That fine it's the GE one I wanted to know as I don't see those unknown topics here..
it's not specific to GE; I get unknowns for the outlets too.
The common part is that the unknows are being transmitted when the HE Web interface is used.
First off...thanks @kevin for creating this. This is exactly what I needed for a home pool project I am working on.
However, I have not been able to get a manually created device mapping to work. I believe I have everything set up correctly, but I don't see the Hubitat devices mirroring what I see in MQTT Explorer. What kind of additional info can I provide to better troubleshoot?
Thank You!
Your connection to the MQTT broker seems to be constantly restarting ...
Any reason you can think of ?
If not can you reboot the Hubitat hub and see if that corrects it (maybe there are two clients running).
You are running the latest client driver yes ?
I see this early in the logs, which is correct - but I don't see it later after the reconnect
MQTT subscribing to: aqualinkd/Temperature/Pool
I also rebooted the Hubitat hub as part of my troubleshooting steps. So check on that. Maybe you were seeing that early, before I rebooted the hub.
My Hubitat device list only shows one MQTT Client.
I just installed MQTT app from your beta branch earlier today.
Troy
It does that even if two are concurrently running but if you have rebooted then only one will be running.
Can you 'disconnect' the client driver (button in devices UI) and then re-run the app through 'done' again.
Also just post me the data for the temperature device you created (from the devices UI)
Clear the logs before clicking done
The MQTT client log is the most useful one at this stage..
Please do restart again as it does look like you have two connections running - the heartbeat messages don't match
dev:972020-02-04 01:54:34.829 pm debugMQTT> Rx: heartbeat [87] none
dev:972020-02-04 01:54:33.355 pm debugMQTT> Tx: heartbeat [0] none
I removed the two virtual devices I had. Then went back into MQTT app, on second screen chose to create a new device for virtual temp sensor, then chose to enable it for MQTT, then edited its topic. Upon clicking through to Done, I see that device was created and indeed was updated this time.
The main difference between my previous attempt was that I manually created the virtual temp sensor devices first, instead of having the MQTT app create them.
I see an extra attribute in the Data field for the virtual device that I don't recall seeing before.
I will also reboot again, as you asked in your reply.
Ahh I see - I should probably emphasise that in the read-me. If you directly create the device in HE it is not a child device to my app and so I can't access it. I suspect afterwards it wasn't enabled in the 'Enable All Devices' dropdown as it was a new addition.
I have now (in beta 2) removed that 'All devices' dropdown as it was confusing and often forgotten but it now requires the virtual devices be created within my app and thus they are child devices to it. Hence it was not updating..
Hope it's working now - if not post back..
In my first attempt, I had indeed went back to the Enable All your devices section and toggled on again, but as you stated, the initial device creation and thus MQTT connection was probably bad.
I will proceed further with testing.
BTW...It was not clear to me what the text driver was for. Can you elaborate? The reason I ask, is I have some devices in MQTT that don't quite fit to a HA virtual device. Such as a motor, which contains RPM and Watts attributes. I would like to be able to get various MQTT attributes into HA in some form, maybe as global variables or something. Wondering if the text driver could be a fit?
Thank You
Again in the upcoming beta2 I have further enlisted the use of my 'text' driver. It was an easy way to get a textual MQTT payload into HE and displayed as an 'attribute' tile (text) in the HE dashboard. RM is not very good (capable) at handling string values though. WebCore is better in this respect.
It also supports a 'prefix' and 'suffix' that gets appended to the text which can be used as html tags to change font colour/size/anything or usefully 'suffix' is available to add a units value like °F or °C. There are commands available in the driver that include these values automatically or you can just update the displayed text directly. You can call these from RM.
However you can also directly input any MQTT payload into an RM global variable which you might prefer, this can be displayed again on the dashboard but lacks prefix/suffix ability.
Sounds like that Text driver will indeed be of interest to my project. You describe almost my exact use case, since it doesn't match an OOTB virtual driver.
If I can be of any assistance to this project, please let me know. I play IT architect by day, so I understand this stuff.
Thank You!
I've tried to make the MQTT app as simple as possible for new users but surprisingly capable for expert users. If you have suggestions on how it can be improved then I'm all ears.
I don't want to add specific 'kludges' to suit a users need or another app but things that are generally beneficial to HE users I'm keen to support.
I think my 'second page' virtual devices and maybe even the HA/homie 'third page' will get accessed via a sub menu rather than as a sequential step through once I get more time and more familiarity with the UI
I might suggest that you consider the parent/child design approach that I have seen other Hubitat and third party apps take. I have a few other apps that use that very effectively.
Would make create/update/delete operations very intuitive on each device.
I do create MQTT virtual devices as child devices to my app. Already existing HE's devices are outside of my apps control.
The MQTT client driver is not a child driver to my app as I originally envisaged using it with other apps, it 'events' messages. However I am now considering making it a child device to my app whilst I address multiple MQTT broker support
Or did you allude to some other aspect / benefit ?
Looks like the Thermostat device linking code may need some work. Configured the MQTT device and it does seem to be getting some settings, but not from where I configured.
MQTT Explorer showing what is in the message tree.
Thermo device as configured in Data section:
Thermo device current states:
It also looks like there may be need to tell the MQTT driver how to interpret the values in each message. For instance 1=On/Enabled, 0=Off. I thought I saw you had something for this interpretation in regards to switch states.
Let me know if I can contribute any more details. Thanks.
Let's take your example...
So the supportedMode expects auto|cool|emergency heat|heat|off as the payload but
you are linking it to a payload that provides '0' , it's not clairvoyant there are 5 payloads allowable and 0 isn't one of them.
I provide mapping of 'boolean' values between whatever your device provides and whatever HE expects e.g ON > true or high > open. I also provide level scaling. I do not provide mapping of every payload possibility to every possible attribute value. That would be hugely complicated in the UI and to users. I recognise it's going to crop up though and it's not impossible, in fact I've considered (and half implemented) it but not currently.
It would be more appropriate to use a scriptable engine like nodeRED for that to do the payload and topic translations. The thermostat is one of the most complex and awkward devices you could chose... If the payloads are in the right format it will likely work though.
Alternatively you could use Rule Machine to translate payloads and populate the thermostat appropriately.
I might remove the virtual thermostat (and Omni sensor) from being selectable currently as they are a PITA.
Understood on your points, but I also see the setpoints are not loaded from the topic configured. They appear to all be loaded from the temperature topic.
