@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 :grinning: . 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...

From what I understood, the solution from @tmandel was meant to revoke sleep based on incoming message. I needed to delay sleep due to messages waiting in the outgoing queue. At the end, I just got my fork of MySensors and added additional extern callback to MySensorsCore.cpp/_sleep just after the pre-sleep wait(MY_SMART_SLEEP_WAIT_DURATION_MS). The callback is then implemented in my source, where I check whether the oubound queue is empty. If not, MY_SLEEP_NOT_POSSIBLE is returned and the queue is flushed immediately in the next loop(). It may be crude but... hey, it keeps my flowers watered. Many thanks for the advice and the direction provided!

@Floca Your node is defined as repeater, and repeaters do not sleep by definition: See log: 65890 !MCO:SLP:REP To disable repeater mode, comment this line (writing "Disabled" won't work): #define MY_REPEATER_FEATURE Disabled

@Sergio-Rius delay is actually the easiest way to do it :) Either that, or build a hardware debouncer. See also https://www.mysensors.org/build/binary for how to use the bounce2 library to handle debouncing. That solution doesn't support interrupts though, so delay is probably a better solution for your node.

Ok I got it to work. I misunderstood how the interrupts worked. Got it now. The culprit was the if statement detecting if the state changed. Since the state was being maintained while sleep, it wasn't firing when I pushed the button. Thanks for everyones help!!

oh it's really long .. thanks.

Yea, now I understand how to use that!! I will do that, thats probably the best... will try! Thanks alot everybody involved! @martinhjelmare @AWI @Yveaux

@hek Accordingly to LowPower library documentation, library support Atmega32U4 processor, so should work on Leonardo. Look's like i need to investigate deeper.

@hek Just a hunch, could it be the radio that somehow is stuck in receive mode, and not going to sleep? If I remember correctly from the datasheet, it almost uses the same current in both transmit and receive mode (~14mA) / Thomas