@jkandasa I test the latest SNAPSHOT and it works like a charm !!!
Thanks a lot

Wonderful !!!
Option 1 works for me like a charm !

Many thanks, MyController is the best

@jkandasa Ohhh wonderfull !
You are incredible !!

Many Thanks ! I will test this when I have time
Tanks !!!

@jkandasa Perfect ! Nice Job !

@jkandasa Ticket created !
Many thanks to you for spend time on our problems

@jkandasa
Yes it's practically fixed with 2000ms
99% of payload are send and ACK, sometimes payload are NACK , I think it's my gateway (Raspberry Pi with NRF24L01+ on serial with mycontroller on it too)
So I still have a way of knowing if payload is ACK (other than show in Mysensors LOG ?)

@jkandasa
OHHHH wonderfull !!! I will try this !
Many thanks !

@jkandasa Thanks for your response
I already use "aliveCheckInterval" propreties with value 7 (minutes)
(you have create this after my request : http://forum.mycontroller.org/topic/109/best-way-to-check-status-of-mysensors-sleeping-node/3 , many thanks for this)
But my Smart Sleep nodes have a particular way of doing his jobs :
They sleep during X seconds for an number of loop without Smart Sleep (so no heartbeat sended, no wait for response) and after T (threshold) loops , do a smart sleep, then restart his cycle...
For example :
My Node do normal sleep during 300 seconds (X) with threshold 10, so after 10 loop of normal sleep, it makes a smart sleep (heartbeat send + wait 2 seconds).

I do this for battery saving (less wait time).
Maybe I'm wrong and I should always do smart sleep....
Or set aliveCheckInterval to 50 minutes (300*10)

Hi,
My nodes are only Smart sleep enabled with sleep duration of 60 minutes
When they wake up, nodes do job and send heartbeat response before sleep.
At this moment, MyController ask many Heartbeat request (I think they are queud during 60 minutes).
Sample log :

mysgw: TSF:MSG:READ,4-4-0,s=255,c=3,t=22,pt=5,l=4,sg=0:206897
mysgw: TSF:MSG:SEND,0-0-4-4,s=255,c=3,t=18,pt=0,l=0,sg=0,ft=0,st=OK:
mysgw: TSF:MSG:READ,4-4-0,s=255,c=3,t=22,pt=5,l=4,sg=0:207241
mysgw: TSF:MSG:SEND,0-0-4-4,s=255,c=3,t=18,pt=0,l=0,sg=0,ft=0,st=OK:
mysgw: TSF:MSG:READ,4-4-0,s=255,c=3,t=22,pt=5,l=4,sg=0:207291
mysgw: TSF:MSG:SEND,0-0-4-4,s=255,c=3,t=18,pt=0,l=0,sg=0,ft=0,st=OK:
mysgw: TSF:MSG:READ,4-4-0,s=255,c=3,t=22,pt=5,l=4,sg=0:207438
mysgw: TSF:MSG:SEND,0-0-4-4,s=255,c=3,t=18,pt=0,l=0,sg=0,ft=0,st=OK:
mysgw: TSF:MSG:READ,4-4-0,s=255,c=3,t=22,pt=5,l=4,sg=0:207471

Here they a way to remove duplicate call in queue ?
Thanks

Hi,
I have only Nodes with Smart sleep enabled. So when I send payloads, they are queued until nodes heartbeat back.
Is there a way to see this queue ?
Thanks in advance

@jkandasa
Yes it's practically fixed with 2000ms
99% of payload are send and ACK, sometimes payload are NACK , I think it's my gateway (Raspberry Pi with NRF24L01+ on serial with mycontroller on it too)
So I still have a way of knowing if payload is ACK (other than show in Mysensors LOG ?)

Hi,
I have a battery node with Option "Smart sleep" enabled. (I use NRF24L01+ with auto ack)
So my sensor wake up, does his job, send heartbeat wait for smart sleep wait duration (in mysensors/myconfig.h : MY_SMART_SLEEP_WAIT_DURATION_MS (500ul)) then sleep

During this sleep wait, mycontroller try to send payload (for change status : Message Type:V_STATUS to 1) and sometimes is not fast enought
I see this log in mysensors :

mysgw: !TSF:MSG:SEND,0-0-1-1,s=1,c=1,t=2,pt=0,l=1,sg=0,ft=0,st=NACK:1

We see that send status is : st=NACK:1, so my node not receive this payload
But mycontroller keep the new value of this var (1) instead of keep 0 (because NACK)
Is there a solution for this case ?

Thanks

@jkandasa I test the latest SNAPSHOT and it works like a charm !!!
Thanks a lot

@jkandasa Unfortunately, I just tried the latest build with this feature, and it does not work for me,
my sensors and nodes have exactly the same name (It's the same source code).....

@jkandasa Ohhh wonderfull !
You are incredible !!

Many Thanks ! I will test this when I have time
Tanks !!!

@jkandasa
No problem, I understand that this is really a specific request
I will continue to use my script, it works

Thanks for your response