WakeUp, Scheduled Tasks Probleme

[hanske]

@krikan
Ich habe ja den PSP01, der müsste Deinem PSM02 ziemlich ähnlich sein.
Der schickt zuverlässig die  "wakeup notification". Hatte bei einem anderen Sensor auch schon Ausfälle gesehen.
Ich kann ja mal Deine beiden Zeilen:

Code Auswählen Erweitern

push @list, "frequentListening:" . ($r[3] & ( 0x20 | 0x40 ));
push @list, "beaming:" . ($r[3] & 0x10);
einfügen und Dir dann berichten.
Programmieren kann ich schon, aber mit Perl kenne ich mich gar nicht aus.

[krikan]

@hanske

Der schickt zuverlässig die  "wakeup notification". Hatte bei einem anderen Sensor auch schon Ausfälle gesehen.

Drücke mich wahrscheinlich unverständlich aus:  "wakeup notification" kommt regelmäßig solange keine ausstehenden Befehle im Sendstack. Wenn Befehle im sendstack, dann wurden die genau zum Zeitpunkt der üblichen "wakeup notification" verschickt und verarbeitet, das Event "wakeup notification" kam aber dann nicht. Das begreife ich nicht. Ich glaube eher nicht an Ausfälle, als an eigene Dummheit. Muss noch mal weiterprobieren.

Bei meinen beiden Code-Zeilen würde mich interessieren, was Deine Geräte ausspucken. Ob wir das aber letztlich brauchen, weiß ich leider nicht.

Programmieren kann ich schon, aber ...

War keinesfalls böse gemeint, bevor hier Mißverständnisse aufkommen  . Perl kann ja noch werden!

Gruß, Christian

[krikan]

eigene Dummheit

genau so ist es (ungenügende Versuchsreihe bzw. zu viel gleichzeitig verändert):
Die Auto battery reports des Sensors wurden zum Zeitpunkt der "wakeup notification" ebenfalls verschickt. Diese battery reports führen beim PSM02 dazu, dass die "wakeup notification" ausbleibt und er wach ist. Zudem führen battery reports dazu, dass die Startzeit für die nächste "wakeup notification" neu gesetzt wird.
Damit hat meine Theorie bezüglich Wachzustand gewisse Brüche. Oder ist ein battery report nichts anderes als eine "wakeup notification"? Dazu brächte man Vergleichsensoren.

Das ändert aber nichts an meinen Ausführungen zu den ACK von oben.

[hanske]

Ich habe alle meine Geräte mit Deinem Patch getestet.
Genau wie bei Dir:

Code Auswählen Erweitern

frequentListening:0 beaming:16
Kann also irgendwas nicht stimmen.

Zu Deiner anderen Frage:
Bei meinem PSP01 kommen "wakeup notification" und "battery" Meldungen asynchron, kann aber sein, dass es bei Deinem Gerät anders implementiert ist.
Den Battery Report kann man bei mir auch getrennt einstellen über:

Code Auswählen Erweitern

Auto Report Battery Time (Parameter Number 10, Parameter Size 1) interval time for auto report the battery level
1 — 127 30 minutes per tick and minimum time is 30 minutes, default tick is 12 (6 hours) (Default 12)

Wahrscheinlich muss bei der Stapelverarbeitung wirklich erst mal der "arme Rudi" ran.
Bis ich Perl kann sind wahrscheinlich schon etliche Neunutzer verzweifelt.
Bei mir ist ja erst mal alles konfiguriert 

[krikan]

Kann also irgendwas nicht stimmen.

Bin ich nicht sicher. Vermutlich geben die Werte für frequentListung und beaming nur in Kombination mit den anderen nodeInfo-Werten einen Sinn. Warum würde sonst das openzwav-control-panel bei mir zu den gleichen Werten kommen? Die Entwickler von openzwave werden sich doch was dabei gedacht haben.

Bei meinem PSP01 kommen "wakeup notification" und "battery" Meldungen asynchron, kann aber sein, dass es bei Deinem Gerät anders implementiert ist.
Den Battery Report kann man bei mir auch getrennt einstellen über

Kann man bei meinem auch und genau die Spielerei daran, hat zu meinem Irrtum geführt. Nach Reset auf Default kam die Erkenntnis.

Wir haben jetzt immerhin ein paar Erkenntnisse und kennen die Abhilfe/Lösung. Ob das geändert werden sollte oder nicht, kann ich nicht wirklich beurteilen, da ich die möglichen negativen Nebeneffekte und Probleme nicht kenne. Von Rudis Zeit/Spaß ganz zu schweigen.....

