Troubleshooting

@grumpazoid Good to hear and thanks for reporting back :+1:

I know Its too late to ask you, but did you find the solution?

The same ChildID most likely isn't the cause for the missed relay commands, but the "wait" instructions. IMO the code should be changed to a "non blocking loop". Search the web for that keywords or have al look at https://www.mysensors.org/build/pulse_water as an example within the MySensors framework.

It might be possible to power the Arduino off the output pin. Since they are dirt cheap I would just test it. But like the others I would suggest to use the interrupts of pin 2 and 3. For my battery powered 3.3v pro mini I use 3.3v pir sensors without the voltage regulator. The standard 5v pir needs at least 4.5v just to step it down internally to 3.3V. On these I had problems with voltage stability because I stepped it up to 5V. Also the battery lifetime was poor. With the 3.3v pir version this thing runs for months. With the solar panel on top maybe forever.

After more investigations I believe the problem is caused by a mqtt server connection timeout. By default the gateway tries to send the radio message 5 times. If I lower the number of retries , 2 for example, no more loop. Probably now much more then 25 messages cause a loop. For testing I added _MQTT_client.loop() in transportSendWrite() (MyTransport.cpp) and, no more loop with default 5 retries.

I’m running Home Assistant with NRF24L01 with no problems at all. But I have manually installed it on Raspbian for that exact reason. You could do nothing by yourself when using HASSIO. It’s extremely easy to install it manually but not sure how easy it would be to migrate your existing environment. It may be worth it though. You get your freedom to do whatever you want with your Raspberry, back.

@jimy-aguirre I think this behavior is intentional. The indication is designed for giving user feedback when sending or receiving messages. Most users do not expect to see acknowledgement packets as messages. I think you could add a call to set tx indication here to activate the pa when sending acks: https://github.com/mysensors/MySensors/blob/67efa7a7a24e589aad5e0b605fd6c88a858f4038/hal/transport/RFM69/MyTransportRFM69.cpp#L231

The atmega328 implementation of MySensors sleep wakes up every 8 seconds and result in many years of battery life, so waking up on the nrf5 shouldn’t be much of a problem I think.

I've been fiddling with the radio alone (serial gw), softspi and changing pins, and I think there's something else here. Well those are my findings: With this base definition and without the module wired: #define MY_RADIO_RFM69 #define MY_RFM69_NEW_DRIVER #define MY_IS_RFM69HW #define MY_DEBUG_VERBOSE_RFM69 #define MY_GATEWAY_ENC28J60 It works as expected. 0 MCO:BGN:INIT GW,CP=RPNGA---,REL=255,VER=2.3.1 4 TSM:INIT 5 TSF:WUR:MS=0 6 RFM69:INIT 7 RFM69:INIT:PIN,CS=10,IQP=2,IQN=0 11 RFM69:PTX:LEVEL=5 dBm 13 TSM:INIT:TSP OK 15 TSM:INIT:GW MODE 16 TSM:READY:ID=0,PAR=0,DIS=0 19 MCO:REG:NOT NEEDED 72 GWT:TIN:IP=192.168.50.211 1075 MCO:BGN:STP 1077 MCO:BGN:INIT OK,TSP=1 1081 TSM:READY:NWD REQ 1083 RFM69:SWR:SEND,TO=255,SEQ=0,RETRY=0 1088 RFM69:CSMA:RSSI=-98 1090 TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK: If I try to change CS pin to any other with #define MY_RFM69_CS_PIN 4 for example, I always get: 0 MCO:BGN:INIT GW,CP=RPNGA---,REL=255,VER=2.3.1 4 TSM:INIT 5 TSF:WUR:MS=0 6 RFM69:INIT 7 RFM69:INIT:PIN,CS=4,IQP=2,IQN=0 11 RFM69:PTX:LEVEL=5 dBm 13 TSM:INIT:TSP OK 14 TSM:INIT:GW MODE 16 TSM:READY:ID=0,PAR=0,DIS=0 19 MCO:REG:NOT NEEDED So I revert the CS pin change and activate softspi and change irq #define MY_SOFTSPI and #define MY_RFM69_IRQ_PIN 3 And it works well: 0 MCO:BGN:INIT GW,CP=RPNGA---,REL=255,VER=2.3.1 4 TSM:INIT 5 TSF:WUR:MS=0 6 RFM69:INIT 7 RFM69:INIT:PIN,CS=10,IQP=3,IQN=1 11 RFM69:PTX:LEVEL=5 dBm 13 TSM:INIT:TSP OK 15 TSM:INIT:GW MODE 16 TSM:READY:ID=0,PAR=0,DIS=0 19 MCO:REG:NOT NEEDED 72 GWT:TIN:IP=192.168.50.211 1075 MCO:BGN:STP 1077 MCO:BGN:INIT OK,TSP=1 1079 TSM:READY:NWD REQ 1081 RFM69:SWR:SEND,TO=255,SEQ=0,RETRY=0 1086 RFM69:CSMA:RSSI=-98 1091 TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK: Then I add the eth module and I get: 0 MCO:BGN:INIT GW,CP=RPNGA---,REL=255,VER=2.3.1 4 TSM:INIT 5 TSF:WUR:MS=0 6 RFM69:INIT 7 RFM69:INIT:PIN,CS=10,IQP=3,IQN=1 11 RFM69:PTX:LEVEL=5 dBm 13 TSM:INIT:TSP OK 15 TSM:INIT:GW MODE 16 TSM:READY:ID=0,PAR=0,DIS=0 19 MCO:REG:NOT NEEDED And stays here forever. Of course all those test are made using a double (5v+3v3) good power source, a level shifter... and changing the wires accordingly. I have some questions: Its normal MY_RFM69_CS_PIN not having effect and breaking the radion connection? Without being able to change this, I don't know if it's spi interference. In the last test, it seems to halt when initialising the network. Doesn't it? Is there a way I can further know if the problem is with the eth module? I've tried it alone with the nano and it works. I would thank guidance for debugging this.

