Troubleshooting

Yes D8 = pin 15 :) So any ideas on why the raspberry pi isn't sending parent information or "listening/responding" to the wemos? As a side sanity check I will try a different raspberry pi. Can someone confirm the pins on Pi2/3? Power - 1 Mosi -19 Miso -21 DIO - 22 Clk - 23 NSS - 24 GND - 25

Apparently this day is my lucky day :-) @scalz , you did me think with your comment about the samd21 board not triggering the irq. So I looked up where the pin layouts of all these 'arduino compatible' boards are defined. My used board is a RobotDyn Samd21 M0 board and they claim compatible with a Arduino M0 and I did use the Arduino SAMD boards (32-bits ARM Cortex-M0+) by Arduino version 1.8.3. The code you find at: https://github.com/arduino/ArduinoCore-samd With some help of the google doctor, I did find that the pin layouts are defined in the Variants.cpp file in https://github.com/arduino/ArduinoCore-samd/blob/master/variants/arduino_mzero/variant.cpp (I'm using the Arduino M0 entry when selecting my board) In this file /* * * + Pin number + ZERO Board pin | PIN | Label/Name | Comments (* is for default peripheral in use) * +------------+------------------+--------+-----------------+------------------------------ * | | Digital Low | | | * +------------+------------------+--------+-----------------+------------------------------ * | 0 | 0 -> RX | PA11 | | EIC/EXTINT[11] ADC/AIN[19] PTC/X[3] *SERCOM0/PAD[3] SERCOM2/PAD[3] TCC1/WO[1] TCC0/WO[3] * | 1 | 1 <- TX | PA10 | | EIC/EXTINT[10] ADC/AIN[18] PTC/X[2] *SERCOM0/PAD[2] TCC1/WO[0] TCC0/WO[2] * | 2 | ~2 | PA08 | | EIC/NMI ADC/AIN[16] PTC/X[0] SERCOM0/PAD[0] SERCOM2/PAD[0] *TCC0/WO[0] TCC1/WO[2] * | 3 | ~3 | PA09 | | EIC/EXTINT[9] ADC/AIN[17] PTC/X[1] SERCOM0/PAD[1] SERCOM2/PAD[1] *TCC0/WO[1] TCC1/WO[3] * | 4 | ~4 | PA14 | | EIC/EXTINT[14] SERCOM2/PAD[2] SERCOM4/PAD[2] TC3/WO[0] *TCC0/WO[4] * | 5 | ~5 | PA15 | | EIC/EXTINT[15] SERCOM2/PAD[3] SERCOM4/PAD[3] TC3/WO[1] *TCC0/WO[5] * | 6 | ~6 | PA20 | | EIC/EXTINT[4] PTC/X[8] SERCOM5/PAD[2] SERCOM3/PAD[2] TC7/WO[0] *TCC0/WO[6] * | 7 | ~7 | PA21 | | EIC/EXTINT[5] PTC/X[9] SERCOM5/PAD[3] SERCOM3/PAD[3] TC7/WO[1] *TCC0/WO[7] * +------------+------------------+--------+-----------------+------------------------------ * | | Digital High | | | * +------------+------------------+--------+-----------------+------------------------------ * | 8 | ~8 | PA06 | | EIC/EXTINT[6] PTC/Y[4] ADC/AIN[6] AC/AIN[2] SERCOM0/PAD[2] *TCC1/WO[0] * | 9 | ~9 | PA07 | | EIC/EXTINT[7] PTC/Y[5] DC/AIN[7] AC/AIN[3] SERCOM0/PAD[3] *TCC1/WO[1] * | 10 | ~10 | PA18 | | EIC/EXTINT[2] PTC/X[6] SERCOM1/PAD[2] SERCOM3/PAD[2] *TC3/WO[0] TCC0/WO[2] * | 11 | ~11 | PA16 | | EIC/EXTINT[0] PTC/X[4] SERCOM1/PAD[0] SERCOM3/PAD[0] *TCC2/WO[0] TCC0/WO[6] * | 12 | ~12 | PA19 | | EIC/EXTINT[3] PTC/X[7] SERCOM1/PAD[3] SERCOM3/PAD[3] *TC3/WO[1] TCC0/WO[3] * | 13 | ~13 | PA17 | LED | EIC/EXTINT[1] PTC/X[5] SERCOM1/PAD[1] SERCOM3/PAD[1] *TCC2/WO[1] TCC0/WO[7] * | 14 | GND | | | * | 15 | AREF | PA03 | | *DAC/VREFP PTC/Y[1] * | 16 | SDA | PA22 | | EIC/EXTINT[6] PTC/X[10] *SERCOM3/PAD[0] SERCOM5/PAD[0] TC4/WO[0] TCC0/WO[4] * | 17 | SCL | PA23 | | EIC/EXTINT[7] PTC/X[11] *SERCOM3/PAD[1] SERCOM5/PAD[1] TC4/WO[1] TCC0/WO[5] This is the defined pin mapping for a Arduino mZero. (I was using D2 as IRQ for the RFM69) * | 2 | ~2 | PA08 | But on the pin layout of the RobotDyn board I saw: * | 2 | ~2 | PA14 | On the RobotDyn the pin PA08 is mapped on the D4 arduino pin and not the D2 pin! With the pins D2/D4, RobotDyn is following here the Arduino Zero layout and NOT the Arduino mZero layout! So, I verified the other mappings and found that following pins are different mapped on the Arduino mZero: * | 2 | ~2 | PA08 | * | 4 | ~4 | PA14 | On the RobotDyn Samd21M0 * | 2 | ~2 | PA14 | * | 4 | ~4 | PA08 | So I changed the IRQ (DIO0) from the RF69 to the port D8 (PA06) and bingo it started to work :-) (did choose randomly D8) I saw also a difference in the SPI mapping mZero * | 18 | 1 | PA12 | MISO RobotDyn samd21 m0 * | not defined on their pin layout doc | 1 | PB12 | MISO But it is working, so maybe an error on RobotDyn's documentation? So if I resume the thing: The RobotDyn SAMD21 M0 board is claimed compatible with the Arduino M0 (mZero). In the IDE you must also select the Arduino M0. (selecting Arduino/Genuino Zero xxx will not work) But the RobotDyn used layout is compatible with the Arduino Zero, so pin D2 and D4 are reversed, making the code of the board Arduino M0 not working if you choose to use these pins in your design. So now we can continue to build our gateway, my originally goal. Edit : my MQTT gateway with the RobotDyn Samd21 M0 board, a W5500 ethernet module and a radio RFM69HW is up and running :-) Thanks for all comments that guided me to the solution :-)

