smart sleep inconsistent?

[skywatch]

@CrankyCoder I have similar issue with a couple of nodes. Sometimes it looses signal for hours at a time...

It might be external interference from other devices like wifi, bluetooth or microwave oven.

It can also be connection issues especially with the push-on dupont connectors as when the temperature/humidity/air pressure change then the connectors can move slightly. Also they might be badly crimped in the first place.

So check all connections are good and can't move (soldering is best here), and then look for sources that might be an issue.

It could also be another node closer to the GW is sending at the exact same time as the problem node and masking the signal.

Batteries are susceptable to variations due to temperature too, they are a chemical reaction. So try a better source of power for testing too.

Looking at the code, send_status_message only ever sends 1 - is this what you want? It seems to never send anything else (like 0)....

Also you are using sleep but have a receive function - what happens to messages when the node is asleep?

You are sending battery level every second? That is too often. How long will the batteries last? This wastes battery power a lot. I check betteries once a day on my security sensors, they don't change for weeks at a time....

Have you modified the pro mini as per the battery page on this site? Have you added capacitors to the radio module?

directionControl seems like it will always turn off both digital pins regardless of the message as //disable are the last statements to be actioned?

You can try changing

#define MY_RADIO_RF24

to.....

#define MY_RADIO_RF24
#define MY_RF24_PA_LEVEL RF24_PA_HIGH

options for power are MIN, LOW, HIGH, MAX. - it might help.

[CrankyCoder]

@skywatch said in smart sleep inconsistent?:

Looking at the code, send_status_message only ever sends 1 - is this what you want? It seems to never send anything else (like 0)....

battery is only sent when there is a change in the voltage.

@skywatch said in smart sleep inconsistent?:

Looking at the code, send_status_message only ever sends 1 - is this what you want? It seems to never send anything else (like 0)....

Where do you see that? i get 1 and 0 reported as needed based on the state.

@skywatch said in smart sleep inconsistent?:

Also you are using sleep but have a receive function - what happens to messages when the node is asleep?

That is what smartsleep does. It tells my controller (homeassistant) to queue up the messages. Which works fine, as long as the node wakes up.

@skywatch said in smart sleep inconsistent?:

Have you modified the pro mini as per the battery page on this site? Have you added capacitors to the radio module?

Correct, modified for battery use, and capacitors to the radio module.

@skywatch said in smart sleep inconsistent?:

directionControl seems like it will always turn off both digital pins regardless of the message as //disable are the last statements to be actioned?

This is correct, this is a directional H-bridge controller to pulse a latching solenoid valve, so I do not need them on but very briefly.

[CrankyCoder]

@skywatch said in smart sleep inconsistent?:

#define MY_RF24_PA_LEVEL RF24_PA_HIGH

I have the node and gateway on my desk now for testing, so I am going to reflash with this now! Fingers crossed it helps. :)

[CrankyCoder]

Got some more info. Here is some debug log off the gateway. The node in question is node 18

22:02:47.582 -> 28832653 TSF:MSG:SEND,0-0-18-18,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=OK:0
22:03:51.377 -> 28896448 TSF:MSG:READ,18-18-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
22:03:51.422 -> 28896512 TSF:MSG:BC
22:03:51.422 -> 28896533 TSF:MSG:FPAR REQ,ID=18
22:03:51.468 -> 28896566 TSF:PNG:SEND,TO=0
22:03:51.513 -> 28896594 TSF:CKU:OK
22:03:51.513 -> 28896615 TSF:MSG:GWL OK
22:03:51.967 -> 28897026 TSF:MSG:SEND,0-0-18-18,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=OK:0
22:05:01.405 -> 28966464 GWT:IMQ:TOPIC=mygateway1-in/10/1/1/0/40, MSG RECEIVED
22:05:01.497 -> 28966569 !TSF:MSG:SEND,0-0-53-10,s=1,c=1,t=40,pt=0,l=6,sg=0,ft=0,st=NACK:FFFFFF
22:07:04.200 -> 29089296 TSF:MSG:READ,18-18-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
22:07:04.246 -> 29089359 TSF:MSG:BC
22:07:04.292 -> 29089380 TSF:MSG:FPAR REQ,ID=18
22:07:04.337 -> 29089414 TSF:PNG:SEND,TO=0
22:07:04.337 -> 29089442 TSF:CKU:OK
22:07:04.382 -> 29089463 TSF:MSG:GWL OK
22:07:05.152 -> 29090214 TSF:MSG:SEND,0-0-18-18,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=OK:0
22:10:01.430 -> 29266499 GWT:IMQ:TOPIC=mygateway1-in/10/1/1/0/40, MSG RECEIVED
22:10:01.521 -> 29266604 !TSF:MSG:SEND,0-0-53-10,s=1,c=1,t=40,pt=0,l=6,sg=0,ft=0,st=NACK:FFFFFF
22:10:59.660 -> 29324730 TSF:MSG:READ,38-38-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
22:10:59.706 -> 29324794 TSF:MSG:BC
22:10:59.706 -> 29324815 TSF:MSG:FPAR REQ,ID=38
22:10:59.751 -> 29324848 TSF:PNG:SEND,TO=0
22:10:59.797 -> 29324877 TSF:CKU:OK
22:10:59.797 -> 29324897 TSF:MSG:GWL OK
22:11:00.523 -> 29325594 !TSF:MSG:SEND,0-0-38-38,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=NACK:0

