Can't get sensors talking

linus72982

I keep having a few problems that I can't figure out. I think they are related, but I'm not entirely sure. I have the Nano Compatible as my serial gateway connected to the NRF24L01+PA+LNA Antenna version radio with a 4.7uf cap (ground connected to the white strip side) using the 2.0 GatewaySerial example (unchanged). I have it shielded the radio with the "ugly fix", the tin foil attached to ground. I checked the pins for continuity, nothing is touching the ground. On the sensor side, I have a pro mini 3.3v connected via the ftdi adapter to another usb port. The radio is the NRF24L01+ 2.4GHz Wireless Transceiver with a 47uf cap (yes, 47 for this and 4.7 for the other, I found references to use both in different places, of course, if my electronics classes serve me, it doesn't matter if I go bigger, it should still work, right?) Connected is a magnetic open/close sensor. This guy is running the 2.0 BinarySwitchSleepSensor (unchanged).

What I've tried: Replacing the pro mini with another, replacing the pro mini's radio (twice), replacing all cables (dupont cables), replacing caps, moving the node further away from the gateway (to the adjacent room).

I don't have a controller, so I've hard-coded (I think) the node ID and parent id with #define MY_NODE_ID 1 and #define MY_PARENT_NODE_ID 0 for the gateway, then the same with node # 3 and parent #1 for the node. The goal is to write my own controller but I need to get these working first.

So, when I start the two monitors up within a few seconds of each other (gateway first), here's the output of the gateway:

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
0;255;3;0;14;Gateway startup complete.
0;255;0;0;18;2.0.0
0;255;3;0;9;No registration required
0;255;3;0;9;Init complete, id=0, parent=0, distance=0, registration=1
0;255;3;0;9;TSP:MSG:READ 3-3-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=3)
0;255;3;0;9;TSP:CHKUPL:OK
0;255;3;0;9;TSP:MSG:GWL OK
0;255;3;0;9;!TSP:MSG:SEND 0-0-3-3 s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=fail:0
0;255;3;0;9;!TSP:SANCHK:FAIL
0;255;3;0;9;!TSM:FAILURE
0;255;3;0;9;TSM:PDT
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

Here was the output of the pro mini over the same time:

Starting sensor (RNNNA-, 2.0.0)
TSM:INIT
TSM:RADIO:OK
TSP:ASSIGNID:OK (ID=3)
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
!TSM:FPAR:FAIL
!TSM:FAILURE
TSM:PDT

To my untrained eye, it looks like the gateway sees the node as it says FPAR req'd sender=3, but then it looks like the fpar fails? I don't even know what FPAR is and I can't find anything on the site that allows me to decode these messages, only the 0;255;3;0;9 which is logging.

Can anyone see what I'm doing incorrectly?

linus72982

Also, after running for a bit, I get this from the gateway:

