(Not a question, but rather an informal post aimed at saving others time figuring things out.)
When I went searching the forums for information on how to get the Venus's MQTT server to allow local access to the information I wanted, I found a lot of posts with solutions that either didn't work, required an internet connection, relied on a child MQTT server, or required an always on server sending keepalive messages to the Venus device. In our usage environment, a cruising sailboat, relying on an internet connection was a non-starter, and since we power our MQTT instrument data via an Arduino, powering a Raspberry pie or similar just to feed cookies to our Octo GX seemed silly.
For people familiar with MQTT, but new to Venus: You'll see a lot of mentions of keepalives in these discussion, and you might gloss over this, already being familiar with the keepalive mechanism of the MQTT protocol, but this is not that keepalive. The keepalive that causes all the trouble is a internal Venus thing that is used to stop bridging information from their internal data bus to their local MQTT server (which is just mosquitto, which you may be familiar with). It's the timing out of the bridging into MQTT which causes most of the frustration.
That out of the way, here are the steps to making a local only MQTT Venus without a separate, keepalive feeding server. To do this, you'll want something that can explore MQTT topics, such as MQTT Explorer, something you can publish a topic with, I'll show this with mosquitto_pub since it's the tool I know the best, but there are probably easier ways (you will need this once per power cycle of the Venus), and your favorite MQTT dashboard app, I use Virtuino 6, but use whatever appeals to you the most. This setup assumes that your system is on a secure network, if that is not the case, you will want to do extra steps to configure access controls to the Venus MQTT server.
- Turn on MQTT via the remote console's Settings -> Services (I turned on both plaintext and SSL, but only used the former)
- Disable VRM via Settings -> VRM online portal (If you actually want VRM, I don't recommend this solution since it will add a lot of updates to what is sent to Victron's server)
- I recommend turning off auto updates as well, since an update will undo one piece of this solution and you might be left scratching your head as to what happened. This is not strictly required. Settings -> Firmware -> Online Updates
- Give yourself root access (usual disclaimers apply here, you can mess up and it can be bad, this is only for technical users, etc) Settings -> General set Access level to superuser and make sure to give a password.
- ssh into your Venus via ssh root@venus.local and do the usual ssh dance.
- Next you will turn off part of the keepalive mechanism, that which requires periodic MQTT publishes. The easiest way to do this is to modify /opt/victronenergy/service-templates/dbus-mqtt/run to add " --keep-alive 0" to the end of the line that starts dbus_mqtt.py. I saw several posts saying to do the same to a file in /service, but at least on my system that does not work as that file is created on bootup from the file I pointed you at.
- reboot the Venus device
- Next we need to find our system id, which we can do with MQTT Explorer by connecting to venus.local and expanding the "N" topic, which should have child whose name is your 12 hex digit id.
- At this point if you explore the tree, you'll find nothing of use outside of statics about the MQTT server itself. This is because the dbus->mqtt bridge defaults to being conservative and not bridging information. Next we'll populate the tree to find what topics we are interested in.
- Since Victron doesn't appear to publish a topic list the easiest way to see what's out there is to tell the data bus to MQTT bridge to just bridge everything. I did this with "mosquitto_pub -h venus.local -n -t 'R/<your id here>/system/0/Serial'" substituting my id for <your id here>.
- I then explored around and built the first pass of my dashboard using MQTT Explorer to find the topics I needed.
- Since we're now asking Venus to bridge a lot of information into mosquitto via a relatively expensive mechanism, it's best to now go back and selectively tell the bridge what we're interested in. To do this, start with a Venus reboot (either via the command lien or the remote console mechanism).
- To selectively tell the bridge what we want to see, we publish to the topic "R/<your id here>/keepalive a JSON encoded array of topics with the top "N/<your id here/" stripped off. Basically the topics relative to the controller.'s point of view. In my simple example of getting data from my battery monitor (289 on my setup) I used the command:
"mosquitto_pub -h venus.local -m '["battery/289/Dc/0/Voltage", "battery/289/Dc/0/Current", "battery/289/Soc", "battery/289/Dc/0/Power", "battery/289/ConsumedAmphours", "battery/289/TimeToGo", "battery/289/History/TimeSinceLastFullCharge", "battery/289/Dc/0/Temperature"]' -t 'R/<your id here>/keepalive'"
- Obviously you'll want to expand this, tune it to your setup, and make it your thing. It's a good idea to make a script to do this, or save the publication message so as you can do it easily since you will need to do this publication after each Venus reset.
Attached is an quick example dashboard I made with Virtuino. (Ignore the connection error at the top, that was to our instrument server which was off at the time).
Hopefully this saves someone some frustration along the way.
Lisa
