Repeater drops nodes

  • So, to try to solve the range issues of the NRF24 node networks deployed inside masonry-mortar buildings, i've setup a repeater on my first floor. I have a serial gateway with an amplified NRF24 at the groundfloor and a node that works normally.
    At the first floor i have 2 nodes (temp+hum) where only one is able to connect to the gateway in this normal setup. Ive then installed a repeater with a fixed ID which gets connection to the gateway without problems.
    Ive then forced the nodes at the first floor to connect to the repeater with:

    #define MY_PARENT_NODE_ID 51           

    Everything works ok for an hour or so, and then i begin to notice in Domoticz that the time the nodes were "seen" starts to be 20, 30, 50 minutes without reporting the readings and i get the info on my nodes that transportCheckUplink() is false. If i restart the repeater, everything starts to work but the same issue happens again… Has anyone come across something similar? Ive checked the log of the repeater but since this issue takes a bit of time to show up, ill need to plug it to a laptop and collect the full log.

    Im now trying to setup one of the temp+hum nodes also as a repeater, but since my nodes have a small OLED im trying to implement a delayed display update since ive removed the "sleep" function. I hope this doesnt spam the gateway…

    As always, any insights are more than welcome.
    Thank you.

  • Hardware Contributor

    @titvs did you try to set my_parenr_node_id (gateway = 0) on the repeater? I had some similar issues but I upgraded from 2.2 to 2.3 in the same time so can't tell if it was a version mismatch or that the parent setting helped.

  • @sundberg84 hmmm, nope… I only have this line:

    #define MY_NODE_ID 51 

    So you're saying you've solved your problem by also adding:

    #define MY_PARENT_NODE_ID 0 

    At the repeater?

  • Hardware Contributor

    @titvs yes, I'm saying it's worth a try... I made some other changes so can't promise.

  • Well, that didn’t solve it... got both nodes disconnected as before. It seems the repeater hangs for some reason...

    I’ve also noticed that the “last seen” time for the repeater that appears in Domoticz is the time it was powered up and presented to the gateway. It doesn’t get updated.

    I guess the only way to debug this is to collect all the log from the repeater until the nodes get disconnected...

  • Hardware Contributor

    @titvs well, its good you figured out its the repeater hanging. Maybe you should look over the hardware? I would suggest trying swapping the capacitor and/or radio. Looking over the nodes debug output is a great idea, but if it just hangs it will not give you anything (unless its a software issue). If so, as I said try first to change the capacitor, maybe try another value (ie if you are using 4,7uF you can try 10uF or 47uF). It can also be good to try another power supply.

    How do you power the repeater at the moment? How do you get it to 3.3v? Are you using a strong enough voltage regulator?

  • @sundberg84 well, the repeater doesnt "hang" on the literal sense. Here is the initial log from it with the initialization and the acknowledge of one of the nodes:

    26 TSM:INIT
    27 TSF:WUR:MS=0
    37 TSF:SID:OK,ID=51
    39 TSM:FPAR
    43 TSM:ID
    44 TSM:ID:OK
    45 TSM:UPL
    48 TSF:MSG:SEND,51-51-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:1
    59 TSF:MSG:READ,0-0-51,s=255,c=3,t=25,pt=1,l=1,sg=0:1
    66 TSM:UPL:OK
    68 TSM:READY:ID=51,PAR=0,DIS=1
    97 TSF:MSG:SEND,51-51-0-0,s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=OK:0100
    114 TSF:MSG:READ,0-0-51,s=255,c=3,t=15,pt=6,l=2,sg=0:0100
    147 TSF:MSG:SEND,51-51-0-0,s=255,c=0,t=18,pt=0,l=5,sg=0,ft=0,st=OK:2.3.0
    155 TSF:MSG:SEND,51-51-0-0,s=255,c=3,t=6,pt=1,l=1,sg=0,ft=0,st=OK:0
    175 TSF:MSG:READ,0-0-51,s=255,c=3,t=6,pt=0,l=1,sg=0:M
    212 TSF:MSG:SEND,51-51-0-0,s=255,c=3,t=11,pt=0,l=13,sg=0,ft=0,st=OK:Repeater Node
    222 TSF:MSG:SEND,51-51-0-0,s=255,c=3,t=12,pt=0,l=3,sg=0,ft=0,st=OK:1.0
    228 MCO:REG:REQ
    232 TSF:MSG:SEND,51-51-0-0,s=255,c=3,t=26,pt=1,l=1,sg=0,ft=0,st=OK:2
    242 TSF:MSG:READ,0-0-51,s=255,c=3,t=27,pt=1,l=1,sg=0:1
    247 MCO:PIM:NODE REG=1
    249 MCO:BGN:STP
    22758 TSF:MSG:READ,2-2-0,s=255,c=3,t=24,pt=1,l=1,sg=0:1
    22763 TSF:MSG:REL MSG
    22765 TSF:MSG:REL PxNG,HP=1
    22770 TSF:MSG:SEND,2-51-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:2
    22781 TSF:MSG:READ,0-0-2,s=255,c=3,t=25,pt=1,l=1,sg=0:1
    22787 TSF:MSG:REL MSG
    22789 TSF:MSG:REL PxNG,HP=1
    22793 TSF:MSG:SEND,0-51-2-2,s=255,c=3,t=25,pt=1,l=1,sg=0,ft=0,st=OK:2
    22799 TSF:MSG:READ,2-2-0,s=255,c=3,t=15,pt=6,l=2,sg=0:0100
    22805 TSF:MSG:REL MSG
    22817 TSF:MSG:SEND,2-51-0-0,s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=OK:0100
    22824 TSF:MSG:READ,0-0-2,s=255,c=3,t=25,pt=1,l=1,sg=0:1
    22830 TSF:MSG:REL MSG
    22832 TSF:MSG:REL PxNG,HP=1
    22857 TSF:MSG:SEND,0-51-2-2,s=255,c=3,t=25,pt=1,l=1,sg=0,ft=0,st=OK:2
    22864 TSF:MSG:READ,0-0-2,s=255,c=3,t=15,pt=6,l=2,sg=0:0100
    22870 TSF:MSG:REL MSG
    22874 TSF:MSG:SEND,0-51-2-2,s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=OK:0100
    22880 TSF:MSG:READ,0-0-2,s=255,c=3,t=15,pt=6,l=2,sg=0:0100
    22885 TSF:MSG:REL MSG
    22889 TSF:MSG:SEND,0-51-2-2,s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=OK:0100
    22896 TSF:MSG:READ,2-2-0,s=255,c=0,t=17,pt=0,l=5,sg=0:2.3.0
    22901 TSF:MSG:REL MSG
    22905 TSF:MSG:SEND,2-51-0-0,s=255,c=0,t=17,pt=0,l=5,sg=0,ft=0,st=OK:2.3.0
    22913 TSF:MSG:READ,2-2-0,s=255,c=3,t=6,pt=1,l=1,sg=0:51
    22918 TSF:MSG:REL MSG
    22921 TSF:MSG:SEND,2-51-0-0,s=255,c=3,t=6,pt=1,l=1,sg=0,ft=0,st=OK:51
    22936 TSF:MSG:READ,0-0-2,s=255,c=3,t=6,pt=0,l=1,sg=0:M
    22941 TSF:MSG:REL MSG
    22979 !TSF:MSG:SEND,0-51-2-2,s=255,c=3,t=6,pt=0,l=1,sg=0,ft=0,st=NACK:M
    22986 TSF:MSG:READ,2-2-0,s=255,c=3,t=11,pt=0,l=12,sg=0:TEMPHUM_OLED
    22992 TSF:MSG:REL MSG
    23035 !TSF:MSG:SEND,2-51-0-0,s=255,c=3,t=11,pt=0,l=12,sg=0,ft=0,st=NACK:TEMPHUM_OLED
    23044 TSF:MSG:READ,2-2-0,s=255,c=3,t=12,pt=0,l=3,sg=0:1.2
    23049 TSF:MSG:REL MSG
    23053 TSF:MSG:SEND,2-51-0-0,s=255,c=3,t=12,pt=0,l=3,sg=0,ft=1,st=OK:1.2
    23059 TSF:MSG:READ,2-2-0,s=0,c=0,t=7,pt=0,l=0,sg=0:
    23064 TSF:MSG:REL MSG
    23067 TSF:MSG:SEND,2-51-0-0,s=0,c=0,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
    23073 TSF:MSG:READ,2-2-0,s=1,c=0,t=6,pt=0,l=0,sg=0:
    23078 TSF:MSG:REL MSG
    23083 TSF:MSG:SEND,2-51-0-0,s=1,c=0,t=6,pt=0,l=0,sg=0,ft=0,st=OK:
    25023 TSF:MSG:READ,2-2-0,s=255,c=3,t=26,pt=1,l=1,sg=0:2
    25028 TSF:MSG:REL MSG
    25032 TSF:MSG:SEND,2-51-0-0,s=255,c=3,t=26,pt=1,l=1,sg=0,ft=0,st=OK:2
    25039 TSF:MSG:READ,0-0-2,s=255,c=3,t=27,pt=1,l=1,sg=0:1
    25044 TSF:MSG:REL MSG
    25074 TSF:MSG:SEND,0-51-2-2,s=255,c=3,t=27,pt=1,l=1,sg=0,ft=0,st=OK:1
    27297 TSF:MSG:READ,2-2-0,s=1,c=1,t=0,pt=7,l=5,sg=0:25.8
    27302 TSF:MSG:REL MSG
    27307 TSF:MSG:SEND,2-51-0-0,s=1,c=1,t=0,pt=7,l=5,sg=0,ft=0,st=OK:25.8
    27314 TSF:MSG:READ,2-2-0,s=0,c=1,t=1,pt=7,l=5,sg=0:50.2

    When the nodes give the "disconnected" signal, the log from the repeater gives this block over and over:

    11917643 TSF:MSG:REL MSG
    11917645 TSF:MSG:REL PxNG,HP=1
    11917649 TSF:MSG:SEND,2-51-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:2
    11919709 TSF:MSG:READ,2-2-0,s=255,c=3,t=24,pt=1,l=1,sg=0:1

    I cant see anything on the log that the repeater lost connection to the gateway so i guess its not a radio problem. But answering your question, when i collected the log, the repeater (arduino nano) was connected/powered via a USB 3.0 port and the NRF was power by the 3v3 pin.

    Im now collection the log from one of the nodes to see what it gives.


  • Ive been digging around the node logs and i got this after a while:

    964878 TSF:PNG:SEND,TO=0
    964882 TSF:MSG:SEND,3-3-51-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:1
    964917 TSF:MSG:READ,0-51-3,s=255,c=3,t=25,pt=1,l=1,sg=0:2
    964922 TSF:MSG:PONG RECV,HP=2
    964925 TSF:CKU:OK
    964969 !TSF:MSG:SEND,3-3-51-0,s=0,c=1,t=1,pt=7,l=5,sg=0,ft=0,st=NACK:48.7

    A bunch of NACK errors and "!TSF:MSG:PONG RECV,INACTIVE". I dont understand why this doesnt happen at the beginning and only after a while (about 16 minutes in this case) and i also dont know if the lack of radio acknowledge is from the repeater to the node or the repeater to the gateway…

    Ive now moved the repeater more closer to the gateway but im still getting:


    Oddly, again after 16 minutes… Im at a loss...

  • Hardware Contributor

    If you have a amplified radio you need a better voltage regulator than the onboard regulator. When the radio transmits it can cause a higher current draw than the regulator can provide.

    I don't know what the logs mean... but try the log parser.

  • I know about the power requirements, but only the gateway is amplified. The repeater i was testing was a normal nano with a NRF24 powered by an original LG USB charger. Thats not the point with this issue.

    What im saying is that seems the repeater stops to relay messages after about 16 minutes and with an almost direct line of sight to the gateway… If i remove the repeater, the node that is about 2 meters further apart from where the repeater was, still gets signal directly from the gateway and it works normally.
    If i put the repeater in between, about 16 minutes later one of the values (temp or hum) doesnt get through to the gateway.

    Ive tested different radios, nanos and power supplies but it seems to be a software issue or somekind of interference… I'll have to equate if i put up more gateways with NRF24's or completely ditch them. They seem not to worth all this hassle even if they are cheaper...

  • Are you running 2.2 or 2.3. I have noticed that repeaters and 2.3 just do not seem to work. I have three gateways and various repeaters around my place and over 20 nodes and have reverted all Gateways and Repeater to 2.2. and all my issue went away. I even took a gateway on my desk install 2.3 on it - works find for a few hours then starts to NACK and play up - on 2.2 this just does not happen.

  • Hardware Contributor

    @itbeyond logs would be great it can be improved. As i wrote above, I had some issues as well but they went away when I upgraded all (and made some other changes as well).

  • Hello,
    I have a similar problem. I wanted to start a new thread, but after reading this posts I put it here. My problem is similar even though I do not have a repeater. I used the mysensors version 2.3.0 alpha, after updating to 2.3.0 stable a few days ago one of my nodes started not to send humidity data. Here is the log:

    25 TSM:INIT
    26 TSF:WUR:MS=0
    35 TSM:INIT:STATID=101
    37 TSF:SID:OK,ID=101
    39 TSM:FPAR
    43 TSM:ID
    44 TSM:ID:OK
    45 TSM:UPL
    81 TSF:MSG:SEND,101-101-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:1
    2092 TSF:MSG:SEND,101-101-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=1,st=OK:1
    2099 TSF:MSG:READ,0-0-101,s=255,c=3,t=25,pt=1,l=1,sg=0:1
    2107 TSM:UPL:OK
    2108 TSM:READY:ID=101,PAR=0,DIS=1
    2132 TSF:MSG:SEND,101-101-0-0,s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=OK:0100
    2143 TSF:MSG:READ,0-0-101,s=255,c=3,t=15,pt=6,l=2,sg=0:0100
    2183 TSF:MSG:SEND,101-101-0-0,s=255,c=0,t=17,pt=0,l=5,sg=0,ft=0,st=OK:2.3.0
    2191 TSF:MSG:SEND,101-101-0-0,s=255,c=3,t=6,pt=1,l=1,sg=0,ft=0,st=OK:0
    2732 TSF:MSG:READ,0-0-101,s=255,c=3,t=6,pt=0,l=1,sg=0:M
    2769 TSF:MSG:SEND,101-101-0-0,s=255,c=3,t=11,pt=0,l=18,sg=0,ft=0,st=OK:Senzor 101-DualDHT
    2780 TSF:MSG:SEND,101-101-0-0,s=255,c=3,t=12,pt=0,l=3,sg=0,ft=0,st=OK:1.1
    2790 TSF:MSG:SEND,101-101-0-0,s=0,c=0,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
    2798 TSF:MSG:SEND,101-101-0-0,s=1,c=0,t=6,pt=0,l=0,sg=0,ft=0,st=OK:
    2805 TSF:MSG:SEND,101-101-0-0,s=2,c=0,t=6,pt=0,l=0,sg=0,ft=0,st=OK:
    2813 TSF:MSG:SEND,101-101-0-0,s=3,c=0,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
    2820 MCO:REG:REQ
    2824 TSF:MSG:SEND,101-101-0-0,s=255,c=3,t=26,pt=1,l=1,sg=0,ft=0,st=OK:2
    2832 TSF:MSG:READ,0-0-101,s=255,c=3,t=27,pt=1,l=1,sg=0:1
    2837 MCO:PIM:NODE REG=1
    2840 MCO:BGN:INIT OK,TSP=1
    2848 MCO:SLP:MS=2000,SMS=0,I1=255,M1=255,I2=255,M2=255
    2853 TSF:TDI:TSL
    2855 MCO:SLP:WUP=-1
    2856 TSF:TRI:TSB
    2868 TSF:MSG:SEND,101-101-0-0,s=1,c=1,t=0,pt=7,l=5,sg=0,ft=0,st=OK:31.8
    DHT1TEMP: 31.80
    2875 MCO:SLP:MS=2500,SMS=0,I1=255,M1=255,I2=255,M2=255
    2880 TSF:TDI:TSL
    2882 MCO:SLP:WUP=-1
    2884 TSF:TRI:TSB
    4485 !TSF:MSG:SEND,101-101-0-0,s=0,c=1,t=1,pt=7,l=5,sg=0,ft=0,st=NACK:35.2
    DHT1HUM: 35.20
    4497 MCO:SLP:MS=2000,SMS=0,I1=255,M1=255,I2=255,M2=255
    4501 TSF:TDI:TSL
    4503 MCO:SLP:WUP=-1
    4505 TSF:TRI:TSB
    4513 TSF:MSG:SEND,101-101-0-0,s=2,c=1,t=0,pt=7,l=5,sg=0,ft=1,st=OK:24.0
    DHT2TEMP: 24.00
    4520 MCO:SLP:MS=2500,SMS=0,I1=255,M1=255,I2=255,M2=255
    4527 TSF:TDI:TSL
    4529 MCO:SLP:WUP=-1
    4530 TSF:TRI:TSB
    6130 !TSF:MSG:SEND,101-101-0-0,s=3,c=1,t=1,pt=7,l=5,sg=0,ft=0,st=NACK:56.8
    DHT2HUM: 56.80

    As you can see the temperature is sent correctly, and then the humidity value is not. When I returned the 2.3.0 alpha version to the node, everything started going OK. Otherwise, on other nodes where i also updated to version 2.3.0 stable this problem is not. I also updated the gateway to version 2.3.0 stable. I just had to make a downgrade on this one node only.

  • Hardware Contributor

    @norton just out of curiosity, you can add a wait(100); after sending the temp value. This way the radio has some time to recover if needed. I understand your point since it works in alpha but could be a good clue if it works with a wait().

  • @sundberg84 I understand about the logs but after spending several days trying to make 2.3.0 work on these nodes and just going to NACK NACK NACK for every send either repeater or gateway I reverted. I can enable it again if you like but all you will see is good data for a period then without any warning or reason constant NACK for every send. I did add wait(50)s on my nodes and these seem to be better but no go on Gateways and Repeaters cannot inject a wait of course. I can report that on Gateways trying 2.3.0 I used Vera/Ethernet - openHab/MQTT and openHab/Ethernet and all did the exact same thing and now on 2.2.0 I have zero problems.

    Coupled with this testing the openHab network was and is still new so had limited nodes installed and everything was 2.3.0 when the troubles occurred so I did have a full 2.3.0 network using channel 82.

  • @itbeyond im running 2.3 on gateway, nodes and repeater… Im glad someone showed up with the same issue. The behaviour is similar: everything is ok and, in my case, it starts to "NACK" after around 16 min… Seems to be a software problem then and not the "popular" NRF24 reception issues. What radios are you using? NRF24's?

  • Admin

  • @tekka ok, will test your version tomorrow and collect the node log. Do i need to upload your version to the node, repeater and gateway?

  • Admin

    @titvs are you using nrf24L01+ PA+LNA modules?

  • @tekka using normal NRF24's on the nodes and a nrf24L01+ PA+LNA on the gateway.

  • Admin

    @titvs ok - I'd recommend to update all devices and re-run the test.

  • @titvs my testing seems to show that this updated version from @tekka does resolve the problem. I have added some questions about the release details etc in the post

  • @itbeyond Nice! Will test it today and post my results.

  • @tekka well, unfortunately i had the same problem. The far away node connected to the Repeater but after aprox 1h working ok, it stopped being updated at Domoticz with transportCheckUplink() false.
    You changed a timing setting, right? With the normal version the node stopped being updated at about 15-16 min and now it changed to about 1 hour…
    I have a node connected directly to the gateway with the nrf24L01+ PA+LNA working without problems, so it seems to be some kind of problem with the Repeater code and timings...

  • Admin

    @titvs It would be helpful if you could post the debug log showing what you describe + the sketch you are using.

  • @tekka the debug log (MY_DEBUG)/sketch from the node that gets disconnected or the repeater?

  • @titvs I have tested a repeater and it is still working ok after 48 hours using the CE timing modified code.

  • @itbeyond can you please post the initial code defines for your repeater and a node that connects to it? To see if I’m doing something wrong...
    In the meantime I’m going to get the debug log and sketch code for my node.

  • Admin

    @titvs ideally both + sketch

  • @tekka Well, im running your beta code and like @itbeyond it seems to be working for 24h now. Uploaded the new compiles with the lib from the RF24Fix branch to all the nodes, gateway and repeater and it seems the drops stopped.
    Built a couple of Relay nodes, one of which is connected to the repeater and they also seem to be working correctly.

    Im linking the ZIP to the node log file with the RF24 verbose debug (its a tad big), if you want to take a look:


    And this is my TEMP+HUM node sketch:

    // Enable debug prints
    //#define MY_DEBUG
    //#define MY_DEBUG_VERBOSE_RF24
    // Enable and select radio type attached 
    #define MY_RADIO_NRF24
    //#define MY_RADIO_RFM69
    //#define MY_RS485
    #define MY_RF24_CHANNEL 1   //////////////
    #define MY_RF24_PA_LEVEL RF24_PA_HIGH
    //#define MY_PARENT_NODE_ID 0            // REPEATER NODE ID
    //#define MY_PARENT_NODE_IS_STATIC        // this will force your node to use only the repeater
    // #define MY_REPEATER_FEATURE
    #include <SPI.h>
    #include <MySensors.h>  
    #include <DHT.h>
    #include <U8g2lib.h>  //////////////////////
    #include <Wire.h>    /////////////////////////
    U8G2_SSD1306_128X64_NONAME_1_HW_I2C u8g2(U8G2_R0, A5, A4);   // U8G2 Constructor (A5 - Clock SCL ; A4 - Data SDA)
    #define DHT_DATA_PIN 3
    #define SENSOR_TEMP_OFFSET 0
    static const uint64_t UPDATE_INTERVAL = 60000;
    static const uint8_t FORCE_UPDATE_N_READS = 10;
    #define CHILD_ID_HUM 0
    #define CHILD_ID_TEMP 1
    float lastTemp;
    float lastHum;
    uint8_t nNoUpdatesTemp;
    uint8_t nNoUpdatesHum;
    bool metric = true;
    MyMessage msgHum(CHILD_ID_HUM, V_HUM);
    MyMessage msgTemp(CHILD_ID_TEMP, V_TEMP);
    DHT dht;
    void before(){
       do {
       } while ( u8g2.nextPage() );
        do {
         u8g2.drawStr(3, 32, "Connecting...");
       } while ( u8g2.nextPage() );
    void presentation()  
      // Send the sketch version information to the gateway
      sendSketchInfo("TEMPHUM_OLED", "1.2");
      // Register all sensors to gw (they will be created as child devices)
      present(CHILD_ID_HUM, S_HUM);
      present(CHILD_ID_TEMP, S_TEMP);
      metric = getControllerConfig().isMetric;
    void setup()
      dht.setup(DHT_DATA_PIN); // set data pin of DHT sensor
      if (UPDATE_INTERVAL <= dht.getMinimumSamplingPeriod()) {
        do {
            u8g2.setFont(u8g2_font_haxrcorp4089_tr); // 7 PIXEL HIGHT
            u8g2.drawStr(1,12,"WARNING: UPDATE_INTERVAL");
           u8g2.drawStr(1,24,"is smaller than supported by");
            u8g2.drawStr(1,36,"the sensor!");
           } while ( u8g2.nextPage() );
    void loop()      
     while (transportCheckUplink() == false){
      do {
        u8g2.setFont(u8g2_font_helvR14_tf); // 14 px height
        u8g2.drawStr(3, 32, "Disconnected!");
        } while ( u8g2.nextPage() );
      float temperature = dht.getTemperature();
      if (isnan(temperature)) {
        Serial.println("Failed reading temperature from DHT!");
      } else if (temperature != lastTemp || nNoUpdatesTemp == FORCE_UPDATE_N_READS) {
        // Only send temperature if it changed since the last measurement or if we didn't send an update for n times
        lastTemp = temperature;
        // apply the offset before converting to something different than Celsius degrees
        temperature += SENSOR_TEMP_OFFSET;
        if (!metric) {
          temperature = dht.toFahrenheit(temperature);
        // Reset no updates counter
        nNoUpdatesTemp = 0;
        send(msgTemp.set(temperature, 1));
        #ifdef MY_DEBUG
        Serial.print("T: ");
      } else {
        // Increase no update counter if the temperature stayed the same
      // Get humidity from DHT library
      float humidity = dht.getHumidity();
      if (isnan(humidity)) {
        Serial.println("Failed reading humidity from DHT");
      } else if (humidity != lastHum || nNoUpdatesHum == FORCE_UPDATE_N_READS) {
        // Only send humidity if it changed since the last measurement or if we didn't send an update for n times
        lastHum = humidity;
        // Reset no updates counter
        nNoUpdatesHum = 0;
        send(msgHum.set(humidity, 1));
        #ifdef MY_DEBUG
        Serial.print("H: ");
      } else {
        // Increase no update counter if the humidity stayed the same
      do {
      u8g2.setCursor(2, 35);
      u8g2.print(temperature, 1);
      u8g2.drawGlyph(88, 35, 0x00b0); // degree
      u8g2.drawStr(100, 35, "C");
      u8g2.setCursor(70, 60);
      u8g2.print(humidity, 0);
      u8g2.drawStr(100, 60, "%");
      u8g2.setFont(u8g2_font_open_iconic_thing_2x_t); // 16 pix height
      u8g2.drawGlyph(45, 60, 0x0048); // drop
      } while ( u8g2.nextPage() );
      // Sleep for a while to save energy

  • Admin

    @titvs ok, do you also have the repeater log + sketch? btw, for powered nodes I'd recommend using wait() instead of delay() - this ensures a proper functionality of the communcation stack.

  • @tekka i didnt save the log from the Repeater but if it helps i'm going to collect it. As for the Repeater sketch, its the default:

    // Enable debug prints to serial monitor
    //#define MY_DEBUG
    // Enable and select radio type attached
    #define MY_RADIO_NRF24
    //#define MY_RADIO_NRF5_ESB
    //#define MY_RADIO_RFM69
    //#define MY_RADIO_RFM95
    #define MY_NODE_ID 51    // FIXED NODE ID
    #define MY_PARENT_NODE_ID 0
    #define MY_RF24_CHANNEL 1
    #define MY_RF24_PA_LEVEL RF24_PA_HIGH
    // Enabled repeater feature for this node
    #include <MySensors.h>
    void setup()
    void presentation()
      //Send the sensor node sketch version information to the gateway
      sendSketchInfo("Repeater Node", "1.0");
    void loop()

  • Admin

    @titvs Would be great if you collect the debug log of the repeater, especially when the NACKs happen - this may help to understand the origin of the issue

  • @tekka Here it is: REPEATER LOG

    It seems to be working ok but there are still some NACKs on the log. Radio issues perhaps? Neverthless, im not getting the node dropouts i got with the 2.3.0 version...

Log in to reply

Suggested Topics