@tbowmo said in Sensebender Gateway RFM69HW Decoupling Capacitor: @nalith the sensebender gateway does include both 10uF and 100nF decoupling capacitors on the board, near the radio. I haven't used the GW with rfm69 that much though, so I have no experience with that radio. Great, thanks for the feedback!

@kimot Usually tied to ground via a 100k, but controlled by a pin so the mcu can pulse a reset.

@redfirebrooks according to the log, the node is not sending any measurement data. It just goes to sleep over and over again. Hard to tell why this happens without seeing the exact sketch code. Would you mind posting it? EDIT: Sorry, was on mobile and didn't see that the values were being sent, just not on the first two sleep periods. These lines show that the node is sending values (first the value 1617, later the value 1846). TSF:MSG:SEND,42-42-0-0,s=0,c=1,t=37,pt=2,l=2,sg=0,ft=0,st=OK:1617 TSF:MSG:SEND,42-42-0-0,s=0,c=1,t=37,pt=2,l=2,sg=0,ft=0,st=OK:1836 So it seems like the problem is that Domoticz is unable to display the information. What does the Hardware->Setup page looks for the MySensors gateway? What is shown on the "Devices" page in Domoticz?

@mfalkvidd said in NRF24 transport status not initialized: I do not know what they were intended for Tekka's chart says it all; preHwInit() has no serial output, so can be used to e.g. initialize serial devices (some hardware might require this). Then before() is called which starts logging to serial.

@ribaaa My guess: you restarted Openhab or the binding. I'm glad it works now!

i can't get this sensor to show up in HA. Any ideas anyone?

Great work @, thanks for reporting back!

just for reference, 4 out of 5 sensebender micros is still running strong, after 4 years on the same set of AA batteries, that they where deployed with. The 5th sensebender is my outdoor sensor, that one eats a set of batteries within 48 hours.. But i suspect that it's the air humidity that has destroyed it. I opted to use a Si7021 instead (there might be others that are better suited now), as it was better suited for low power operation, and runs down to 1.2V supply (if I remember right).

