Page 1 of 1

mqtt topic structure best practice; leading slash or not?

Posted: 18 Aug 2018, 02:02
by kenkoknz
Hi,

Can some expert advice me re best and fail safe practice for constructing mqtt topic sentences.
My environment uses various wemos and sopoff loaded with mega using standard default OH mqtt protocol; hivemq and node-red , so far been good.
However I am a bit perplex, as all the topics all start leading slash (with default OH mqtt protocol).
Hivemq reccomends "never use leading slash" (https://www.hivemq.com/blog/mqtt-essent ... -practices), and recently a interesting forum topic in nodered with espeasy, highlighted the leading slash as the cause of mqtt connection problems. (https://discourse.nodered.org/t/wemos-d ... -mqtt/1960).
Just wanted to be sure that there are no potential issues with using leading slashes in a mqtt topic, as it is easy enough to leave the leading slash out if there are issues with it.

Thanks,
Ken

Re: mqtt topic structure best practice; leading slash or not?

Posted: 18 Aug 2018, 12:01
by grovkillen
According to the MQTT standard the slash is the delimiter of levels. By starting a topic with a slash you essentially tell the broker that the first level is named "null" (i.e. a non-existing value). This is not by any circumstances logical and should be avoided as well as double or triple slashes etc. should be avoided. So no, do not start with a slash. 8-)

Re: mqtt topic structure best practice; leading slash or not?

Posted: 20 Aug 2018, 03:26
by kenkoknz
Hi @grovkillen,
Thanks for that, as most of the other protocols have leading /, perhaps might be handy to include in the protocol for controllers drop down, a generic mqtt protocal without leading / i.e:
%sysname%/#
%sysname%/%tskname%/%valname%
Cheers,
Ken

Re: mqtt topic structure best practice; leading slash or not?

Posted: 20 Aug 2018, 06:28
by grovkillen
OpenHAB is as close to a generic MQTT controller as we have... only removing the leading slash and your good to go. But yes, we need to have a "Generic MQTT" as we have with HTTP etc.