0;255;3;0;9;TSP:MSG:READ 3-3-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=3)
0;255;3;0;9;TSP:CHKUPL:OK
0;255;3;0;9;TSP:MSG:GWL OK
0;255;3;0;9;!TSP:MSG:SEND 0-0-3-3 s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=fail:0
0;255;3;0;9;!TSP:SANCHK:FAIL
0;255;3;0;9;!TSM:FAILURE
0;255;3;0;9;TSM:PDT
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
0;255;3;0;9;TSP:MSG:READ 3-3-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=3)
0;255;3;0;9;TSP:CHKUPL:OK
0;255;3;0;9;TSP:MSG:GWL OK
0;255;3;0;9;!TSP:MSG:SEND 0-0-3-3 s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=fail:0
0;255;3;0;9;!TSP:SANCHK:FAIL
0;255;3;0;9;!TSM:FAILURE
0;255;3;0;9;TSM:PDT
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
0;255;3;0;9;TSP:MSG:READ 3-3-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=3)
0;255;3;0;9;TSP:CHKUPL:OK
0;255;3;0;9;TSP:MSG:GWL OK
0;255;3;0;9;TSP:MSG:SEND 0-0-3-3 s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=ok:0
0;255;3;0;9;TSP:MSG:READ 3-3-0 s=255,c=3,t=24,pt=1,l=1,sg=0:1
0;255;3;0;9;TSP:MSG:PINGED (ID=3, hops=1)
0;255;3;0;9;TSP:MSG:SEND 0-0-3-3 s=255,c=3,t=25,pt=1,l=1,sg=0,ft=0,st=ok:1
0;255;3;0;9;TSP:MSG:READ 3-3-0 s=255,c=3,t=15,pt=6,l=2,sg=0:0100
0;255;3;0;9;!TSP:MSG:SEND 0-0-3-3 s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=fail:0100
0;255;3;0;9;TSP:MSG:READ 3-3-0 s=255,c=0,t=17,pt=0,l=5,sg=0:2.0.0
3;255;0;0;17;2.0.0
0;255;3;0;9;TSP:MSG:READ 3-3-0 s=255,c=3,t=6,pt=1,l=1,sg=0:0
3;255;3;0;6;0
0;255;3;0;9;TSP:MSG:READ 3-3-0 s=255,c=3,t=11,pt=0,l=13,sg=0:Binary Sensor
3;255;3;0;11;Binary Sensor
0;255;3;0;9;!TSP:SANCHK:FAIL
0;255;3;0;9;!TSM:FAILURE
0;255;3;0;9;TSM:PDT
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
0;255;3;0;9;TSP:SANCHK:OK
0;255;3;0;9;TSP:SANCHK:OK
0;255;3;0;9;TSP:SANCHK:OK
0;255;3;0;9;TSP:SANCHK:OK
0;255;3;0;9;TSP:SANCHK:OK
0;255;3;0;9;TSP:SANCHK:OK
0;255;3;0;9;TSP:SANCHK:OK
0;255;3;0;9;TSP:SANCHK:OK

and this from the pro mini:

TSM:INIT
TSM:RADIO:OK
TSP:ASSIGNID:OK (ID=3)
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
!TSM:FPAR:FAIL
!TSM:FAILURE
TSM:PDT
TSM:INIT
TSM:RADIO:OK
TSP:ASSIGNID:OK (ID=3)
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
!TSM:FPAR:FAIL
!TSM:FAILURE
TSM:PDT
TSM:INIT
TSM:RADIO:OK
TSP:ASSIGNID:OK (ID=3)
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
!TSM:FPAR:FAIL
!TSM:FAILURE
TSM:PDT
TSM:INIT
TSM:RADIO:OK
TSP:ASSIGNID:OK (ID=3)
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
!TSM:FPAR:FAIL
!TSM:FAILURE
TSM:PDT
TSM:INIT
TSM:RADIO:OK
TSP:ASSIGNID:OK (ID=3)
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSP:MSG:READ 0-0-3 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=3)
TSM:UPL
TSP:PING:SEND (dest=0)
TSP:MSG:SEND 3-3-0-0 s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=ok:1
TSP:MSG:READ 0-0-3 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 3-3-0-0 s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=ok:0100
TSP:MSG:SEND 3-3-0-0 s=255,c=0,t=17,pt=0,l=5,sg=0,ft=0,st=ok:2.0.0
TSP:MSG:SEND 3-3-0-0 s=255,c=3,t=6,pt=1,l=1,sg=0,ft=0,st=ok:0
!TSP:MSG:SEND 3-3-0-0 s=255,c=3,t=11,pt=0,l=13,sg=0,ft=0,st=fail:Binary Sensor
!TSP:MSG:SEND 3-3-0-0 s=255,c=3,t=12,pt=0,l=3,sg=0,ft=1,st=fail:1.0
!TSP:MSG:SEND 3-3-0-0 s=3,c=0,t=0,pt=0,l=0,sg=0,ft=2,st=fail:
!TSP:MSG:SEND 3-3-0-0 s=4,c=0,t=0,pt=0,l=0,sg=0,ft=3,st=fail:
Request registration...
!TSP:MSG:SEND 3-3-0-0 s=255,c=3,t=26,pt=1,l=1,sg=0,ft=4,st=fail:2
!TSP:MSG:SEND 3-3-0-0 s=255,c=3,t=26,pt=1,l=1,sg=0,ft=5,st=fail:2
!TSM:UPL FAIL, SNP
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
!TSP:SEND:TNR
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
!TSP:SEND:TNR
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
Init complete, id=3, parent=255, distance=255, registration=1
!TSP:SEND:TNR
!TSP:SEND:TNR
!TSP:SEND:TNR
!TSP:SEND:TNR
!TSP:SEND:TNR
!TSP:SEND:TNR
!TSP:SEND:TNR
!TSP:SEND:TNR

