Probleme mit smartSleep

Begonnen von Fathi, 17 September 2019, 10:09:32

Vorheriges Thema - Nächstes Thema

Fathi

Hallo,

ich setzte fhem mit mysensors seit ca. 1,5 Jahren ein und bin eifriger Leser diese Forums. Jetzt habe ich den ersten Node mit smartSleep in Betrieb genommen und bin prompt auf ein Problem gestossen, womit ich allein nur noch schwer weiterkomme. Das Problem ist, daß das reading "sleepState" ständig auf "awake" gestanden hat (ebenfalls nowSleeping auf 0) und somit das verzögerte Senden von Nachrichten von fhem an den Node nicht funktioniert. Nachdem ich geprüft hatte, daß die I_PRE_SLEEP_NOTIFICATION Nachricht vom Node ankommt, musste ich mich am Modul 10_MYSENSORS_DEVICE.pm vergehen, obwohl Perl und ich nicht wirklich Freunde sind.

Herausgekommen ist folgendes:
In onInternalMessage($$) gibt es den Abschnitt

    $type == I_PRE_SLEEP_NOTIFICATION and do {
        #$hash->{$typeStr} = $msg->{payload};
        refreshInternalMySTimer($hash,"Asleep");
        refreshInternalMySTimer($hash,"Alive") if $hash->{timeoutAlive};
        MYSENSORS::Timer($hash);
        sendRetainedMessages($hash) ;
        last;
    };


Dort wird über die Funktion refreshInternalMySTimer ein Timer auf MYSENSORS::DEVICE::timeoutAwake gesetzt, welche dann das Reading "sleepState" richtig setzt. Der Timer wird laut Logdatei richtig gesetzt, die Funktion jedoch wird niemals aufgerufen nach Log (wahrscheinlich auch MYSENSORS::DEVICE::timeoutAlive, aber das habe ich nicht kontrolliert). Wenn man jetzt aus dem obigen Codeabschnitt die Anweisung "MYSENSORS::Timer($hash);" entfernt, funktioniert scheinbar alles. Und nun die Frage, liegt es an mir oder am Modul, daß es nicht funktioniert? Ich überblicke leider die Funktion der Anweisung "MYSENSORS::Timer($hash);" noch nicht und somit auch die Seiteneffekte deren Entfernung.

Vielen Dank schon einmal vorab für die Hilfe und falls ich mich irgendwelcher formaler Vergehen beim schreiben hier schuldig gemacht haben sollte, ich lerne gern dazu.

Gruß
Jan


Beta-User

Vorab mal willkommen im Forum!

Wie hast du überprüft, ob die I_PRE_SLEEP_NOTIFICATION ankommt?

(Mit Bordmitteln: Verbose der Node auf 5 stellen oder Zeile 1105 so anpassen, dass dort ein kleinerer Verbose-Level genutzt wird).

Die paar Zeilen sind m.E. so korrekt, die machen folgendes:
- Timer setzen, der das sleepState-Reading nach kurzer Frist auf "schläft" setzt (und das Internal) - dieser Timer sollte auch ablaufen.
- Timer setzen, der bei Ablauf die Node als "dead" meldet - dieser Timer sollte nie ablaufen, sondern immer wieder rechtzeitig neu gesetzt werden.
- MYSENSORS::Timer($hash) versendet alle ausstehenden Messages der Node nochmal, für die erfolglos ein ACK angefordert wurde => das sollte auch aktiviert bleiben...
- Die letzte Zeile schließlich versendet "normale" Messages, die gequeuet wurden, weil die Node schlief (und die das GW deswegen noch gar nicht "kennt").

M.E. spricht einiges dafür, dass die I_PRE_SLEEP_NOTIFICATION zwar von der Node versendet wurde, aber nicht beim GW ankam => Funkproblem. Bitte wie oben beschrieben Verbose oder Log-Level der Zeile ändern und mal da nachsehen, ob wirklich was ankommt. Wenn Funkproblem, als erstes checken, ob das mit dem Kondensator paßt. (ist doch nRF24, oder?).

Kann aber auch sein, dass ich mich täusche.

Gruß, Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Fathi

Danke für die schnelle Antwort, die Erklärungen und die Begrüßung!

Ja, ich benutze ein nrf24l01 mit Kondensator. Andere Nachrichten werden auch korrekt empfangen. Kontrolliert habe ich es mit Verbose auf 5 setzten. Da dann die Meldung ... Awake timeout timer set at ... im Log aus Zeile 1122 kam, bin ich davon ausgegangen, das die I_PRE_SLEEP_NOTIFICATION angekommen ist. Nur die Meldung aus Zeile 1150 ("timeoutAwake called") wird nicht ausgegeben, erst wenn ich die besagte Anweisung entferne. Einen Log-Ausschnitt kann ich leider erst heute Abend einstellen.

Gruß
Jan

Beta-User

Hmm, ok, Danke für die weiteren Hinweise.

Du hast vermutlich einen Bug gefunden ::) .

Kannst du die fragliche Zeile in 10_MYSENSORS_DEVICE.pm wieder aktivieren und stattdessen Zeile 558 in 00_MYSENSORS.pm wie folgt ändern:
RemoveInternalTimer($hash,"MYSENSORS::Timer");

