I have the same driver for my Ikea shades and ran into the same error message as @hovee referencing the MissingMethodException on line 4469 while attempting to publish my shades to MQTT.
I commented out the extraneous text on line 4469 and it seems to have fixed the error and allowed the shades to be published. Before the $state would stick on "init" and all the devices would be uncontrollable in HA (and no shades present), now it is "ready" and all devices including the shades are controllable.
I didn't see any further discussion on this one so I wanted to give a heads-up that despite the useless error groovy spit out, it really is that mashed up line of text on line 4469 of the app code that looks to be the root cause.
I feel like I'm being very stupid, so I hope somebody can set me straight.
I've got MQTT going OUT of my HE just fine, the states report in MQTT Explorer and can trigger stuff in Node-RED, but I can't for the life of me work out how to correctly issue a command through MQTT to trigger that change in HE.
Taking my Office bulb, for example, I can see the following:
However, my logical thought would be that publishing false to onoff would change the state in HE, but that doesn't work. After half an hour of googling and scouring the forum, I'm still stumped.
They don't always seem to update for me though. I've got a virtual switch I activate through Alexa to set my night mode stuff, for example, and twice now it's failed to show up as changed in Node-RED even when I turn the switch on directly from the HE.
Maybe I'd be better off trying to narrow down why the API is failing to update Node-RED, haha.
The topics for controlling anything are the same as the status topics but with .../set appended, assuming the device is $settable=true
so your office light would be controlled by the topic
homie/hubitat-elevation/office/dim = 50
or homie/hubitat-elevation/office/onoff = false (or off)
That is indeed logical but in MQTT you can't use the same topic to provide status and to control the device. They are always two different topics with the control topic typically being appended with ... /set (or in some other systems .../cmd or .../command)
I will try and improve the documentation to make this clearer as it has stumped a couple of people before too.
NodeRED does create an alternate solution for you and you should be able to get it working reliably although it then only provides a HE<>NodeRED link and doesn't expose HE devices to any other controllers you may have or add later.
Yes you could onwardly pass the NodeRED info to MQTT and monitor MQTT for changes with NR but you are essentially tied into HE/NR. If you use MQTT directly you are 'open' to interaction with all other MQTT capable devices and no longer tied to NR or HE. You can also import other MQTT devices into HE. So it provides much greater flexibility , particularly in larger systems or when your system evolves later in life..
You can still use NodeRED with MQTT of course with there being that one extra step of MQTT inbetween. Speed will not be a concern either way.
You can sort of regard MQTT as an open state model for everything in your system - kind of like HubConnect or HubMesh but accessible to all MQTT capable controllers, not just HE
Exactly!!! I agree!!! The ultimate setup imho is to use MQTT as the generic communications "backbone" to tie everything together.
At present for me and my use-case it is more practical time-wise to use the HE Nodes as part of an HE/NR integrated system - at least for the systems I install and support. I do use MQTT for other communications like pulling from a Personal Weather Station and also generating custom "events" in NR.
based on broker configuration, it seems a certificate based authentication (e.g. AWS IoT) is currently not possible? any plans to include this connection method?
I'm struggling with the thermostat functionality. I have a Fuji Airconditioner, which I control via a Sensibo remote control, using the Sensibo Integration for Hubitat by Bryan Li, which works just fine.
In Kevin's MQTT-app, I published this thermostat device, and it is visible in Mosquitto (see screenshot). I can even set cooling- and heatingtemperatures using homie/hubitat1/airco/cooling-setpoint/set with payload 22, to set it to cool at 22 C.
However, I just can't seem to set the fanmode using either ../set, ../cmd or ../command, eg homie/hubitat1/airco/fanmode/set with payload auto or quiet. It just has no effect.
This property is settable. Difference between coolingtemperature and fanmode is the datatype; the first one is float and fanmode is of type enum.
If so it’s a half converted ST driver and needs some further work to get the enumeration values and attribute / control for the fan mode working I’m afraid. It was designed around tiles - not implemented as such in HE
