Hi @hek and @scalz
Thanks for your response. I have been unable to locate the guide I thought I previously found... So I probably misread that.

Thank you for the clear answer - which leaves me with only one more ( at the moment )... If I install OpenHAB - will it be able to hand out id's via MQTT? I noticed that the clients without an id keep posting to MQTT... under node id 255...

/th

Hi there,
Fantastic work on this library! Thanks!

A few suggestions for the mqtt client gateway:

• Make the sketch name and version a "retained" message on the broker - this will make it easy for the controller to know which nodes are attached
• Make the individual sensor presentations become a retained message on the broker. this will make it simple for a controller to know exactly which data to expect from which node
• remove the ack from the mqtt topic tree - unless I have misunderstood something it is not really usefull between broker and gateway (except to make it look exactly as the mysensor frames). So remove it and save the bandwidth...
• make it possible to define the QoS for messages to the server

Thanks again
/th

Great to hear that. I had similar problems - only with corroded pins on the w5100 shield so my proposal would have been to remove the shield, work on the radio and then when that worked return to the w5100...
But great! It Works
/th

Hi @scalz
Fantastic!
I am really looking forward to that!
I was actually thinking that for sensors that only wake up and publish on changes, the retained feature could be really great too... That way you would always get the most recent temperatuere, switch position etc. on subscription... Except for the load on the broker I cannot see any disadvantages.
/th

Gateway:

Sensor:

@Gustafsson - sure,

Gateway:
arduino uno R3 with w5100 ethernet shield and NRF24L01 radio. All bought on ebay from some random chinese manufacturer...

Radio with soft-spi - connected as illustrated here.
Running the GatewayW5100MQTTClient sketch with the following changes:

• comment out the IP to activate DHCP:
  //#define MY_IP_ADDRESS 192,168,178,87
• Enter mqtt broker address - I use the public available hivemq demo:
  #define MY_CONTROLLER_URL_ADDRESS "broker.hivemq.com"
• optional change mqtt settings:
  #define MY_MQTT_PUBLISH_TOPIC_PREFIX "to"
  #define MY_MQTT_SUBSCRIBE_TOPIC_PREFIX "ti"
  #define MY_MQTT_CLIENT_ID "tv50"

Sensor
Arduino nano with serial adaptor, NRF24L01 radio and a switch on pin 3.
Running the BinarySwitchSleepSensor. Only change is to add this line to assign node-id:
#define MY_NODE_ID 12
It is only needed the first time - after that it is stored in eeprom. If you check the debug serial prints, then you should be able to find something like:
TSP:ASSIGNID:OK (ID=11)
If it does not get the right id then load the ClearEepromConfig, run it and go back to the binary switch sketch.

How to test
The above enabled me to use mqtt.fx to connect to the hivemq broker and subscribe to "to/#" which means all messages from my gateway (to is the mqtt out prefix configured on the controller).

If it still does not work then please post a dump from the serial port - perhaps some of the champs can help decode it...

/th

@scalz - jeez I spent a lot of time invesstigating this

Hi there,
Fantastic work on this library! Thanks!

A few suggestions for the mqtt client gateway:

• Make the sketch name and version a "retained" message on the broker - this will make it easy for the controller to know which nodes are attached
• Make the individual sensor presentations become a retained message on the broker. this will make it simple for a controller to know exactly which data to expect from which node
• remove the ack from the mqtt topic tree - unless I have misunderstood something it is not really usefull between broker and gateway (except to make it look exactly as the mysensor frames). So remove it and save the bandwidth...
• make it possible to define the QoS for messages to the server

Thanks again
/th

Ok, Responding to my own post so whoever is in the same boat does not have to search for this info...

In the API-description - which I for some reason had not discovered before, there is a wealth of information. In the serial API description there are all the tables we need to understand the mqtt client operation.

So... Look here for v2.0 serial API description.

The documents are not directly describing the mqtt tree - but the information in the mqtt tree is all described there:

mqtt topic tree: prefix/node-id/child-sensor-id/message-type/ack/sub-type + payload

Ok - prefix, node-id and child-sensor-id are defined by you in the sketches. Prefix in the gw the other two in the sensors. NB. your sensors must use manual id assigment unless you have a controller that handles that - I do not.

Message type: defines what the message contains AND what the sub-type means:

• Presentation (0): Contains the S_xxx sensor type
• set/req (1/2): Contains the V_xxx data type
• Internal (3): Contains an I_xxx constant that describes what the payload is - ex. I_CONFIG (6) or I_SKETCH_VERSION (12) from my example above
• stream (4): for fw update. I have not investigated that yet.

The **ack **field is used to know if a message is an ack to a previous message or a real message. I assume that only normal messages will be forwarded to the mqtt broker - so I think it will always be 0.

I hope this information can help somone else to avoid spending time digging in the documentation, code and exampes

/th

Hi There,
I have my MQTT client gateway up and running - and tried to decode the mqtt topic tree that is sent to the mqtt broker.

EDIT: I have deleted the (wrong) information from this post. Below I have added the correct interpretation in a reply.

I have set the publish prefix to "to", node id and sensor id are set in the sensor sketch

ex. from mqtt.fx subscribing to "to/#"
to/10/4/1/0/16 payload 1/0
Prefix "to", node 10, sensor 4

I have another sensor (id 11) that does not work so well. The radio works but it reports several errors and I have not fund out why yet. But it reports several other mqtt topics that are forwarded to the mqtt broker during boot:
to/11/255/3/0/6 payload "0"
to/11/255/3/0/12 payload "1.0"
to/11/4/0/0/0 no payload
Prefix "to", node 11, sensor 4 and 255

The strange thing is that the binary sensor I have that works, does NOT send any messages to mqtt unless I activate the button. I will investigate later...

So - the question is how to understand the mqtt topic tree - so that my controlling app can subscribe to the right topics.

I have - at least partially answered the questions below...
/th

Hi @Gustafsson
I cannot claim to be an Expert. I did what you are doing with almost untouched v2.0 examples... so a suggestion be to upgrade to 2.0 and try again...
Sensors must have a client id manually assigned AND Clear the eeprom with the sketch in the The mysensor - not the arduino One.
The Gateway I just commented out the ip to get a dhcp ip. Then I updated the broker url and it Works

Good luck