the !TSP:SEND:TNR messages at the end happen each time I open or close the sensor.

tekka

@linus72982 looks like you have an issue with your GW radio:

0;255;3;0;9;!TSP:SANCHK:FAIL

GW and repeater nodes have by default regular sanity checks enabled. In your case, the sanity check fails, most likely due to cable and/or power issues. Try fixing/reseating the radio cables and/or add a larger cap to the GW radio.

Also, please post the node sketch for further analysis.

As for the debug messages, here the most important ones:

TSM:FPAR => Transport State Machine:Find PARent
!TSM:UPL FAIL, SNP => Uplink failed, Search New Parent
!TSP:SEND:TNR => Transport:SEND:Transport Not Ready
TSM:PDT => PowerDown Transport

I'm currently working on a PR to unify and document all transport debug log messages for troubleshooting

In your case, this is what happened:

Node initializes and assigns ID 3, then it fails to find a parent...

TSM:INIT
TSM:RADIO:OK
TSP:ASSIGNID:OK (ID=3)
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
!TSM:FPAR:FAIL
!TSM:FAILURE
TSM:PDT

Later on it receives a response to the find parent request from node ID 0 (=GW)

TSP:MSG:FPAR RES (ID=0, dist=0)
TSP:MSG:PAR OK (ID=0, dist=1)
TSM:FPAR:OK

and finally, the TSM is fully operational.

TSM:READY

Then the node starts sending the presentation messages...


TSP:MSG:SEND 3-3-0-0 s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=ok:0100
TSP:MSG:SEND 3-3-0-0 s=255,c=0,t=17,pt=0,l=5,sg=0,ft=0,st=ok:2.0.0
TSP:MSG:SEND 3-3-0-0 s=255,c=3,t=6,pt=1,l=1,sg=0,ft=0,st=ok:0

...and fails again to (successfully) send the messages to the GW

!TSP:MSG:SEND 3-3-0-0 s=255,c=3,t=11,pt=0,l=13,sg=0,ft=0,st=fail:Binary Sensor
!TSP:MSG:SEND 3-3-0-0 s=255,c=3,t=12,pt=0,l=3,sg=0,ft=1,st=fail:1.0
!TSP:MSG:SEND 3-3-0-0 s=3,c=0,t=0,pt=0,l=0,sg=0,ft=2,st=fail:
!TSP:MSG:SEND 3-3-0-0 s=4,c=0,t=0,pt=0,l=0,sg=0,ft=3,st=fail:

Hence, start searching for a new parent...

!TSM:UPL FAIL, SNP
TSM:FPAR
TSP:MSG:SEND 3-3-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:

...and (again) no reply from the GW, therefore...

!TSP:SEND:TNR

Transport not ready, and starting from the beginning...

sundberg84

@tekka - i get this:

TSM:FPAR
TSP:MSG:SEND 12-12-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSP:MSG:READ 0-0-12 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)
TSP:MSG:READ 101-101-12 s=255,c=3,t=8,pt=1,l=1,sg=0:1
TSP:MSG:FPAR RES (ID=101, dist=1)
TSP:MSG:READ 99-99-12 s=255,c=3,t=8,pt=1,l=1,sg=0:1
TSP:MSG:FPAR RES (ID=99, dist=1)
TSP:MSG:READ 100-100-12 s=255,c=3,t=8,pt=1,l=1,sg=0:1
TSP:MSG:FPAR RES (ID=100, dist=1)
TSM:FPAR:OK
TSM:ID
TSM:CHKID:OK (ID=12)
TSM:UPL
TSP:PING:SEND (dest=0)
TSP:MSG:SEND 12-12-0-0 s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=ok:1
TSP:CHKUPL:FAIL (hops=255)
!TSM:UPL:FAIL

