<![CDATA[ESP8266MQTTClientGateway]]>I am not sure this is a bug or an intentional change of the MQTT message structure.

The version 1.5 Gateway has the code:

inline MyMessage& build (MyMessage &msg, uint8_t destination, uint8_t sensor, uint8_t command, uint8_t type, bool enableAck) {

while the ESP8266MQTTClientGateway uses:

       snprintf_P(_fmtBuffer, MY_GATEWAY_MAX_SEND_LENGTH, PSTR(MY_MQTT_PUBLISH_TOPIC_PREFIX "/%d/%d/%d/%d/%d"), message.sender, message.sensor, mGetCommand(message), mGetAck(message), message.type);

The disadvantage is of course that when upgrading to the ESP8266MQTTClientGateway a lot of coded definitions in for example Openhab have to be changed (I have no experience of how other controllers will handle this).

]]>https://forum.mysensors.org/topic/2971/esp8266mqttclientgatewayRSS for NodeMon, 10 Aug 2026 07:19:42 GMTSat, 30 Jan 2016 10:26:26 GMT60<![CDATA[Reply to ESP8266MQTTClientGateway on Sat, 30 Jan 2016 14:16:00 GMT]]>@hek That was very visible, please excuse my ignorance. Even though I have looked at this page I managed to leave the change unnoticed.

]]>https://forum.mysensors.org/post/30093https://forum.mysensors.org/post/30093Sat, 30 Jan 2016 14:16:00 GMT<![CDATA[Reply to ESP8266MQTTClientGateway on Sat, 30 Jan 2016 14:08:27 GMT]]>It has been posted here:
http://forum.mysensors.org/topic/2352/guide-setting-up-and-testing-mqtt-client-gateway

]]>https://forum.mysensors.org/post/30092https://forum.mysensors.org/post/30092Sat, 30 Jan 2016 14:08:27 GMT<![CDATA[Reply to ESP8266MQTTClientGateway on Sat, 30 Jan 2016 14:02:46 GMT]]>@hek Thank's for the info. I have missed any discussions about the change but as I am sure I am not the only one please add some text about the new format as a comment to the sketch whenever convenient. Might save some calls for support :-)

]]>https://forum.mysensors.org/post/30091https://forum.mysensors.org/post/30091Sat, 30 Jan 2016 14:02:46 GMT<![CDATA[Reply to ESP8266MQTTClientGateway on Sat, 30 Jan 2016 11:34:22 GMT]]>@Yveaux said:

Maybe @hek can explain why the format changed.

It was due to space requirement (all V-types had to be stored as strings) and maintenance reasons (no changes needs to be done in the MQTT driver when adding a new V-types). Also the "new" topic follows the serial protocol (including internal commands) which should make it easier for controller developers to support both MQTT and serial protocol.

]]>https://forum.mysensors.org/post/30080https://forum.mysensors.org/post/30080Sat, 30 Jan 2016 11:34:22 GMT<![CDATA[Reply to ESP8266MQTTClientGateway on Sat, 30 Jan 2016 11:31:03 GMT]]>@mbj Ok, got it.
Maybe @hek can explain why the format changed.

]]>https://forum.mysensors.org/post/30079https://forum.mysensors.org/post/30079Sat, 30 Jan 2016 11:31:03 GMT<![CDATA[Reply to ESP8266MQTTClientGateway on Sat, 30 Jan 2016 11:09:01 GMT]]>@Yveaux Thank's for a quick reply. The current message (1.5) shows up with type (like V_TEMP) in third position in the received message at the Openhab end. Item def thus is something like MyMQtt/24/1/V_TEMP:state:default.

The received message from new version as sniffed by a MQTT.fx client is MyMQTT/24/1/1/0/V_TEMP which thus means a rewrite of all definitions in Openhab.

]]>https://forum.mysensors.org/post/30078https://forum.mysensors.org/post/30078Sat, 30 Jan 2016 11:09:01 GMT<![CDATA[Reply to ESP8266MQTTClientGateway on Sat, 30 Jan 2016 11:30:39 GMT]]>@mbj said:

inline MyMessage& build (MyMessage &msg, uint8_t destination, uint8_t sensor, uint8_t command, uint8_t type, bool enableAck) {

This is the build-method used to create a message to be sent over the MySensors network, while this

snprintf_P(_fmtBuffer, MY_GATEWAY_MAX_SEND_LENGTH, PSTR(MY_MQTT_PUBLISH_TOPIC_PREFIX "/%d/%d/%d/%d/%d"), message.sender, message.sensor, mGetCommand(message), mGetAck(message), message.type);

is the creation of the format string to convert a message to MQTT topic...

Two different things.

What is your real issue?

]]>https://forum.mysensors.org/post/30074https://forum.mysensors.org/post/30074Sat, 30 Jan 2016 11:30:39 GMT