Posts made by Thomas Augustinus

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

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 @scalz
Ok - I see that mentioned many places - does that mean that the mysensors library does not have the algorithms to deliver the node-id's?
I am pretty sure that I found a description (of a 1.4 mqtt gateway I think) that claimed it was possible with the mqtt gateway...?
/th

Hi @nielsokker,
Yes - I get that part - as mentioned I did just that to make it work - and that was the test I made to verify that everything works.
But - I really want the automatic id allocation so I do not have to program devices with correct id individually.
I have seen somewhere on google that the mqtt gw can assign node-id to the sensors. So I assume that the library supports this - perhaps it just needs to be activated?
/th

... After playing around with v. 1.5 some time ago, I have restarted with version 2.0 - primarily because another project pushed me in direction of mqtt.
I do not yet have a controller. for now I connect to broker.hivemq.com and use mqtt.fx do see what is published.

Fist - what I have - and below the problem I face - that sensors do not get a node id from the gateway.

I started with the examples. I used the ClearEepromConfig sketch to init the eeprom before loading the examples. I am not really sure it that changed anything.

It took some time to make the gw run. For some reason, the hw played up... One thing that tricked me was all the talk about editing myconfig.h - especially with the softspi. It turned out that the gateway sketch handles it all by it self - so no need to change myconfig.h. If changes are needed then the changes can be made before #include <mysensors.h> in the sketches.
But eventually I got it up and running.

Ethernet is a w5100 shield and radios are NRF24

GatewayW5100MQTTClient
Commented the ip-address out to use DHCP:
//#define MY_IP_ADDRESS 192,168,178,87
Updated broker address:
#define MY_CONTROLLER_URL_ADDRESS "broker.hivemq.com"
It works as a charm:
0;255;3;0;9;Starting gateway (RNNGA-, 2.0.0)
0;255;3;0;9;TSM:INIT
0;255;3;0;9;TSM:RADIO:OK
0;255;3;0;9;TSM:GW MODE
0;255;3;0;9;TSM:READY
IP: 192.168.0.67
0;255;3;0;9;No registration required
0;255;3;0;9;Init complete, id=0, parent=0, distance=0, registration=1
IP: 192.168.0.67
0;255;3;0;9;Attempting MQTT connection...
0;255;3;0;9;MQTT connected
0;255;3;0;9;TSP:MSG:READ 255-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0:
0;255;3;0;9;TSP:MSG:BC
0;255;3;0;9;TSP:MSG:FPAR REQ (sender=255)
0;255;3;0;9;TSP:CHKUPL:OK (FLDCTRL)
0;255;3;0;9;TSP:MSG:GWL OK
0;255;3;0;9;TSP:MSG:SEND 0-0-255-255 s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=bc:0
0;255;3;0;9;TSP:MSG:READ 255-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0:
0;255;3;0;9;TSP:MSG:BC
0;255;3;0;9;TSP:MSG:FPAR REQ (sender=255)
0;255;3;0;9;TSP:CHKUPL:OK (FLDCTRL)
0;255;3;0;9;TSP:MSG:GWL OK
0;255;3;0;9;TSP:MSG:SEND 0-0-255-255 s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=bc:0

BinarySwitchSleepSensor
To make it work I added node id manually above including mysensors.h:
#define MY_NODE_ID 75
And again - it works great:
Starting sensor (RNNNA-, 2.0.0)
TSM:INIT
TSM:RADIO:OK
TSP:ASSIGNID:OK (ID=75)
TSM:FPAR
TSP:MSG:SEND 75-75-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSP:MSG:READ 0-0-75 s=255,c=3,t=8,pt=1,l=1,sg=0:0
TSP:MSG:FPAR RES (ID=0, dist=0)
TSP:MSG:PAR OK (ID=0, dist=1)
TSM:FPAR:OK
TSM:ID
TSM:CHKID:OK (ID=75)
TSM:UPL
TSP:PING:SEND (dest=0)
TSP:MSG:SEND 75-75-0-0 s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=ok:1
TSP:MSG:READ 0-0-75 s=255,c=3,t=25,pt=1,l=1,sg=0:1
TSP:MSG:PONG RECV (hops=1)
TSP:CHKUPL:OK
TSM:UPL:OK
TSM:READY
TSP:MSG:SEND 75-75-0-0 s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=ok:0100
!TSP:MSG:SEND 75-75-0-0 s=255,c=0,t=17,pt=0,l=5,sg=0,ft=0,st=fail:2.0.0
TSP:MSG:SEND 75-75-0-0 s=255,c=3,t=6,pt=1,l=1,sg=0,ft=1,st=ok:0
TSP:MSG:SEND 75-75-0-0 s=255,c=3,t=11,pt=0,l=13,sg=0,ft=0,st=ok:Binary Sensor
TSP:MSG:SEND 75-75-0-0 s=255,c=3,t=12,pt=0,l=3,sg=0,ft=0,st=ok:1.0
TSP:MSG:SEND 75-75-0-0 s=3,c=0,t=0,pt=0,l=0,sg=0,ft=0,st=ok:
TSP:MSG:SEND 75-75-0-0 s=4,c=0,t=0,pt=0,l=0,sg=0,ft=0,st=ok:
Request registration...
TSP:MSG:SEND 75-75-0-0 s=255,c=3,t=26,pt=1,l=1,sg=0,ft=0,st=ok:2
TSP:MSG:READ 0-0-75 s=255,c=3,t=27,pt=1,l=1,sg=0:1
Node registration=1
Init complete, id=75, parent=0, distance=1, registration=1
TSP:MSG:SEND 75-75-0-0 s=3,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=ok:1
TSP:MSG:SEND 75-75-0-0 s=4,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=ok:1

BUT here the problems begins
I would like to have the nodes get the node id auto assigned - so I removed the node-id assignment, cleared the eeprom (again) and loaded the now competely unchanged binary sensor.
//#define MY_NODE_ID 75
#define MY_NODE_ID AUTO
The result is:
Starting sensor (RNNNA-, 2.0.0)
TSM:INIT
TSM:RADIO:OK
TSM:FPAR
TSP:MSG:SEND 255-255-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSP:MSG:READ 0-0-255 s=255,c=3,t=8,pt=1,l=1,sg=0:0
TSP:MSG:FPAR RES (ID=0, dist=0)
TSP:MSG:PAR OK (ID=0, dist=1)
TSM:FPAR:OK
TSM:ID
TSP:MSG:SEND 255-255-0-0 s=255,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=ok:
TSM:ID
TSP:MSG:SEND 255-255-0-0 s=255,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=ok:
TSM:ID
TSP:MSG:SEND 255-255-0-0 s=255,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=ok:
TSM:ID
TSP:MSG:SEND 255-255-0-0 s=255,c=3,t=3,pt=0,l=0,sg=0,ft=0,st=ok:
!TSM:CHKID:FAIL (ID=255)
!TSM:FAILURE
TSM:PDT

I have looked at this forum and google in general but there are not much v2.0 help to be found. I thought it might be related to inclusion mode - but I have not had success with experimenting with that...

Please help!