[SOLVED] MQTT Homie Implementation - some properties remain in dummy state

Setup, Configuration and Use Scripts & Rules
#1

Openhab 2.4 with MQTT2 binding here.

I am noticing that some of the channels for a homie device continue to remain in the dummy state while others are properly processed.

Here is what I show in the paper UI:

image
image.png1198×806 80.3 KB

Display Line 1 and Display Line 2 appear to properly processed and have type string. Display line 3 and display line 4 are of type “dummy”.

If I check the retained topics with mosquitto_sub for “source-1”, I have the following:

homie/nuvo/source-1/$properties displayline-1,displayline-2,displayline-3,displayline-4,duration,position,status
homie/nuvo/source-1/displayline-1/$name Display Line 1
homie/nuvo/source-1/displayline-1/$settable true
homie/nuvo/source-1/displayline-1/$retained true
homie/nuvo/source-1/displayline-1/$datatype string
homie/nuvo/source-1/displayline-2/$name Display Line 2
homie/nuvo/source-1/displayline-2/$settable true
homie/nuvo/source-1/displayline-2/$retained true
homie/nuvo/source-1/displayline-2/$datatype string
homie/nuvo/source-1/displayline-3/$name Display Line 3
homie/nuvo/source-1/displayline-3/$settable true
homie/nuvo/source-1/displayline-3/$retained true
homie/nuvo/source-1/displayline-3/$datatype string
homie/nuvo/source-1/displayline-4/$name Display Line 4
homie/nuvo/source-1/displayline-4/$settable true
homie/nuvo/source-1/displayline-4/$retained true
homie/nuvo/source-1/displayline-4/$datatype string

I don’t see any difference between the messages for display line 1 & 2 vs 3 & 4 that would result in one set of being properly processed and the other remaining in the “dummy” state.

@David_Graeff - Do you have an idea on where I can start to troubleshoot?

#2

I messed up. The homie binding part cannot process topics that contain dashes ("-"). That will be fixed at some point. At least if you create a bug report because I’m not working on MQTT for a while.

#3

I can open an issue… I saw another post indicating an issue with dashes ("-")… However, I wasn’t sure if this is the same thing… Since it processes some of the items?

#4

Add your example to the bug report. Might be another reason, but at least it is written down, so won’t be forgotten.

#5

@David_Graeff -
I removed all dashes ("-") from my topics. Cleared all of my retained messages from mosquitto and I am in the same situation where a mix of channels are still specified as dummy. I have run the output of a mosquitto_sub through the online validator, which validates them successfully.

It is odd because one homie node will be fine and another homie node (whose only difference is the last character of the node name is incremented by 1) will have all dummy channels. You can see it below in where source2 is all dummy and source3 is properly initialized.

image
image.png590×760 60.9 KB

Any suggestions / specific log instrumentation I should turn on to debug?

#6

I’ve been experimenting with Homie a little bit over the past couple of days and have been seeing something similar where some Homie properties were not being displayed correctly.

Looking through openhab.log I could see exceptions being thrown for “Could not subscribe” and “Did not receive mandatory topic value”, however when checking with mosquitto_sub I could see the mentioned retained messages being sent.

Homie properties that did not have these types of exceptions were displayed correctly, while the ones which were not displayed correctly had exceptions.

I started to look at the timing of these messages and wondered whether the broker was not hitting the within 500ms requirement for a Homie device. In my case they were all arriving in ~300ms.

I am using Mosquitto as by MQTT broker and eventually took a look at its logs and noticed something strange - there was a log entry saying that outgoing messages were being dropped. This lead me to https://stackoverflow.com/questions/49130641/mosquitto-outgoing-messages-are-being-dropped and max_queued_messages configuration in Mosquitto.

As an experiment I tried set max_queued_messages to 0 and all the properties are displayed correctly, the mosquitto log entry about dropping outgoing messages was gone and there was no exception in openhab.log.

Summary: if you use Mosquitto as your MQTT broker and have a lot of QoS 1 or 2 level messages (Homie messages should be QoS 1) then it may be that Mosquitto is dropping them. In this case carefully considered values of max_queued_messages and/or max_queued_bytes for your system might help.

#7

OMG That is very helpful. Would you consider to add a comment about this to the official binding documentation (click on the edit link at the bottom)?

#8

Changing max_queued_messages to 0 resolved this issue for me.

Great find and thanks for sharing! @MrWendal