Smart Sleep

[KarlHeinz2000]

Kurze Fragen zum Verständnis:
1. Der Übergang "asleep" zu "awake" wird durch eine beliebige Message ausgelöst, nicht zwangsläufig nur I_POST_SLEEP_NOTIFICATION?
2. Sobald der Node "awake" ist, werden anstehende Messages von FHEM an den Node gesendet?

Hintergrund:
Ein batteriebetriebener Node soll regelmäßig aufwachen. Nach dem Aufwachen eine Aktion triggern und gleich wieder für kurze Zeit schlafen gehen (Strom sparen), bis die Aktion fertig ist. Danach werden Werte an FHEM gesendet.
Mit smartsleep bekomme ich Probleme mit Daten, die von FHEM an den Node gesendet werden sollen, falls die in die 'kurze Zeit schlafen' fallen. Darum will ich nur "sleep" verwenden; mit irgendeiner Message "awake" triggern und lieber in der loop noch z.B. 500ms auf Daten warten. Dann müsste ich nur noch FHEM mitteilen, dass der Node wieder schlafen geht. Die I_PRE_SLEEP_NOTIFICATION mit 1ms o.ä. senden (sofern das einfach geht).

[Beta-User]

Zu 1.: Müßte ich im Code nachschauen, es ist jedenfalls mehr als nur die post-sleep-Message, was "aufgewacht" verursacht.

Zum Ganzen (aus dem Kopf zitiert, daher mit einem gewissen Restrisiko):
Der Ablauf ist der, dass grundsätzlich alles, was beim Aufwachen an Messages zwischengepuffert war, erst dann versendet wird, wenn die pre-sleep-Notification kommt. Damit soll vermieden werden, dass sich der Funkverkehr kreuzt, was definitiv zu Problemen führen würde. Versendet wird allerdings gleich, was der Controller an Sendeanweisungen in der Wachphase generiert (das kann lange sein, wenn die pre-sleep-Notification verloren wurde...).
Erst die pre-sleep-Message löst das Senden der gequeueten Messages aus (= Node meldet, dass sie selbst fertig ist mit Senden, und dann noch eine kurze Zeit (500L, meine ich) bereit zum Empfangen ist). Man kann das Verhalten etwas beeinflussen, indem man eine heartbeat-Message von der Node schickt, das wird auch als "bin fertig"-Info bewertet (kann sein, dass auch eine ACK-Message dieselbe Wirkung hat).

Weiß FHEM, dass die Node schläft (=nach Ablauf der 500ms default nach Erhalt der pre-sleep-Message abzgl. einem kleinen Puffer für eventuelle Delays zum GW = effektiv ca. 300ms), wird die Sendeanweisung in eine Queue geschoben, bis die Node "empfangsbereit" meldet wie oben beschrieben.

Kurzfassung: MMn. brauchst du nicht so viel "drumrum" zu denken, und ein "sleep", von dem FHEM nichts weiß, ist tendenziell ein Problem, weil in diesen Phasen dann Messages gesendet werden, (wenn FHEM welche generiert). Würde - ohne darüber jetzt aber allzu intensv nachgedacht zu haben - dazu tendieren, wenn, dann nur smartsleep zu verwenden und für sehr kurze Intervalle, in denen nichts passieren soll "wait" statt "sleep" zu verwenden.

[KarlHeinz2000]

Danke für die ausführliche Erklärung. Das verschafft mir Klarheit.

[Beta-User]

Thx für die Rückmeldung. Ich habe eben einen kurzen Abschnitt dazu in den "Starter Guide" eingefügt. Wäre nett, wenn du das mal gegenlesen und mit deinen Erfahrungen beim Programmieren/Konfigurieren vergleichen könntest...

[KarlHeinz2000]

Der Wiki Teil passt soweit. Einzig die Zeit nach Aufruf von SLEEP(...) bis zum wirklichen Abschalten (I_PRE_SLEEP_NOTIFICATION) ist konfigurierbar und nicht fest auf 500ms. Default ist aber 500ms.

Code Auswählen Erweitern

#define MY_SMART_SLEEP_WAIT_DURATION_MS 500

Mir ist auch noch aufgefallen, dass sleepState nur durch I_POST_SLEEP_NOTIFICATION auf awake geht. Andere ankommende Nachrichten (incl Heartbeat) haben keinen Effekt. Das ist in meinen AUgen nicht so günstig.

[Beta-User]

Danke für die Rückmeldung. Dass der Wert auf der Sketch-Seite konfigurierbar ist, ist klar, mir war nur (V2.3.1 pre) in Erinnerung, dass der Wert in Zyklen angegeben war, aber mit ms ist das einfacher.