in an endless repeat.

What does it mean?

This is the same code as before - cleared eeprom and uploaded to a working node, only change is 2.0 lib.
My guess is that I need to update the repeater/gw as well? They are running 2.0 beta.

Yveaux

@sundberg84 said:

My guess is that I need to update the repeater/gw as well? They are running 2.0 beta.

Start with that indeed.
2.0.0 sensors require repeaters and gateway to also run 2.0.0

sundberg84

@Yveaux will do but I would like to know what that error message is if possible.

Yveaux

@sundberg84 you will when @tekka finishes his documentation .
Give him a break; I rather have him documenting the new stuff than answering all those individual questions :smirk:

sundberg84

@Yveaux - I have missed this info about document. I will revert everything back then until proper documentation is finished.

Its hen and a egg problem... if documentation was finished before release all the questions could be avoided.

tekka

@sundberg84 We do not recommend nor have the bandwidth to support and troubleshoot setups with mixed MySensors versions (i.e. 1.x and 2.x). That said, mixed setups can but are not guaranteed to function. As semantic versioning suggests, a major version increment implies API changes that are not backwards compatible: For a full list of changes in 2.0.0, please refer to the change log.

In your case, update all nodes/GW/repeaters to the most recent MySensors version, and report back if you encounter any issues.

As @Yveaux pointed out, I am working on a PR that unifies and documents all debug messages emitted from the transport layer.

sundberg84

@tekka - ok, thanks @tekka. I have 25+ nodes so I guess I have some work then
.. or maybe I'll just stick to 2.0b.

tekka

@sundberg84 Wow, how is the topology?

sundberg84

@tekka -

GW - 2.0b
3x Repeaters (combined with motion) - 2.0b
Nodes about 50% 1.4-1.5 and 50% 2.0b

but nevermind, I will hold on to your document is finished - no worries. I was just to eager to upgrade :)
Then I will try to upgrade the gw and see what happens.

linus72982

@tekka
Thanks for the explanation of the messages, that helped me quite a bit. I figured out that my gateway radio wasn't working very well so I bought an Addicore version that the reviews said was a bit more reliable. It came in today and works like a champ (and it has labeled pins which is helpful).

I eagerly await the documentation of the messages. I am writing a controller in Python and with my limited C knowledge (weird, I know, as Python is a C-based language, but it's just different enough to drive me nuts), I'm going cross-eyed trying to reverse-engineer the messages from the code. Your documentation will help immensely. Just the bit you told me up there has allowed me to write most of it. Thanks, again.

tekka

@linus72982 You'll find some more information here. This is a PR (still WIP) for the dev branch and applies to the upcoming 2.0.1 release.

linus72982

@tekka
That's good info, thank you. Quick question if you have a minute, what is the difference between CHKUPL and SANCHK? Based on the docs, they both seem to accomplish the same goal.

tekka

@linus72982 No, they do different things: CHKUPL checks the uplink, i.e. connection to GW whereas SANCHK is the regular radio HW sanity check (radio register verification + SPI connection).

alexsh1

@tekka Can we please get your info about deciphering the log in v.2 into a separate sticky thread in the Troubleshooting section?
Thank you very much for producing it

tekka

@alexsh1 The debug log messages are fully documented in the upcoming 2.0.1 release, see here for a preview (dev): https://ci.mysensors.org/job/Verifiers/job/MySensorsArduinoLibPR/Doxygen_HTML/

Yveaux

@alexsh1 more explicitly, a description of the transport state machine messages (TSM) can be found here: https://ci.mysensors.org/job/Verifiers/job/MySensorsArduinoLibPR/Doxygen_HTML/

tekka

@Yveaux @alexsh1 https://ci.mysensors.org/job/Verifiers/job/MySensorsArduinoLibPR/Doxygen_HTML/group__MyTransportgrp.html

Can't get sensors talking

13

11.7k

11.2k

113.0k