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


  • Mod

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



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


  • Mod

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


  • Admin

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



  • @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 🙂


  • Admin



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


 

165
Online

8.7k
Users

9.5k
Topics

99.5k
Posts