FHEM geht immer von den 500ms aus und zieht einen kleinen Wert für delays ab; bei Bedarf dürfte es kein größeres Problem sein, das konfigurierbar zu machen. Ich habe derzeit keine smartSleep-Nodes im Einsatz, daher bitte ggf. um Rückmeldung, wenn da Bedarf für Änderungen besteht; ich habe das zwar alles soweit auf prinzipielle Funktionalität getestet, aber eben keine längerfristige eigene Erfahrung.
Zum "Schlafzustand" gibt es zwei "Orte", an denen die Info abgelegt ist, und wie du schreibst, ist das Reading von den sleep-Messages abhängig. Was die beschriebene Queue-Verwaltung angeht, ist aber ein Internal maßgebend. Ich hatte das bei meinen theoretischen Überlegungen mal aufgetrennt, weil so uU. besser zu erkennen ist, ob man Funkprobleme hat. Solche wirken sich nämlich vermutlich bei den smartSleep-Nodes potentiell viel gravierender aus als bei Nodes, die einfach nur schlafen oder immer empfangsbereit sind...

Aber wie gesagt: Wenn die graue Theorie da gegen besseres Praxiswissen weichen soll, einfach melden. (Was mir dazu grade in den Sinn kommt: Es kann z.B. auch noch sein, dass manche logischen Reihenfolgen noch nicht passen, oder bestimmte Prüfungen nicht möglich sind (das Internal wirft keine Events, man kann also nicht so einfach automatisiert prüfen, ob Reading und Internal deckungsgleich sind).

[KarlHeinz2000]

Ich bin gerade dabei meine etwas ältere Mysensors Installation zu aktualisieren. Die Nodes sind jetzt erstmal alle smatsleep, wobei mir das bzgl Stromaufnahme nicht so richtig gefällt. Darum probiere ich hier bißchen rum...
Das nowSleeping hatte ich mir gar nicht weiter angeschaut, da es kein automatisches update im Browser gibt.
Bei der Nachlaufzeit zum Senden bin ich davon ausgegangen, dass hier die jeweilige Zeit von I_PRE_SLEEP_NOTIFICATION genommen wird. Wobei diese bei mir aktuell immer 500ms ist. Vielleicht kannst du das einbauen?
Bei sleepState wäre es gut, wenn dieser bei jeder eingehenden Nachricht (auch Heartbeat, ...) auf awake geht. Auf asleep sollte er wechseln, wenn die Nachlaufzeit abgelaufen ist, oder timoutAlive zuschlägt.
Das von dir beschriebene Verhalten zum Senden an die Nodes finde ich soweit gut, habe es aber noch nicht intensiv getestet.
Wird das heartbeat reading nur von der Heartbeat Message getriggert, oder auch von jeder eingehen Nachricht?

[Beta-User]

Also:
FHEM kennt die Zeit nicht, die im Sketch eingestellt ist, da wird afaik lediglich eine Art minimalistischer "Ping" gesendet (wie bei heartbeat auch; das bedeutet auch weniger Infos, die versendet werden und damit einen geringeren Energieverbrauch + kürzeres Sendezeitfenster (=>Kollissionen)); im Moment wird von 500ms ausgegangen.
Damit hatte ich erst experimentiert, allerdings sind dann Messages an die Node verloren gegangen. Daher ist jetzt die effektiv von FHEM zum Senden verwendete Zeit kürzer als das maximale Fenster. Da die Zeit auf der Node einerseits lange genug sein muß, um realistisch noch was empfangen zu können, andererseits aber den Stromverbrauch erträglich zu halten, finde ich den MyS-default an der Stelle sinnvoll, über meinen Abzug kann man streiten, es hat sich aber bisher keiner beschwert (nur im Sketch-Code besteht seither die Möglichkeit, den Timer zum Schlafengehen noch abzubrechen...). Für die Nachlaufzeit Konfigurationsoptionen einzubauen, ist zwar möglich, andererseits aber vermutlich für die Mehrzahl der Nutzer eher verwirrend. Automatisiert ermitteln geht jedenfalls nicht ohne weiteres.

sleepState ist triggernd ausgelegt (und updates dazu sollten daher im Browser auch ohne Reload sichtbar sein), das Internal nicht (daraus ergibt sich btw. eine Möglichkeit festzustellen, ob die pre-/post-Messages verloren gegangen sind). MMn. ist es sinnvoll, die Zahl der Trigger von vornherein sinnvoll zu begrenzen, das war übrigens auch einer der Gründe für die Trennung in Internal (nowSleeping) und Reading, über diesen Weg habe ich auch beim Entwickeln festgestellt, welche Zeitfenster in etwa sinnvoll sind.
Gehen die sleep-Messages verloren, hat man ein Problem, und mMn. ist es besser, das durch eine Begrenzung der zu sleepState passenden Messages entsprechend einzugrenzen; hier alles zu berücksichtigen und verschiedene Timersysteme zu mischen finde ich jedenfalls im Moment nicht zielführend.

Was smartSleep und heartbeat angeht:
Grundsätzlich macht es bei smartSleep-Nodes keinen großen Sinn, zusätzlich heartbeat zu senden, (es sei denn, man will Nachrichten aktiv abrufen). Das "heartbeat"-Reading (bzw. die Timer dahinter) wird bei smartSleep-Nodes durch die pre- und post-Messages getriggert, man muß da also nichts "extra" machen (und Energie aufwenden).
Daher wird (nur) die "heartbeat"-Message bei smartSleep-Nodes (nur) dazu "ge-/mißbraucht", vorzeitige Empfangsbereitschaft zu signalisieren .

[KarlHeinz2000]

Die Nachlaufzeit wird aktuell von den Nodes in der Message I_PRE_SLEEP_NOTIFICATION als Payload (Zeit in ms) mit gesendet. Daher dachte ich (mit meinen nicht vorhandenen Perl Kenntnissen  ), dass es ohne größeren Aufwand möglich sein sollte diese Zeit (minus z.B. 200ms) als Nachlaufzeit zu verwenden.

Heartbeat wir aktuell nur von der heartbeat Message und I_..._SLEEP_NOTIFICATION getriggert. Falls es nicht die Intension war nur auf genau diese 3 Nachrichten zu triggern, wäre es robuster wenn alle eingehenden Nachrichten den timeout Timer zurücksetzen würden.

Bei sleepState verhält es sich analog. Nur diese drei Nachrichten triggern auch ein awake. Hier wäre es schon sinnvoll, wenn alle Nachrichten ein awake triggern würden, denn der Node ist definitv wach. Asleep würde wie bislang durch die I_PRE_SLEEP_NOTIFICATION getriggert. Das ist smartsleep kompatibel und flexibler.

Ich kann auch mit der bisherigen Implementierung leben, nur könnte die so etwas flexibler werden.

[Beta-User]

Das mit der Payload ist mir neu, aber das ist dann wirklich hilfreich und sollte auch leicht umzusetzen sein . Vorschlag dazu kommt dann noch (zum Testen), da brauche ich etwas Ruhe für.

Was die heatbeat und sleepState-Dinge angeht, war es wirklich Absicht, da die Event-Generierung zu reduzieren. Wenn sich mehr User finden, die für mehr Events sind, läßt sich das ändern, aber m.E. ist das nicht erforderlich bzw. man erhält dann auch keine Hinweise auf eventuelle Funk-Probleme.

[KarlHeinz2000]

Und wenn gerade Wunschkonzert ist ...
Ein disable Attribut für die Nodes wäre gut, so dass nichts mehr empfangen und gesendet wird.
Hintergrund: zB. beim Batteriewechsel müssen Nodes abgebaut oder reingeholt werden. Dabei werden die Sensoren falsch gelesen. Das geht in die Filelogs, statistics, etc. hinein. Darum muss ich vorher die Module alle deaktivieren, bzw ich weise dem Node ein Gateway zu, das physikalisch nicht passt. Es wäre einfacher einen Node zu disablen und gut.
Aber nur ein nice to have...

[Beta-User]

Das mit dem disable schaue ich mir bei Gelegenheit mal an, sollte kein Hexenwerk sein.

Anbei mal erst mal eine Testversion für die Verwendung der Payload zur Bestimmung der Nachlaufzeit. Das, was die Node sendet, sollte dann in einem neuen Internal im list zu finden sein. Nicht erschrecken, da sind auch ein paar Zeilen geändert, die mit diesem Thema hier nichts zu tun haben, (möglicherweise in diesen Teilen) noch nicht funktionieren, aber u.a. ein warning und einen kaputten Link in der cref beseitigen sollten...

[KarlHeinz2000]

Absturz 
RadioID 73 gibt es bei mir nicht.

Code Auswählen Erweitern

2019.11.12 21:02:05 3: MYSENSORS: ignoring internal-msg from unknown radioId 73, childId 255 for I_HEARTBEAT_RESPONSE
Undefined subroutine &MYSENSORS::DEVICE::max called at ./FHEM/10_MYSENSORS_DEVICE.pm line 1122.

[Beta-User]

Die RadioID war eher nicht der Grund, das dürfte eine "normale" Meldung gewesen sein (hast du evtl. einen bastelnden Nachbarn?).

"Zu Fuß" und ohne max sollte es funktionieren...

[KarlHeinz2000]

ok, sieht gut aus. Läuft ohne Fehlermeldung. Unterschiedliche preSleep werden angezeigt. Allerdings konnte ich auf die Schnelle nicht testen, ob das Senden auch tatsächlich in dieser Zeit stattfindet. Dafür brauche ich einen anderen Aufbau.