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

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?

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