ESP8266MQTTClientGateway

[mbj]

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).

[Yveaux]

@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?

[mbj]

@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.

[Yveaux]

@mbj Ok, got it.
Maybe @hek can explain why the format changed.

[hek]

@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.

[mbj]

@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

[hek]

It has been posted here:
http://forum.mysensors.org/topic/2352/guide-setting-up-and-testing-mqtt-client-gateway

[mbj]

@hek That was very visible, please excuse my ignorance. Even though I have looked at this page I managed to leave the change unnoticed.