----
Im übrigen habe ich gerade einmal 20 get configs im sendstack gleichzeitig bei der "wakeup notification" abarbeiten lassen. Das läuft mit Rückantworten ohne Probleme durch. Während schon ein get config im sendstack bei Türöffnungstelegrammen zu dauernden CAN-Fehlern führt. Keine Ahnung, ob das evtl. bei Rudis zweiten Teil der Frage 

wer das "011301" sendet (Geraet oder Dongle, soll ein Ack sein), und ob FHEM darauf die weiteren Befehle schicken kann, oder erst warten soll oder was.

beiträgt. Demnach tendiere ich zu sofort. Mir ist unbekannt, wie ich das durch Test absichern könnte.

[rudolfkoenig]

Ich habe leider im Moment nicht die Zeit fuer laengere FHEM-Experimentier-Sessions. Ich beobachte aber diese Diskussion und kann gerne patches ueberfliegen/testen/einchecken, am besten bitte direkt als solches markieren. Und habt von perl keine Angst, es kann doch nichts schiefgehen (wenn man vorher eine Sicherung gemacht hat :)

"Sofort" (was auch immer das meint) schicken funktioniert nicht, habs frueher getestet.
Ich behaupte, mehr als ein Befehl auszusenden ohne auf irgendein Ack zu warten klappt nicht.

Testen kannst Du deine Theorie aber trotzdem, indem du

Code Auswählen Erweitern

    if($hash && $hash->{WakeUp} && @{$hash->{WakeUp}}) {
      IOWrite($hash, "00", shift @{$hash->{WakeUp}});
    }
in 10_ZWave.pm/ZWave_Parse() dahin platzierst, wo es deiner Ansicht nach sinnvoll ist.
Und wo sinnvoll ist, kann man schrittweise mit zusaetzlichen Zeilen wie

Code Auswählen Erweitern

Log 1, "Debug line ".__LINE__;
eingrenzen. Mit der Zeit muss man nicht mehr die Nachrichten abwarten, und schauen, welche "Debug line" Zeilen erscheinen, weil man zunehmend den Code versteht.

[hanske]

Wenn ich den Code von 10_zwave.pm richtig verstehe, macht es doch nur in der "while(@args)" Schleife von Zeile 985ff Sinn.
Nur dort habe ich doch den "Classname" zur Abfrage Verfügung.
Mein Patch

Code Auswählen Erweitern

# send stored requests
if($className eq "WAKE_UP") {
  my $wu = $baseHash->{WakeUp};
  if($wu && @{$wu}) {
shift @{$wu} if($wu->[0] eq "");
IOWrite($hash, "00", shift @{$wu}) if(@{$wu});
  }
  # todo send a final wakeupNoMoreInformation
}
hat ja leider nicht vollständig funktioniert. Es sind immer wieder Nachrichten im Stack geblieben.
Dabei hatte ich das ja eigentlich nur von ein paar Zeilen weiter unten nach oben verschoben. Vorher wurde ja immer der ganze Stack verschickt (nur leider zum falschen Zeitpunkt)
Meinst Du Dein Code:

Code Auswählen Erweitern

if($hash && $hash->{WakeUp} && @{$hash->{WakeUp}}) {
      IOWrite($hash, "00", shift @{$hash->{WakeUp}});
    }
bringt an dieser Stelle eine Verbesserung?

Erstmal soll ja nur der ganze Befehlsspeicher abgeschickt werden.
Um ein Acknowledge und das finale "wakeupNoMoreInformation" kann man sich (ich mich) dann ja später kümmern

[hanske]

Ich habe mir gerade mal die Perl Syntax etwas angesehen.
Dein Code:

Code Auswählen Erweitern

if($hash && $hash->{WakeUp} && @{$hash->{WakeUp}}) {
      IOWrite($hash, "00", shift @{$hash->{WakeUp}});
    }
schreibt doch nur einen gespeicherten Befehl raus, oder?
Das war wahrscheinlich mein Problem.

Kann ich stattdessen

Code Auswählen Erweitern


if ($hash){
   foreach (@{$hash->{WakeUp}}) {
      IOWrite($hash, "00",$_);
}
}

schreiben?

[hanske]

Ich habe jetzt eine Lösung die gut funktioniert.
Ist zwar nicht besonders elegant programmiert, für mich aber einfacher verständlich.
Ich werde das aber noch weiter testen.

Code Auswählen Erweitern


# send stored requests
if($className eq "WAKE_UP") {
  if ($hash){
foreach (@{$hash->{WakeUp}}) {
IOWrite($hash, "00",$_);
Log3 $hash, 4, "Sending stored command: $_";
}
@{$hash->{WakeUp}}=();
    #send a final wakeupNoMoreInformation
my $nodeId = $hash->{id};
IOWrite($hash, "00", "13${nodeId}02840805");
Log3 $hash, 4, "Sending wakeupNoMoreInformation to node: $nodeId";
  }
}