Bitte um Rückmeldung, ob das klappt und ob sonstige Seiteneffekte sichtbar sind (ich müßte sonst meine Testnodes rauskramen)...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Fathi

Man, das war schnell!
Nein, Deine Testnodes brauchst Du nicht raussuchen. Ich teste das heute Abend und werde die Ergebnisse gegen 18:30 Uhr hier einstellen.
Nochmal vielen Dank!


Gruß
Jan

Fathi

#5
Die Änderung in 00_MYSENSORS.pm hat funktioniert!  ;D
10_MYSENSORS_DEVICE.pm ist im Originalzustand, sleepState wird aktualisiert, heartbeat auch. Nachrichten werden gespeichert und gesendet, wenn der Node sich wieder meldet.
Alles andere sieht auch normal aus. Wenn ich noch etwas testen soll, sag bescheid.

Danke !

Jan


-------
Auszug aus Log-Datei (Verbose 5, timeoutAlive: beim loggen auf 2 Sekunden geändert):

2019.09.17 18:25:52 5: KellerSensor is sleeping, enqueing message!
2019.09.17 18:25:58 5: KellerSensor: refreshInternalMySTimer called (Alive)
2019.09.17 18:25:58 5: KellerSensor: refreshInternalMySTimer called (Alive)
2019.09.17 18:25:58 4: MYSENSORS_DEVICE KellerSensor: batteryPercent 100
2019.09.17 18:26:08 5: KellerSensor: refreshInternalMySTimer called (Alive)
2019.09.17 18:26:08 5: KellerSensor: refreshInternalMySTimer called (Alive)
2019.09.17 18:26:08 4: MYSENSORS_DEVICE KellerSensor: batteryPercent 100
2019.09.17 18:26:08 5: KellerSensor: refreshInternalMySTimer called (Asleep)
2019.09.17 18:26:08 5: KellerSensor: Awake timeout timer set at 1568737569.19338
2019.09.17 18:26:08 5: KellerSensor: refreshInternalMySTimer called (Alive)
2019.09.17 18:26:08 5: KellerSensor is not sleeping, sending message!
2019.09.17 18:26:09 5: KellerSensor is not sleeping, sending message!
2019.09.17 18:26:09 4: MYSENSORS_DEVICE KellerSensor: respond to config-request, node parentId = 0
2019.09.17 18:26:09 5: KellerSensor: timeoutAwake called
2019.09.17 18:26:19 5: KellerSensor: refreshInternalMySTimer called (Alive)
2019.09.17 18:26:19 5: KellerSensor: refreshInternalMySTimer called (Asleep)
2019.09.17 18:26:19 5: KellerSensor: Awake timeout timer set at 1568737579.8413
2019.09.17 18:26:19 5: KellerSensor: refreshInternalMySTimer called (Alive)
2019.09.17 18:26:19 5: KellerSensor: timeoutAwake called
2019.09.17 18:26:21 5: KellerSensor: refreshInternalMySTimer called (Alive)
2019.09.17 18:26:23 5: KellerSensor: timeoutAlive called
2019.09.17 18:26:28 5: KellerSensor is sleeping, enqueing message!
2019.09.17 18:26:30 5: KellerSensor: refreshInternalMySTimer called (Alive)
2019.09.17 18:26:30 5: KellerSensor: refreshInternalMySTimer called (Asleep)
2019.09.17 18:26:30 5: KellerSensor: Awake timeout timer set at 1568737590.51633
2019.09.17 18:26:30 5: KellerSensor: refreshInternalMySTimer called (Alive)
2019.09.17 18:26:30 5: KellerSensor is not sleeping, sending message!
2019.09.17 18:26:30 5: KellerSensor: timeoutAwake called
2019.09.17 18:26:32 5: KellerSensor: timeoutAlive called


Beta-User

Danke für's eingrenzen des Problems, überraschend, dass das sonst bisher niemand aufgefallen war.

Hab's eben im svn eingecheckt, kommt also morgen per update.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Fathi

Naja, damit das auffällt, braucht man einen batteriebetriebenen Node (sonst macht ja sleep oder smartSleep nicht wirlich Sinn) und muss noch auf die Idee kommen, Nachrichten aktiv an den Node zu senden. Da ich gerade meine Batterie- und Solarnodes auch auf "Konfiguration zur Laufzeit" umstelle, bin ich in bisschen davon abhängig, ansonsten wäre es mir auch nicht aufgefallen. Aber sieht klasse aus, wie "sleepState" jetzt zappelt.  8)

Gruß
Jan

Beta-User

Hmm, vermutlich mußte neben dem Senden noch eine ACK-Anforderung dazukommen...

Das mit "Konfiguration zur Laufzeit" (@battery) klingt interessant. Vielleicht magst du bei Gelegenheit mal ein Beispiel in einem separaten Thread oder den "Lösungsansätzen" darstellen (Sketch+FHEM-Seite). Ist evtl. für noch mehr Leute interessant, wie das geht usw... :) .

Ansonsten freut es mich sehr, dass jemand an diesem feature Gefallen findet 8) . Es war für meine auch eher bescheidenen Perl-Kenntnisse  eine ziemlich harte Nuß, den vorhandenen Perl-Code so aufzubohren, dass das "zappelt".

Gruß, Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files