Troubleshooting

For plan A (Raspi gateway) I am still waiting for the new radio modules. I'm not scrapping this plan yet... Regarding plan B (ethernet gateway), I am still confused regarding which pins to use and how to make it in the sketch: [image: 1573035936777-9b5536d2-b03a-4006-a9d0-76be91d841a5-image.png] On the left are the pins used in the Ethernet Gateway page, with a nano, a W5100 and the NRF24L01+ radio. Also, the MY_RF24 and MY_SOFT_SPI commands in the original sketch. On the right, the RF-NANO, W5500 and the NRF24L01+ radio I am trying to use. The pins of the radio are fixed, as both are in the same module: [image: 1573037434981-93afe9f7-f4e6-4071-8ba6-c4d1d93a9bd3-image.png] Is the following correct? (#1) the MY_RF24_CS_PIN is now pin 9 while MY_RF24_CE_PIN is the default one of the nano (pin 10, SS?) so it can be ommited (?). (#2) the W5500 pins are the ones that have to be moved now. MISO, MOSI and SCK are going to pins 16, 15 and 14 with MY_SOFT_SPI (I am assuming the W5500 supports software SPI, I read yesterday that not all modules do) (#3) where and how goes the SS pin of the W5500??? MY_SOFT_SPI_CE_PIN exists? Is this what you mean with your comment, @neverdie? All this is really exciting, but I still have a lot to learn. Apologies again for the 'dumb' questions...

I guess i found it now, Looks like that V_LEVEL and V_LIGHT_LEVEL are both not behaving as expected, I have changed these now to V_TEXT after that the sensors was finaly working within domoticz. Also i had some cabeling issues, looks like the sensor doesnt like an cable length off 2 meter on 4x 0,44mm2 wire.. Tommorow i am going to place the arduino closer to the weather station and i guess everything would be fine again then ! Here my latest sketch: #define MY_DEBUG #define MY_RS485 #define MY_RS485_DE_PIN 2 #define MY_RS485_BAUD_RATE 19200 #define MY_RS485_HWSERIAL Serial #define MY_NODE_ID 5 #include <MySensors.h> #include <BH1750.h> #include <Wire.h> #define CHILD_ID_LIGHT 25 unsigned long SLEEP_TIME = 25000; // Sleep time between reads (in milliseconds) BH1750 lightSensor; // V_LIGHT_LEVEL should only be used for uncalibrated light level 0-100%. // If your controller supports the new V_LEVEL variable, use this instead for // transmitting LUX light level. // MyMessage msg(CHILD_ID_LIGHT, V_LIGHT_LEVEL); MyMessage msg(CHILD_ID_LIGHT, V_TEXT); uint16_t lastlux; void setup() { lightSensor.begin(); } void presentation() { // Send the sketch version information to the gateway and Controller sendSketchInfo("Node 5", "1.0"); // Register all sensors to gateway (they will be created as child devices) present(CHILD_ID_LIGHT, S_BINARY); } void loop() { uint16_t lux = lightSensor.readLightLevel();// Get Lux value // Serial.println(lux); // if (lux != lastlux) { send(msg.set(lux)); // lastlux = lux; // } wait(SLEEP_TIME); } @Nca78 Thanks for your help !

@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