@danielo-rodríguez said in Node not working after adding some wires and a capacitor: Which would be a good fit? It depends on your environment. In rural environments you could try the lower channels. The higher channels (around 100 and up) are outside the wifi range, but I've seen clones performing worse at high frequencies. As a reference, this post discusses Wifi vs nRF24 channels: https://forum.mysensors.org/topic/4721/nrf-frequency-and-channels

@zen85 I think @tekka implemented some security functionality in his bootloader but I believe it relies on a personalized atsha204a due to size limitations. And does not support encryption. But I might be out of date on that topic.

https://electronics.stackexchange.com/questions/462754/how-to-send-the-key-sequence-ctrl-q-to-a-serial-port https://forums.ni.com/t5/LabVIEW/How-do-i-send-a-quot-Ctrl-C-quot-character-to-serial-port-RS232/td-p/24213?profile.language=en https://duckduckgo.com/?q=termite+ctrl-q&t=canonical&ia=web

@genuinejd powering the radio at 5v is way out of spec and will likely kill it. I'm not familiar with your pcb, but you could try powering radio+arduino directly from 2 fresh AA batteries, without step converter inbetween. These radios are very sensitive to bad power supply.

Thank you both! That looks exctly like what i need; I was looking in the wrong spot. Cheers!

@snyfir with this fix, everything work fine :smiley:

@tekka EDITED ANSWER*: it worked! it did not work because of a typo... sorry for that....

@steven987 yes atc is on by default. It can be disabled by defining MY_RFM69_ATC_MODE_DISABLED

as soon as i burned a new bootloader it worked. watchdog does not like old bootloader and since mysensors is using that for rebooting it fixed my issue.

Seems that I may have been hit again by the radio sync problem: 613757 RF24:RBR:REG=23,VAL=17 613788 RF24:RBR:REG=23,VAL=17 613820 RF24:RBR:REG=23,VAL=17 613851 RF24:RBR:REG=23,VAL=17 613883 RF24:RBR:REG=23,VAL=17 613914 RF24:RBR:REG=23,VAL=17 613946 RF24:RBR:REG=23,VAL=17 613977 RF24:RBR:REG=23,VAL=17 614009 RF24:RBR:REG=23,VAL=17 614040 RF24:RBR:REG=23,VAL=17 614072 RF24:RBR:REG=23,VAL=17 614103 RF24:RBR:REG=23,VAL=17 614135 RF24:RBR:REG=23,VAL=17 614166 RF24:RBR:REG=23,VAL=17 @tekka I've conducted a debug test with the radio timing code and the results can be found there: GW_DEBUG: https://drive.google.com/open?id=1Ji-6E_iAcE86gTzxSTjOihVlQREHjwLN NODE_DEBUG: https://drive.google.com/open?id=1skaAWlYWqjNRqAjcTAVudw0DAZiAFEqs