[krikan]

@hanske
Wo müsste Dein Code genau hin (Zeile), damit ich am Wochenende mittesten und grübeln kann?

@Rudi
Danke für Deinen Analysetipp, probiere ich mal aus.

[hanske]

Ab Zeile 1000:

Code Auswählen Erweitern


      push @args, substr($arg, $off*2, $l*2);
         $off += $l;
       }
       next;
    }

# HIER NEUER CODE

    my $ptr = ZWave_getHash($hash, $className, "parse");
    if(!$ptr) {


Ich wollte auch noch eine Patchdatei erstellen , aber mein GIT funktioniert gerade nicht.

[hanske]

Die alte Implementierung muss dann natürlich auch noch raus.
Anbei das Patchfile .

[krikan]

Habe den Patch mal kurz getestet, da meine Zeit am Wochenende begrenzt sein wird.
Grundsätzlich läuft es ohne direkt erkennbare Probleme. 

Bei Abfrage WakeupIntervall, wird der "wakeupNoMoreInformation" mehrmals verschickt (vgl. anliegendes Log), da ja auf WAKE_UP-Klasse geparst wird. Negative Auswirkungen auf die Abarbeitung der Befehle kann ich aber interessanterweise nicht erkennen. Hätte erwartet, dass nach Versand "wakeupNoMoreInformation" die nachfolgenden Befehle ins Leere laufen (NCK). Dem ist aber selbst bei vielen gleichzeitigen Abfragen wie im anliegenden Log bei mir nicht so. Ob "wakeupNoMoreInformation" überhaupt zum Sensor-"Schlaf" führt, habe ich noch nicht kontrolliert.

Gibt es eigentlich eine Zeitbegrenzung, ab der keine Befehle mehr verschickt werden, oder wird (vermute ich) bei Deiner Änderung einfach immer der vollständige Sendstack verschickt?

[hanske]

Hallo,

bei mir läuft es auch gut. Der ganze Stack wird nun regelmäßig und zuverlässig versendet.

Die beiden TODOs sind tatsächlich noch das Selektieren zwischen "wakeup notification" und "wakeup intervall" Rückmeldung.
Letztere kommt allerdings auch nur wenn man danach fragt.
Das andere TODO wäre die Abfrage, ob die Befehle auch angekommen sind, da hattest Du ja schon mal was zu geschrieben.
Das scheint aber ein grundsätzliches Problem zu sein. Ich habe einen Schalter, der manchmal nicht erreichbar ist und FHEM schickt ihm brav Befehle die nicht ankommen ohne dazu einen Fehler zu loggen.
Zeitbegrenzung ist nicht implementiert, normalerweise bleiben die Geräte ein paar Sekunden wach und sollten in dieser Zeit auch schon einige Befehle entgegen nehmen können. Sind ja immer nur ein paar Bytes. Du selbst hattest ja schon 20 Befehle in einem Rutsch absetzen können.

Vielleicht kann der Herr König (um nicht schon wieder "der arme Rudi" schreiben zu müssen ) meinen PATCH ja mal einarbeiten.
Kann gerne auch noch verschönert werden z.B. mit "while" und "shift".
Ich lass das mal hier so weiterlaufen und schau immer mal in die Logs.

schönen Abend noch...

[krikan]

Mich irritiert gerade folgender Beitrag:
http://forum.fhem.de/index.php/topic,20884.msg144227.html#msg144227
Demnach gibt es wohl noch mehr Geräte, die nicht nur bei "wakeup notification" Befehle verarbeiten. Schafft man bie diesen Geräten Probleme mit dem Patch?
Wobei der sichere Weg wohl nur Versand bei "wakeup notification" in Kombination mit Kontrolle der Rückmeldung des Gerätes ist.

Ich habe einen Schalter, der manchmal nicht erreichbar ist und FHEM schickt ihm brav Befehle die nicht ankommen ohne dazu einen Fehler zu loggen.

Gar keine Rückmeldung? Noch nicht einmal mt verbose 5? Zumindest ein NO_ACK oder ähnliches solltest Du haben. Oder ist für Dich das Log im Fehlerfall nicht deutlich genug?

Ich hatte eben mal angefangen umzusetzen, dass nur auf eine "wakeup notification" die gesammelten Befehle verschickt werden. Mein Gedanke ist, dies durch einfügen einer zusätzlichen Bedingung für das"wakeup notification"-Telegramm in Zeile 1020 zu lösen:
if($arg =~ m/028407/ && $wu && @{$wu}) 
Habe ich aber noch nicht zu Ende gedacht/probiert.

Rudi wird schon mitlesen und passend eingreifen, ruhig an.