Node doesn't work without repeater



  • Hello everybody!

    Please, I need an inspiration!
    I've got several nodes around my appartment: three temp/humidity sensors, double relay, door.
    I have built another relay node to hack my ikea floor lamp. It's working fine, and it has a default repeater feature. Now I have built another door sensor. It is a MySensors Stable node with MYS 1.3 bootloader. It's working through the node 10 (floor lamp). When I turn the lamp off to get rid of the repeater node the new door sensor (node 2) stops working. If I reboot it manually it doesn't find parent (I want it to be the gateway). I tried to assign manual parent ID 0 but it doesn't help.
    How do I make it work without the repeater? I want it to work in another room.

    P.S. I tried to clear eeprom, then flash the firmware, assign parent ID manually, rebooting it without repeater turned on, rebooted it near another repeater (double relay). Oh, I forgot to tell, the gateway is closer to the node then the repeater node 10.


  • Hardware Contributor

    @Tigroenot - sounds like the right steps... strange.
    Any code or serial output from the node so we can see what happens when it boots?



  • @sundberg84 thanks for quick response.
    Here is the serial output of the node when the repeater node 10 is on:

    0 MCO:BGN:INIT NODE,CP=RNNNA--,VER=2.1.0-beta
    4 TSM:INIT
    4 TSF:WUR:MS=0
    12 TSM:INIT:TSP OK
    14 TSF:SID:OK,ID=2
    16 TSM:FPAR
    53 TSF:MSG:SEND,2-2-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
    1507 TSF:MSG:READ,10-10-2,s=255,c=3,t=8,pt=1,l=1,sg=0:1
    1513 TSF:MSG:FPAR OK,ID=10,D=2
    2060 TSM:FPAR:OK
    2060 TSM:ID
    2062 TSM:ID:OK
    2064 TSM:UPL
    2068 TSF:MSG:SEND,2-2-10-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:1
    2125 TSF:MSG:READ,0-10-2,s=255,c=3,t=25,pt=1,l=1,sg=0:2
    2131 TSF:MSG:PONG RECV,HP=2
    2136 TSM:UPL:OK
    2136 TSM:READY:ID=2,PAR=10,DIS=2
    2142 TSF:MSG:SEND,2-2-10-0,s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=OK:0100
    2191 TSF:MSG:READ,0-10-2,s=255,c=3,t=15,pt=6,l=2,sg=0:0100
    2199 TSF:MSG:SEND,2-2-10-0,s=255,c=0,t=17,pt=0,l=10,sg=0,ft=0,st=OK:2.1.0-beta
    2209 TSF:MSG:SEND,2-2-10-0,s=255,c=3,t=6,pt=1,l=1,sg=0,ft=0,st=OK:10
    2342 TSF:MSG:READ,0-10-2,s=255,c=3,t=6,pt=0,l=1,sg=0:M
    2351 TSF:MSG:SEND,2-2-10-0,s=255,c=3,t=11,pt=0,l=13,sg=0,ft=0,st=OK:Binary Sensor
    2361 TSF:MSG:SEND,2-2-10-0,s=255,c=3,t=12,pt=0,l=3,sg=0,ft=0,st=OK:1.1
    2371 TSF:MSG:SEND,2-2-10-0,s=3,c=0,t=0,pt=0,l=0,sg=0,ft=0,st=OK:
    2377 MCO:REG:REQ
    2396 TSF:MSG:SEND,2-2-10-0,s=255,c=3,t=26,pt=1,l=1,sg=0,ft=0,st=OK:2
    2500 TSF:MSG:READ,0-10-2,s=255,c=3,t=27,pt=1,l=1,sg=0:1
    2506 MCO:PIM:NODE REG=1
    2508 MCO:BGN:STP
    2510 MCO:BGN:INIT OK,TSP=1
    2514 MCO:SLP:MS=5,SMS=0,I1=255,M1=255,I2=255,M2=255
    2519 MCO:SLP:TPD
    2521 MCO:SLP:WUP=-1
    2525 TSF:MSG:SEND,2-2-10-0,s=3,c=1,t=16,pt=1,l=1,sg=0,ft=0,st=OK:1
    2533 MCO:SLP:MS=5,SMS=0,I1=255,M1=255,I2=255,M2=255
    2539 MCO:SLP:TPD
    2539 MCO:SLP:WUP=-1
    2545 TSF:MSG:SEND,2-2-10-0,s=255,c=3,t=0,pt=1,l=1,sg=0,ft=0,st=OK:100
    2553 MCO:SLP:MS=0,SMS=0,I1=1,M1=1,I2=255,M2=255
    2557 MCO:SLP:TPD
    2560 MCO:SLP:WUP=1
    2562 MCO:SLP:MS=5,SMS=0,I1=255,M1=255,I2=255,M2=255
    2568 MCO:SLP:TPD
    2570 MCO:SLP:WUP=-1
    2572 MCO:SLP:MS=5,SMS=0,I1=255,M1=255,I2=255,M2=255
    2578 MCO:SLP:TPD
    2578 MCO:SLP:WUP=-1
    2582 MCO:SLP:MS=0,SMS=0,I1=1,M1=1,I2=255,M2=255
    2586 MCO:SLP:TPD```


  • @sundberg84 Adn here is the serial output of the node 2 when the repeater node 10 is off:

    Here is the serial output of the node 2 when the repeater node 10 is off:

    0 MCO:BGN:INIT NODE,CP=RNNNA--,VER=2.1.0-beta
    4 TSM:INIT
    4 TSF:WUR:MS=0
    12 TSM:INIT:TSP OK
    14 TSF:SID:OK,ID=2
    16 TSM:FPAR
    53 TSF:MSG:SEND,2-2-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
    2060 !TSM:FPAR:NO REPLY
    2062 TSM:FPAR
    2099 TSF:MSG:SEND,2-2-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
    4108 !TSM:FPAR:NO REPLY
    4110 TSM:FPAR
    4147 TSF:MSG:SEND,2-2-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
    6156 !TSM:FPAR:NO REPLY
    6158 TSM:FPAR
    6195 TSF:MSG:SEND,2-2-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
    8204 !TSM:FPAR:FAIL
    8206 TSM:FAIL:CNT=1
    8208 TSM:FAIL:PDT
    18212 TSM:FAIL:RE-INIT
    18214 TSM:INIT
    18221 TSM:INIT:TSP OK
    18225 TSF:SID:OK,ID=2
    18227 TSM:FPAR
    18264 TSF:MSG:SEND,2-2-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
    20273 !TSM:FPAR:NO REPLY
    20275 TSM:FPAR
    20312 TSF:MSG:SEND,2-2-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
    22321 !TSM:FPAR:NO REPLY
    22323 TSM:FPAR
    22360 TSF:MSG:SEND,2-2-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
    24369 !TSM:FPAR:NO REPLY
    24371 TSM:FPAR
    24408 TSF:MSG:SEND,2-2-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
    26417 !TSM:FPAR:FAIL
    26419 TSM:FAIL:CNT=2
    26421 TSM:FAIL:PDT
    36425 TSM:FAIL:RE-INIT```


  • Please, explain it to me, shouldn't the node find another parent if the repeater is offline? Shouldn't the gateway reply to FPAR request? The range is really not the issue because I've got a PA+LNA nrf module on the gateway, and it is 4 meters away from the node 2.
    Maybe I should move to the stable branch? 🙂


  • Hardware Contributor

    @Tigroenot said in Node doesn't work without repeater:

    Please, explain it to me, shouldn't the node find another parent if the repeater is offline?

    It should - and I think the limit (was before atleast) is 6 failed messages and the it should search a new way/route.

    It looks like it does try to find a new way (2-2-255 instead of 2-2-10) but doesnt get a reply. Maybe the routing table in the GW still is going trhough the repeater?



  • @sundberg84 said in Node doesn't work without repeater:

    @Tigroenot said in Node doesn't work without repeater:

    Please, explain it to me, shouldn't the node find another parent if the repeater is offline?

    It should - and I think the limit (was before atleast) is 6 failed messages and the it should search a new way/route.

    It looks like it does try to find a new way (2-2-255 instead of 2-2-10) but doesnt get a reply. Maybe the routing table in the GW still is going trhough the repeater?

    The repeater is fisically off. I can see the routing table through the MYSController. Tried to clear it - doesn't seem to work.

    Here is another attempt. I downloaded the latest stable 2.1.1 and here is the output:

    0 MCO:BGN:INIT NODE,CP=RNNNA--,VER=2.1.1
    4 TSM:INIT
    4 TSF:WUR:MS=0
    12 TSM:INIT:TSP OK
    14 TSF:SID:OK,ID=2
    16 TSM:FPAR
    16 TSM:FPAR:STATP=0
    18 TSM:ID
    20 TSM:ID:OK
    20 TSM:UPL
    59 !TSF:MSG:SEND,2-2-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=NACK:1
    2066 TSM:UPL
    2103 !TSF:MSG:SEND,2-2-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=1,st=NACK:1
    4112 TSM:UPL
    4149 !TSF:MSG:SEND,2-2-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=2,st=NACK:1
    6158 TSM:UPL
    6195 !TSF:MSG:SEND,2-2-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=3,st=NACK:1
    8204 !TSM:UPL:FAIL
    
    475289 TSM:FPAR
    475291 TSM:FPAR:STATP=0
    475293 TSM:ID
    475295 TSM:ID:OK
    475297 TSM:UPL
    475334 !TSF:MSG:SEND,2-2-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=8,st=NACK:1
    475770 TSF:MSG:READ,12-12-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
    475779 TSF:MSG:BC
    477343 TSM:UPL
    477380 !TSF:MSG:SEND,2-2-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=9,st=NACK:1
    477872 TSF:MSG:READ,12-12-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
    477878 TSF:MSG:BC
    479389 TSM:UPL
    479426 !TSF:MSG:SEND,2-2-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=10,st=NACK:1
    479977 TSF:MSG:READ,12-12-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
    479983 TSF:MSG:BC
    481435 TSM:UPL
    481472 !TSF:MSG:SEND,2-2-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=11,st=NACK:1
    483481 !TSM:UPL:FAIL```


  • 0_1493559720612_Screen.png


  • Mod

    If you bring the node closer to the gateway? Maybe it is not able to reach it without the repeater


  • Hardware Contributor

    @Tigroenot it looks like you have alot of :NACK which means you have a range problem (or power) and the node with ID 2 does not get a reply (ack) from the GW. Still my last question - even if you clear the routing table/eeprom in the node it might that it takes a while for th gw to update its routing table? Im not sure how this works "behind the scenes" since im not of a coding guy,



  • The range is not the issue because I tried to move it closer to the gateway, but untill I power on the repeater node it didn't work.

    I sent C_INTERNAL, I_DEBUG, E to node 10, is has reset it's ID and became no 11, and after that nodes 2 and 12 starter to work through node 11. Damn it. I reset the ID of node 2, it became node 8 and continued to work through node 11. Sh*t!
    Now I've got two nodes that just want that bloody repeater node 11 and don't want to deal with the filthy gateway 🙂


  • Mod

    Did you restarted the gateway so that all nodes presented again? It is actually kind of weird since quite some people had issues about the nodes trying to connect to low signal gateway even if repeater had better signal.



  • @gohan said in Node doesn't work without repeater:

    Did you restarted the gateway so that all nodes presented again? It is actually kind of weird since quite some people had issues about the nodes trying to connect to low signal gateway even if repeater had better signal.

    Not only have I restarted the gateway, I have reinstalled it, now it's latest development branch.
    Now I have built one more node, burned the same 1.3 MYSBootloader, and it doesn't show up on the network at all. Static parent ID and set node ID don't do a thing.

    314689 TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
    316700 !TSM:FPAR:NO REPLY
    316702 TSM:FPAR
    

    The gateway works normally, it gets the data from similar nodes that are further that this new one... I'm very confused...

    Maybe it's somethig to do with the nrf chanels? MYSBootloader? All my nodes are the same...


  • Mod

    NRF channels can be manually defined if you want to try (default channel is something like 76, I set it to 10 to move it away from wifi frequencies), but if you change the values in the MyConfig.h file you will get the same settings an all builds (just remember it will get overwritten if you up\downgrade the library. I am taking for granted you have capacitors on the radio vcc, right? Did you try to swap radios around, just to see if anything happens?



  • Well, what I did is swaped the radio on the gateway, added capacitors (10-200uf), swaped the nrf chip on the nodes (nrf+ and nrf), added 1M resistor to the node for radio back compatibility, moved nodes closer to the gateway and further from it, flashed the repeater node (now it's node 10 again) with repeater function disabled.

    In the end, I've got three new nodes that talk to controller ONLY through repeater node (the repeater node is further from the gateway then the new nodes). Clearing the routing table on the repeater node doesn't help, erasing eeprom of the repeater node makes it change the node ID and after restarting the other nodes they bind to the repeater again.
    Strange thing is that the node 10 is with MYSBootloader (which has nrf chanel 76 set) and it talks straight to the gateway. The nodes (8,12,13) have the same bootloader and nrf chanel set to 76 and are not recognised by the gateway as soon as there is no repeater node 10.


  • Mod

    I am out of options.... I am calling for @hek help 😄


  • Admin

    Try setting

    #define MY_RF24_PA_LEVEL RF24_PA_LOW

    on the gateway

    The gateway might be SCREAMING so high that the node doesn't pick up the answer.


Log in to reply
 

Suggested Topics

54
Online

11.4k
Users

11.1k
Topics

112.7k
Posts