MQTT Homie convention version

Hi there,

The openHAB page for the Homie binding indicates that it is compatible with v3.x of the binding and up, however there is an important difference between v3 and v4 which is overlooked in the binding.

In v3.0.0 and v3.0.1 the ‘/set’ topic should be set with ‘retain=true’. Whereas in v4.0.0 ‘/set’ has been redefined to be ‘retained=false’. I believe this to be an oversight and is a subject I am already discussing with the Homie Devs for a better workaround.

However v3.x is quite clear that the ‘/set’ topic should be retained. This is illustrated in the following:
v3.0.1:

2.3 QoS and retained messages

The nature of the Homie convention makes it safe about duplicate messages, so the recommended QoS for reliability is At least once (1). All messages MUST be sent as retained, UNLESS stated otherwise.

7.4.1 Property Attributes

  • homie / device ID / node ID / property ID / set: the device can subscribe to this topic if the property is settable from the controller, in case of actuators.

Homie is state-based. You don’t tell your smartlight to turn on, but you tell it to put its power state to on. This especially fits well with MQTT, because of retained message.

Compare this to v4.0.0 which does a full 180°

2.3 QoS and retained messages

The nature of the Homie convention makes it safe about duplicate messages, so the recommended QoS for reliability is At least once (1). All messages MUST be sent as retained, UNLESS stated otherwise.

7.3.2 Property command topic

  • homie / device ID / node ID / property ID / set: The device must subscribe to this topic if the property is settable (in case of actuators for example).

A Homie controller publishes to the set command topic with non-retained messages only.

I don’t believe it would take too much effort to support both conventions. However I believe it is important that openHAB shouldn’t take the stand to only support v4+. There are definite use cases where a retained ‘/set’ topic is a necessity. For example I have an ESP32 device that sleeps and periodically awakes to check for new updated settings, this is not possible if ‘/set’ is not retained…

Thanks,
Alex 2

Your best bet here is to file an issue and see what the developers have to say.