Correct, it has neither the capability or the attribute. My MQTT Text driver does have the battery capability and a text attribute that could display anything including temperature and you can include a degrees suffix. It does not have a temperature capability.
A non workable implementation. You need to use a proper 24/7 MQTT broker like mosquito. Are you sure this is the broker and not a client ?
Regardless as Steven mentions my app does send a heartbeat every 20 seconds so this should suffice but that is a feature I will likely deprecate.
I was likely going to send the hub UID, or a hash of, every time done was clicked. I am not interested in any other information except how many hubs run this app. If it is just a dozen or so then I will likely not evolve the app any further feature wise but just release any bug fixes. However 100+ say and I have groupies to satisfy.
I am not a programmer and have other commitments so have spent over 6 months in the evenings/early mornings so far , but learned a lot too. I just want to know if people are, or are not using it.
The ‘can opt out’ is always likely to be the final choice but I was trying to gauge how many would actually do this.
Indirectly any existing app that accesses a remote url can stealth implement this any way by IP. Even loading a remote image or code or controlling a cloud device.
Yes, unfortunately it's the only option if you want to interface with Victron equipment via MQTT. (The other available protocols are Dbus, CAN-bus, or MOD-TCP, none of which are available in Hubitat that I'm aware of). Here's the documentation that explains the keep-alive: GitHub - victronenergy/dbus-mqtt: Venus OS service mapping the D-Bus on Venus OS to MQTT
It should be workable though right? I just need to be able to publish a message to the broker every 60 seconds?
Yeah this doesn't seem to work for the keep alive. Maybe because it's not being published to a topic that the broker is aware of? Because my Virtual Temperature Sensor only updates the battery stats if I manually publish a message via the "PublishMsg" button on the "MQTT: Child device driver" page.
This isn’t a battery device ? I can only assume they kill the broker to stop too many bridges to their cloud broker. 
This doesn’t allow an alternate broker to be configured ?
By default, dbus-mqtt will connect to a Mosquitto MQTT broker running on the GX Device itself.
Another option would be to run a local MQTT broker 24/7 that is bridged to the Victron (or their cloud). I’d recommend this if no other solution.
Please don’t use a non 24/7 available MQTT broker with the MQTT app is it is not (yet) definitively robust for frequent disconnects and implements an increasing back off’ timer on failure that can ultimately give up.
Well, this is where it gets hairy. So the page I linked to are docs for "Venus" which is the open source OS (Based on Linux) that Victron developed for their own products. They have a commercial product called the "Color Control GX" which runs the Venus OS.
If I were building my own Venus OS based device (IE: if I took a raspberry pi for example and installed Venus on it and built everything from scratch), I could use whatever broker I wanted. Because I'm using a commercial off the shelf Victron product, they flash the storage device every time you apply any updates to it. So making changes that "survive" a firmware update is a tricky area and something I'd really like to avoid.
I'm also trying to avoid having to add an raspberry pi as a bridge, as adding components just adds even more complexity and parts that can fail.
I guess I'm not seeing the concern with just publishing an empty message every 60 seconds? That seems like it should be simple enough to accomplish? There are quite a few people who are doing it that way and it's working for them, just not necessarily with Hubitat.
Default keep-alive interval is 60 seconds
This implies it’s configurable. Can it be set to 0 for permanent ?
My keepalive won’t work because it needs to go to this topic
Topic: R/e0ff50a097c0/system/0/Serial
Payload: empty
Where I send my heartbeat just add another line after it that sends to this topic... but the broker must be connected or it will fail.
I can send you a line number if that helps, it’ll be in the MQTT client driver. Every time I update though you will have to add it in again.
PM me if you want more help
It is configurable if you're building your own Venus device. On the Color Control it's not (As of now) from what I've gathered reading through the various posts of people who've integrated with it via MQTT. Pretty much everyone just runs some sort of loop to publish a message every 60 seconds.
Thanks! I'll give this a shot. But I'm curious: On the button where it has the option to do "Pushed MQTT command topic": I was under the impression that would allow me to have a button press event publish a message to that topic. Is that not what this is for?
The reason I ask is there are certain things on the Victron that can be controlled by writing commands to certain topics. For example I could switch the inverters off to save battery power if it's not hot enough to need to run the A/C, or send a command to start the generator when the weather forecast shows that it's going to be cloudy (No solar). I was hoping I could map virtual buttons and/or switches to functions like this?
Thanks again,
-Jeremy
Getting back to what I believe was your original question, I don't see why you couldn't setup something to send a message on any time period you wish. But how about just enabling publishing of an existing device's info? I have several devices, like the Aeotec Nano Switch, that can be set via device preferences to send power info as frequently at every 5 seconds (default is 1 min).
Well yes, and no..
Buttons are a right PITA on HE and MQTT. They push their state value to a configurable topic. In this case you will be sending pushed to topic R/04a316c3eb1f/system/0/Serial. If that isn't working for you then let me know (you have MQTT Explorer .. yes ?). You can't remap 'pushed' to empty though.
However it may also be not working because the payload is not empty as documented and my app will not allow an empty (zero length) string to be sent as that usually deletes a retained topic.. I assume empty isn't 'empty' ?
Now switches.. You can send any payload to any topic (but again not an empty string) so yes your switch can send to R/04a316c3eb1f/system/0/Serial and it can be any value, again except empty. I may be able to relax that but as it is a safeguard I'm loathe to.
However if after line 338 in the beta 3c client driver you add a line 339 as follows
interfaces.mqtt.publish('R/04a316c3eb1f/system/0/Serial', '', 1, false)
that should work..
I just realised your device is in a RV so is battery powered .... bridging is still a better solution
Why not write a driver unique to the Victron and not try to squeeze yet another special case into Keven's driver/app? Other MQTT drivers can coexist with Kevins work.
1 Like
And be much leaner...
1 Like
In the case of the Keep Alive, it doesn't really matter what text is sent. Empty is fine, non-empty is fine, etc. I noticed when I use the "publishMsg" button on the child device driver that it throws an error if I leave the 2nd field blank.
groovy.lang.MissingMethodException: No signature of method: user_driver_ukusa_MQTT_Client_348.publishMsg() is applicable for argument types: (java.lang.String) values: [R/04a316c3eb1f/system/0/Serial]
I figured it just required some text to be entered in the message field so I just added the text "test" and that was working fine to keep the keep-alive going (As long as I was pushing it manually):
But when I set this up using a button (According to the screenshot above) I didn't see any messages being published to the broker at all so I just assumed I hadn't configured something correctly.
-Jeremy
Works for me
You looking in the right place on MQTT for an R top level topic and clicking the Publish Msg button ?
.. and you're subscribed to that topic or a wildcarded alternative in MQTT Explorer ?
I think our wires are getting crossed. Let me start over:
When I try to publish an "empty" message using "publishMsg", that's when I get the groovy error. If I enter "Test" it works fine. I've been manually doing the "Keep Alive" myself by simply pressing that "PublishMsg" button and sending "test" every minute. No issues there.
What I'm struggling to figure out is the Virtual Button, which I have configured like so:
And I'm "pushing" the button with this:
Does it matter which button number I use here?
Jeremy - not working .. I agree .. I'll investigate now
One other fix first then yours...(as yours will likely take a bit longer)
Still not sure how getting this button working helps you though ?
No worries, I can switch to using a switch if it's just the button that's broken. I really just assumed I was doing something wrong and just wanted to make sure I understood the "correct" way to do this before digging myself too deep into a rabbit hole. 
Really appreciate the help.
-Jeremy
switch 
but I will fix this too
1 Like
