3. Can't get sensors talking

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?

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

    0 tekka 1 Reply
  • tekka
    Admin

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

    1. 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
    1. 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
    1. and finally, the TSM is fully operational.
    TSM:READY
    1. 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
    1. ...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:
    1. 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:
    1. ...and (again) no reply from the GW, therefore...
    !TSP:SEND:TNR
    1. Transport not ready, and starting from the beginning...
    5 linus72982 alexsh1 2 Replies
  • sundberg84
    Hardware Contributor

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

    0 Yveaux tekka 2 Replies
  • Yveaux
    Mod

    @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

    0 sundberg84 1 Reply
  • sundberg84
    Hardware Contributor

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

    0 Yveaux 1 Reply
  • Yveaux
    Mod

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

    1 sundberg84 1 Reply
  • sundberg84
    Hardware Contributor

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

    0
  • tekka
    Admin

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

    1 sundberg84 1 Reply
  • sundberg84
    Hardware Contributor

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

    0 tekka 1 Reply
  • tekka
    Admin

    @sundberg84 Wow, how is the topology?

    0
  • sundberg84
    Hardware Contributor

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

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

    0 tekka 1 Reply
  • tekka
    Admin

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

    0 linus72982 1 Reply
  • 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.

    0 tekka 1 Reply
  • tekka
    Admin

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

    0
  • 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

    0 tekka 1 Reply
  • tekka
    Admin

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

    1 Yveaux 1 Reply
  • Yveaux
    Mod

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

    0 tekka 1 Reply
  • tekka
    Admin

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

    0 Yveaux 1 Reply
  • Yveaux
    Mod

    @tekka ehhhrrfmmm... Copy/paste on Android didn't work as expected.... Sorry

    0
  • Cravecode

    This post is deleted!
    0
  • Quinie

    Hi All

    I am working on the version 2 for the first time after being away for awhile.
    The gateway is up and running.

    8-10-2016 02:45:07	RX	0;255;3;0;9;TSP:SANCHK:OK

    But my sensors is giving problems.

    TSM:INIT
TSM:RADIO:OK
TSP:ASSIGNID:OK (ID=188)
TSM:FPAR
TSP:MSG:SEND 188-188-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSM:FPAR
TSP:MSG:SEND 188-188-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSM:FPAR
TSP:MSG:SEND 188-188-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
TSM:FPAR
TSP:MSG:SEND 188-188-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

    I have a 4,7 capacitor in place. Any ideas?

    0
  • Quinie

    Changed the arduino.. not the radio .. from UNO to Nano (not the sensor but the gateway).. now it works...

    0
Log in to reply
 

Suggested Topics

  • hek


    Announcements •  

    3
  • se-O-matic


    Troubleshooting •  

    5
  • Gibber


    Troubleshooting •  

    1
  • kamilb85


    Troubleshooting •  

    2
  • Gibber


    Troubleshooting •  

    8

0
Online

11.4k
Users

11.1k
Topics

112.7k
Posts



Copyright 2019 Sensnology   |   Forum Guidelines   |   Privacy Policy   |   Terms of Service