Running it through the log parser it would appear the gateway is responding to the find parent request.

BUT. The node it self seems to be failing to find parent periodically. Like it's not getting the message back from the gateway.

22:12:10.465 -> Going to sleep
22:12:10.465 -> 44562 MCO:SLP:MS=30000,SMS=1,I1=255,M1=255,I2=255,M2=255
22:12:10.465 -> 44572 !MCO:SLP:TNR
22:12:20.399 -> 54491 TSM:FAIL:RE-INIT
22:12:20.399 -> 54493 TSM:INIT
22:12:20.399 -> 54499 !TSM:INIT:TSP FAIL
22:12:20.444 -> 54501 TSM:FAIL:CNT=5
22:12:20.444 -> 54503 TSM:FAIL:DIS
22:12:20.444 -> 54505 TSF:TDI:TSL
22:12:20.489 -> 54575 MCO:SLP:MS=19999
22:12:20.489 -> 54577 !TSF:SND:TNR
22:12:21.035 -> 55080 TSF:TDI:TSL
22:12:42.255 -> 55083 MCO:SLP:WUP=-1
22:12:42.301 -> 55085 TSF:TRI:TSB
22:12:42.301 -> 55091 !TSF:SND:TNR
22:12:42.301 -> Awake Now
22:12:42.301 -> 1010
22:12:42.301 -> 3.29
22:12:42.301 -> Battery Voltage: 7.98 V
22:12:42.301 -> Battery percent: 94 %
22:12:42.301 -> sensorValue:1010
22:12:42.301 -> Going to sleep
22:12:42.301 -> 55099 MCO:SLP:MS=30000,SMS=1,I1=255,M1=255,I2=255,M2=255
22:12:42.301 -> 55109 !MCO:SLP:TNR
22:12:51.744 -> 64509 TSM:FAIL:RE-INIT
22:12:51.744 -> 64512 TSM:INIT
22:12:51.744 -> 64518 !TSM:INIT:TSP FAIL
22:12:51.744 -> 64520 TSM:FAIL:CNT=6
22:12:51.744 -> 64522 TSM:FAIL:DIS
22:12:51.744 -> 64524 TSF:TDI:TSL
22:12:52.330 -> 65112 MCO:SLP:MS=19999
22:12:52.330 -> 65114 !TSF:SND:TNR
22:12:52.829 -> 65617 TSF:TDI:TSL

[mfalkvidd]

!TSM:INIT:TSP FAIL indicates that the radio chip is not responding to the arduino's commands.

The most common cause is unreliable wiring. But it could be something else. Define MY_DEBUG_VERBOSE_RF24 to get more details.

[mfalkvidd]

Btw, are you using MySensors 2.3 on the node and the gateway?

[skywatch]

@CrankyCoder Do the data drop outs have any correlation to the solenoid valve operating and does the valave use the same power supply as the node MCU?

[CrankyCoder]

@mfalkvidd Will add this now.

[CrankyCoder]

@mfalkvidd said in smart sleep inconsistent?:

Btw, are you using MySensors 2.3 on the node and the gateway?

Correct 2.3 on node and gateway.

[CrankyCoder]

@skywatch unfortunately no. This is for a sprinkler valve that I haven't set up any automations for yet since the questionable reliability at the moment would flood my yard lol

[CrankyCoder]

Not sure if this helps or if anything jumps out, but here is the node and gateway side by side. Node does find parent request, gateway sees it, responds with 0. But node never gets it.

[mfalkvidd]

@CrankyCoder I am not sure but to me it looks like it takes a bit more than 1 second for the gateway to send the response? And by then, the node has already gone to sleep so it can't receive the message.

[skywatch]

@CrankyCoder How far apart are the node and gateway? What is between them? Can you post any photos of of each with the wiring?