Well, I have one, haha.
I can add my Xiaomi button to HA, and that was working fine. So may depend on what button you have?
Now I know this, I'll work on my lights then. 
Looking forward to version 3c 
So with the Xiaomi button in HE it auto creates a device on HA... ??.. interesting, Or was this added directly to HA ?
I may be able to arrange something for your other buttons then. What driver are they using ? I assume they do populate to MQTT OK ?
Sorry no, I mean HA supports the buttons, as I have one connected on there.
Yeah buttons are in there, just not to HA. This is another Xiaomi button.
Any reason I see this?
Only the ones with numbers at the bottom are the ones which made it to HA. 25 batteries, and 1 light. Have I cocked something up?
No - that is as expected... For every device that you expose from HE to HA I create an entry in homeassistant/devicetype for discovery by HA. You're seeing the 25 advertisements for your battery sensors and one for a light device type. I needed to include those numbers 7335, 7544 etc to group entities in 'compound devices' so that if a contact sensor for example had a temperature, humidty and a light sensor they were picked up by HA as belonging to the same device.
There is no HA Discovery advertisment there for a button though - let me look back at what happened here, I seem to remember it was some limitation of the HA MQTT Discovery protocol.
The HA StateStream50 topic in that screenshot contains device updates sent by Home Assistant. Within there are all your HA devices. Which brings me to a question .. Do you know what is sent to HAStatestream50 by HA when you click the Xiaomi button in HA ?
1 Like
Here's a bit of background for HA MQTT Discovery of HE devices
1 Like
Thanks for the help Kevin, I'd forgotten I had re-paired the switch with HE again, but can put it back on HA for a test. When I do, I'll grab the details
Dont worry - but it will be interesting to see how HA reports it (button) via MQTT - I am not sure if it can be discovered automatically by MQTT
1 Like
I have posted beta 3c to github. It's a minor hotfix.
It addresses the json fix @guido to support multiple json keys within one device / different attributes and also the same or different keys within multiple devices.
Also supports changed variable support and much revised MQTT Text Driver @LosinIt which provides a Dashboard UI text display device driven or synched from MQTT. This includes optional prefix and suffix support for example to append measurement units or these could be html tags as desired. You can alter the text, prefix, suffix on the fly via MQTT or RM
If you add 'MQTT Text' as an HE device and 'enable' it for MQTT it will appear on MQTT as below.
If you wish to add and link it to an existing adhoc MQTT payload then do this via the Virtual Device option in my app and configure the topics to use (in the 'quirky' editor)
Various bugfixes... close now to release version at last which I'll add to Package Manager.
Kindly report any issues asap (as I've likely missed them)
(Completing Homie discovery into HA still to do)
Will work on documentation now as the Github read me is from a way back
1 Like
I have a question....
Not many people post here yet there were a 100+ alpha access requests. I do get a lot of PM's from people I've never heard of but I have really no idea how many people use my app.
If I was to include a 'feature' that just let me know how many people use this app by advising me of your HubUID would that worry you ? This is not the IP or MAC address but seems to be a random but unique identifier (the only one) I have available to use. I don't believe in any way it identifies you to me. I'm wanting this really to know how much work I should put in, in the future, to this app.
This app is free to use and always will be from me, yes I have a PayPal coffee donation link but my incentive is for many happy users and pushing HE to be the leading integrated hub in the MQTT world, which I believe it now is... 'probably' ... but I'm just not sure how many of you there are..
2 Likes
Would you support me including a fully anonymous feature that advised me how many people use my app ?
The last option has an inference you would and so defeats my objective.
- No
- Yes
- Yes - as long as I can opt out
0 voters
Thnx for the beta3c release. I wanted to get started with the virtual MQTT devices and json payload (re)mapping.
I tried installing but ran into several issues. After some fiddling around I decided to remove the app, driver, devices and app/driver code, reboot hubitat and start from scratch.
Still, the following happens:
- import driver code from github: check
- import app code from github: check
- creating app: hangs in loop (browser window waits indefenitily), log shows some action (see screenhots), but when refreshing the browser, there is no MQTT app created. However, the mqtt child device driver is created.
- Second try to create the mqtt app seems to succeed (the browser shows the hubitat mqtt app). However the log shows errors.
- Setting Hub name and MQTT Broker address results in the following entries in the log
- No connection to the broker
It took me a while to get back to you, because I tried the above several times to be sure it's reproducible and no trivial issue.
Could it be that there are some leftovers of objects/code somewhere in hubitat that could cause this behaviour? I really tried to delete everything and rebooted several times.
I wanted to downgrade to beta3b to check whether I could get that version working again but can't find the files in the repository.
Any suggestions welcome...
UPDATE: I manually deleted the MQTT Child device driver. Then again configured broker in the mqtt app and now it's connecting to the broker
So I definitely would choose option 3 but allow it at least initially. It just seems like the classy/fair thing to do even though it can mess with your #'s.
Would have the default setting to "opt out" unchecked - maybe a blurb explaining why you want to collect data, how it is useful etc etc. Also maybe collect the version of MQTT in use at that time as well.
For legality purposes (especially seeing how someone will throw out GDRP, CA Privacy laws), the default option should be to opt IN, not OUT... either that or force a "yes I have reviewed this" somewhere...
and make it VERY clear what it's collecting, how often, etc...
Personally I'd have no problems with on every "save" it sends some information such as # of devices pushed to HA, number of devices from HA, etc...
1 Like
Continuing my question from here: [Alpha] MQTT application
@kevin So I tried to set up the device as a "Virtual Temperature Sensor" since I get both battery and temperature data from my RV battery. However when I choose that as the device type it doesn't give me the option to choose any attributes:
When I choose the edit option:
Then click "Update" it takes me back here:
EDIT: Nevermind: I forgot to select it as a device first in the first selection menu before proceeding to "Edit". My bad. Now I've got it to where it let's me enter the attributes:
I thought Temperature Sensor would make the most sense... As I thought it would have a battery attribute as well as a temperature attribute, both of which are things my BMS tracks for my main battery pack. I guess the virtual temp sensor doesn't have a battery attribute?
You mentioned the Text driver... I wasn't clear on what that was for exactly or if I needed that?
-Jeremy
@kevin, this is what I was talking about some weeks back (probably in a PM) when I noted the same behavior.
One additional question I have:
The Victron MQTT broker has an odd behavior: In order to avoid sending unnecessary messages it automatically shuts down after 60 seconds. That means if a client wants to continue receiving messages from the broker it has to publish a message once every 60 seconds to do a "keep alive". The example Victron provides is to run something like this every 60 seconds:
mosquitto_pub -h localhost -t "R/04a316c3eb1f/system/0/Serial" -m ""
My thinking was to create a virtual button or switch and just set up a rule that pushes the button every 60 seconds, and map a button push to publish a message on that topic. So I created a virtual button like this:
Do I need to add something to tell it what "message" to publish? It just needs to be an empty string.
Hmmm, @kevin's app sends homie/steve-s-hubitat/$implementation/heartbeat every 20 seconds. I wonder why that doesn't do the "keep alive"? Does every subscriber have to publish in addition to the publisher?
The editor is ‘quirky’ in that it sometimes requires two updates to accept a value but the behaviour is as intended.
The app does a few things before ‘taking you back’ . It adds the value you have just edited to the data value within the device and it makes sure MQTT is subscribed to any needed topic you have just added. The values from my dynamic page were getting mixed sometimes if I did not return to the entry screen. I will revisit this but not immediately.
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.
