Skip to content
  • 0 Votes
    1 Posts
    39 Views
    No one has replied
  • not understanding Smart Sleep

    Development smartsleep sleep api
    6
    0 Votes
    6 Posts
    122 Views
    rejoe2R
    @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...
  • send() after receive()

    Development sleep smartsleep
    7
    1 Votes
    7 Posts
    95 Views
    H
    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!
  • 0 Votes
    3 Posts
    1k Views
    O
    @gohan thanks, however the issue i'm having is not in the HVAC implementation, but in the messaging..
  • 0 Votes
    3 Posts
    2k Views
    S
    Nice. Didn't know that. But still it would be a great feature for the gateway to give every one the feature of smartSleep despite the controller.

18

Online

11.7k

Users

11.2k

Topics

113.0k

Posts