Great work @mcchots, thanks for reporting back

@yveaux said in nRF24L01+ Communication Failure: Root Cause and “Solution”: E.g. in your last post "as it works if debug is activated. Also Tekka Code works." That suggests there is a working solution for you, with tekka's patch and debug disabled. Is this correct? Yes @yveaux with my posts on this thread I was only hoping to help testing this situation, as I found interesting to also add control to TX sequences. But to my surprise the issue #941 appeared on a node (in my desk 0.5m away from gw) that never showed it before and I thought it could help with that one, as still wasn't solved. I thought I found a clue to prove that it has to do with node radio processing speed (alas SW, not HW). I don't know how pairing is synced between nodes and gw. It makes sense to me for the gw to wait and adapt to a new incoming node should already be implemented, so this issue has no logic to me. It's true that my range it's very poor. I only have two sensors operative, and the two are in clear line of sight to the gw. The garage door controller was giving so many problems that had to deactivate it (only one floor between and just under gw) and the strips controllers work one day of ten. But it has passed some time and I should do testing again. PS: As for at where I was with my installation (I had two operations on my hands and a baby, so I've been disconnected) my problems are nodes that appear comms dead after putting them in place and starting. Not completing the registering sequence. Others working as expected and after a while being totally disconnected from the network and at the same situation above. Randomly registering after leaving them alone for days. So two kinds of nodes, ones that finally register on their own and others never, even being so much near to the gw (4mt) I don't find it to be a range or radio issue. It smells to me to be a network management problem.

Sorry for being unclear. The log from node boot until where it gets "stuck" (i e where the significant slowdown occurs) should be sufficient. See https://github.com/mysensors/MySensors/issues/927 for a discussion on which order the different methods are called. It might help pinpoint the issue. If you don't mind, please post the node sketch. It makes it easier to match the debug output with what is happening.

I experience the same behaviour with an ESP8266 wifi gateway. In the MySensors sources I found the reason why this doesn't work: In the file core\MyGatewayTransportEthernet.cpp in lines 98 to 106 the ethernet server is initialized: #if defined(MY_GATEWAY_CLIENT_MODE) #if defined(MY_USE_UDP) EthernetUDP _ethernetServer; #endif /* End of MY_USE_UDP */ #elif defined(MY_GATEWAY_LINUX) /* Elif part of MY_GATEWAY_CLIENT_MODE */ EthernetServer _ethernetServer(_ethernetGatewayPort, MY_GATEWAY_MAX_CLIENTS); #else /* Else part of MY_GATEWAY_CLIENT_MODE */ EthernetServer _ethernetServer(_ethernetGatewayPort); #endif /* End of MY_GATEWAY_CLIENT_MODE */ For my gateway the last statement without the constant MY_GATEWAY_MAX_CLIENTS is used to define the server. Thus it is clear why only one connection is kept. Maybe the ESP8266 examples should be updated. Or the ethernet server code should be reworked. :/

@yveaux : you're right! PIR are not so fast.

sorry it took a bit - this is my current test: https://gist.github.com/solars/688a635f791c2e558a1ec57b67c9beb4 it's stitched together from sources I have found, so I might not be doing it right.

Long story short, problem found to be the US running for 19 days continuously but couldn't tell as had detached the board's LED in an earlier itteration where power indication was from the booster. Fault was a detached Dupont connection for the latching relay reset, only discovered when probing found the relay was not off, and went to reset it by removing the Arduino pin connection to power it direct, ending up with the entire wire in my hand. Reconnected relay board and it felt tight, reset the relay then reconnected to the Arduino pin before the next due 12 hourly battery check, 1.76v recovered to 1.87 in 30 minutes and rising. Can only presume I disturbed the connection somehow, but kicking myself about removing the LED, and not thinking to listen for clicks from the relay as a check on Set/Reset.:flushed: Ho-hum, next a fresh pair of AA to start over again, well over a year is back in the frame again.

Man ska inte ropa Hej... But it seems your tip was really working out. I tried D1 and D2 but had some other issues so I went back to D3 but made sure the doorswitch was not connected on boot, in order not to interfere. Then it boots, normally, connects to the router and subsequently to Domoticz. Thanx a lot ! // Beersmith