Troubleshooting

@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

@mfalkvidd i will definetly do that within the next days.