[Beta] MQTT beta 3d (released 5th July)

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.

1 Like

Hi!

Sorry to be a fool - I'm struggling to get this working with Home Assistant and Mosquitto Broker.

I'm seeing this on the logs Hubitat side -

and this on the logs Mosquito side

Everything is setup for anonymous authent, just to keep it simple. Any ideas how/where to start debugging please?

Hmmm, my first thought is a network problem.

Have you been using Mosquitto with other stuff for a while or is this a new install?

What hardware is running Mosquitto?

Is it on the same LAN as HE?

What network equipment is between the two?

Try deleting the MQTT client device (not the driver code) and then (importantly) restarting your hub. A new device will be created.

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:

image

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.

Quick question - why not use the awesome HE Nodes for Hubitat?

edit: I get why you might want to go with MQTT everywhere it's nice to standardize on - that's kinda my long term goal as well..

I've got the HE Nodes, which are indeed great.

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.

1 Like

Might want to post that over on the Node-RED thread and ask @fblackburn / others..

I really haven't experienced that issue with Node-RED / HE at all.. interesting!

1 Like

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.

1 Like

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

1 Like

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.

I am still playing around with this though.

1 Like

Yup agree 100%

Ah, that did the trick, thank you - I was sure I was missing something obvious like that!

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?

Sorry - not just at the moment.

Could you perhaps add an interim (Intranet secured) bridged broker that was mirrored to the remote broker as a workaround ?

2 Likes

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.

Any suggestions on how to set the fanmode?

I’ll check it - does it update the device attribute at all or throw any error message in the log?

this is what happens when setting the coolingtemperature (homie/hubitat1/airco/cooling-setpoint/set with payload 23):

and this is what happens when setting fanmode (homie/hubitat1/airco/fanmode/set with payload quiet):

I am not sure ‘quiet’ is an allowable value. Let me refresh my memory on this part of the code. Does high, medium, low, off work ?

MQTT should list the allowable enum values so that is a bug too

Is this the device driver you are using ?

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

Download the Hubitat app