smart sleep inconsistent?
-
The 30 seconds is what is passed to the smart sleep function based on the smartsleep() documentation. In this case SLEEP_TIME = 30000. The other stuff in the code around the millis() check i understand would be halted, but I believe the smart_sleep is different based on the documentation.
#ifdef MY_DEBUG Serial.println("Going to sleep"); #endif smartSleep(SLEEP_TIME); #ifdef MY_DEBUG Serial.println("Awake Now"); #endif -
Another quick update. I hooked my gateway up to my computer to get some debug logs off it. I am not seeing ANYTHING coming from that node using smartsleep at all. So it does appear the issue is specifically with that node.
Since it's battery powered i am going to see if i can get serial connected up without a reset and see what's it saying but i have a feeling it's going to be what ive seen before and it's having a hard time finding a parent for some reason. Not sure how to fix that.
-
Another quick update. I hooked my gateway up to my computer to get some debug logs off it. I am not seeing ANYTHING coming from that node using smartsleep at all. So it does appear the issue is specifically with that node.
Since it's battery powered i am going to see if i can get serial connected up without a reset and see what's it saying but i have a feeling it's going to be what ive seen before and it's having a hard time finding a parent for some reason. Not sure how to fix that.
@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_HIGHoptions for power are MIN, LOW, HIGH, MAX. - it might help.
-
@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.
-
@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. :)
-
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:0Running 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 -
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:0Running 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 -
@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 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?
-
!TSM:INIT:TSP FAILindicates 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_RF24to get more details.@mfalkvidd Will add this now.
-
@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 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?
@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
-
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.

-
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.

-
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.

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