not understanding Smart Sleep

[Stef9998]

I'm not sure if I understand correctly how the smart sleep works, hope someone can help.

The API says:

Each sleep function has a "smart" variant, which sends heartbeat and process incoming messages before going to sleep. This is useful for sending out firmwares or commands for sleeping nodes. The controller must support buffering of messages and send them when node wakes up. <<

So am I seeing it correctly, that the node is only sending a heartbeat and then process incoming messages before it goes to sleep and nothing after waking up?
Because if the controller is supposed to start buffering messages, it has to know that a node is going to sleep, and a heartbeat shouldn't be enough, or am I missing something. Also I have to write my own code for the node when it wakes up, to tell the controller I'm back alive, which is also not different to the normal sleep function.

I'm probably not understanding it correctly, but how I see it now, I do not understand why I should choose the smart sleep over normal sleep.

Hope someone can enlighten me

[rejoe2]

@Stef9998 Actually, it only sends the special message "I will go to smartsleep" and no real "heartbeat" message.
All other things are handled in the controller - especially handling the queued messages. In general, imo choosing smart sleep ONLY makes sense, if you want/need OTA support for nodes you can not easily reboot by hand or want to switch, (re-) configure ... and so on at runtime.
In short: details are tricky and you have to thouroughly check what is needed on both sides - controller and node... (I had some interesting discussions here long time ago wrt. to the FHEM integration and changes in sleeptime duration. Perhaps you might search for that - imo, it should be very instructive.
(We ended up using the heartbeat signal to signalize towards the controller that the node is already in the state of listening prior to the "will-go-to-sleep-now" message).

[Stef9998]

So you probably mean this discussion? https://forum.mysensors.org/topic/10221/disable-cancel-smartsleep-while-sleep-countdown-is-running
What I get from that is that the node will send a message that it has woken up, which makes sense to me, but isn't in the documentation, which is why I was asking my question in the first place.

The reason why I want to know is, that I want to put a receiver on one of these small battery powered chain of LED-lights. The problem of course is, that having the NRF24 in RX-Mode the whole time alone will drain the 2 AAs in like 2 Weeks or something like that.
So I was planing on only waking the whole thing up with the timer interrupt of my ATmega328P and then signalling my Gateway/Controller, that the node is awake, just to go directly to sleep again if no command is given.
I know, that after I am switching it on on whatever interface I'm using with my controller it may take a while to turn the light on, but that's okay, cause it will just be ambient light anyways.

So I thought in the beginning, smartsleep will be what I need, because the controller will buffer the messages till my node will wake up again. But after reading the documentation I wasn't sure anymore.

After describing my use case, is smartsleep what I need?

[rejoe2]

@Stef9998 said in not understanding Smart Sleep:

After describing my use case, is smartsleep what I need?

I'd say yes, clearly - if your controller is supporting the smartsleep feature.

But to make it more clear: when the sketch uses smartsleep, two type of smartsleep messages will be sent out: one when waking up, the second before going to sleep. Usually, the controller should ONLY send out queued messages when the second is sent. Why? To avoid collissions on the RF layer.
The discussion you cited is the one I had in mind, and afai remember, it highlights a second aspect: usually, smartsleep is the last thing the node "does" before going to sleep. So you are able to switch sth. on in the "receive" function or change variables, but especially changing variables like the time the node will be asleep, will only have any effect when the loop is processed. Means in this case one step later than desired...

[Stef9998]

@rejoe2
I'm in the process of configuring an OpenHab instance, and the binding should support smart sleep

But to make it more clear: when the sketch uses smartsleep, two type of smartsleep messages will be sent out: one when waking up, the second before going to sleep. Usually, the controller should ONLY send out queued messages when the second is sent. Why? To avoid collissions on the RF layer.

That I don't understand. Why should the controller have queued messages when the node is sending the second type (going to sleep). The controller knows the node is awake (cause of first/awake message), so why should it start to queue them? It should just send them, and then when the controller knows, that a node will be asleep (second message) start queueing.

The discussion you cited is the one I had in mind, and afai remember, it highlights a second aspect: usually, smartsleep is the last thing the node "does" before going to sleep. So you are able to switch sth. on in the "receive" function or change variables, but especially changing variables like the time the node will be asleep, will only have any effect when the loop is processed. Means in this case one step later than desired...

The sleep time will be pretty much hardcoded into the arduino. If any changeble somehow through OTA if I need it, but then also not time critical

[rejoe2]

@Stef9998 said in not understanding Smart Sleep:

@rejoe2
I'm in the process of configuring an OpenHab instance, and the binding should support smart sleep

Don't know about OH's abilities, I "just" did the FHEM implementation of that feature .

That I don't understand. Why should the controller have queued messages when the node is sending the second type (going to sleep). The controller knows the node is awake (cause of first/awake message), so why should it start to queue them? It should just send them, and then when the controller knows, that a node will be asleep (second message) start queueing.

The user or some automatics could create some message to be sent out at any point in time. But sending out any message only makes sense when the controller knows the node is actually listening - these are sparse blinks in time, so most of the time a message will be queued first (or let's call it retained to stick to mqtt conventions).
Then the controller has to wait for a signal from the node side, but as described earlier, this should not be the "awake" message (meaning a sensor can deliver some values and so on), but the "will go to sleep" one (meaning: "I will stop talking now, but continue to listen for 500 ms now").
Hope the fog is clearing now...