WakeUp, Scheduled Tasks Probleme

[hanske]

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 habe nur Verbose 3 eingestellt, da kommt dann im Log "ZWave set sw_wall on" und das Icon an der Oberfläche wird auf "on" gesetzt. Weitere Meldungen werden nicht raus geschrieben. Wenn ich den Status des Schalters abfrage wird mir "off" zurückgeliefert.

Deinen Codevorschlag kann ich auf Grund meiner geringen Perl Kenntnisse nicht kommentieren.
Mir reicht der aktuelle Stand aus, es ist bis jetzt nichts mehr verloren gegangen.
Wenn er bei Dir auch eine Verbesserung bringt, kann man ihn ja erst mal einpflegen.

Grüße

[krikan]

Verbose 3 eingestellt, da kommt dann im Log "ZWave set sw_wall on" und das Icon an der Oberfläche wird auf "on" gesetzt

Könntest Du das nicht mal testhalber hochschrauben. Eigentlich müsste nach meiner Meinung soetwas in der Art auftauchen:

Code Auswählen Erweitern

2014.10.21 20:19:35 5: ZWDongle_0 dispatch 00132601
2014.10.21 20:19:35 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:01 ARG:
2014.10.21 20:19:35 2: ZWDongle_0 ERROR: SEND_DATA returned 01
Wenn nicht, sind meine Gedankengänge zur Empfangsbestätigung durch die Geräte per ACK hinfällig, was ich eigentlich nicht glauben kann.

Deinen Codevorschlag kann ich auf Grund meiner geringen Perl Kenntnisse nicht kommentieren.
Mir reicht der aktuelle Stand aus, es ist bis jetzt nichts mehr verloren gegangen.
Wenn er bei Dir auch eine Verbesserung bringt, kann man ihn ja erst mal einpflegen.

Ich selbst habe es noch nicht zu Ende gedacht/probiert; ist also unvollendet. Wollte Deine Schleife noch mal dort hineinschieben und meine Try-And-Error-Übungen fortsetzen. Mir fehlen nicht nur Perl-Kenntnisse, sondern auch der Programmiererdurchblick .

[rudolfkoenig]

@hanske: habe deine Zeilen angeschaut, hier meine Bemerkungen:
- die Stelle um Zeile 1000 analysiert eingetroffene Pakete. Bei einem mit MULTI_CMD verpackten Nachricht koennen auch mehrere sein, deswegen die Schleife.
- dein Code reagiert, falls irgendeine eine Nachricht der Klasse WAKE_UP eintrifft. Kann nicht beurteilen, ob das sinnvoll ist.
- die Abfrage if($hash) ist ueberflussig, falls kein $hash gefunden wurde, wird diese Zeile nicht erreicht (siehe Zeile 973). Stattdessen wuerde ich $hash->{WakeUp} pruefen, da dieser Hash nicht immer angelegt ist.
- dass man mehrere Befehle direkt hintereinander absenden kann, verwundert mich immer noch, aber wenn eure Tests bestaetigen, dass es klappt, dann ist es wohl so.

@krikan: du pruefst mit 028407 explizit auf WAKEUP (84) notification(07), ist mir prinzipiell sympatischer, weiss aber nicht ob es tut.

Wenn es fertig zum Einchecken ist (habe noch nicht dein Eindruck anhand der Meldungen hier), bitte Bescheid geben.

[krikan]

Habe den Code von hanske mit der von mir vorgeschlagenen Prüfung nur auf die "wakeup notification" einmal umgesetzt. Den Patch habe ich angehängt. Er enthält auch noch detaillierteres Logging bei fehlgeschlagenen Empfang der Geräterücktelegramme. Funktionsprobleme konnte ich bisher keine feststellen. Er müsste aber von anderen noch mal gegengetest und überprüft werden.

man mehrere Befehle direkt hintereinander absenden kann, verwundert mich immer noch, aber wenn eure Tests bestaetigen, dass es klappt, dann ist es wohl so.

Läuft ohne erkennbare Probleme. Selbst das Log sieht für mich im Vergleich zum Einzelversand gleich aus. Mir wäre aber ein Einzelversand mit Warten auf das Rücktelegramm lieber. Würde dann gerne das Rücktelegramm auf ACK und NACK testen. Wenn kein ACK, dann sollte der fehlgeschlagene Befehl im sendstack verbleiben und keine weiteren Befehle verschickt werden. Erst bei der nächsten "wakeup notification" sollte erneut verschickt werden. Das ganze vielleicht maximal 3 mal, bevor man es endgültig verwirft/aufgibt. (Zukunftsvision!)

[krikan]

Die Änderung des obigen Patches läuft bei mir nach diversen Tests ohne erkennbare Probleme.

Folgende Punkte verstehe ich im 10_ZWave.pm-Code nicht und lassen mich ungewünschte Seiteneffekte befürchten:
- Im sub ZWave_cmd wird hier ein "" in den Sendstack eingefügt:

Code Auswählen Erweitern

if($awake && @{$baseHash->{WakeUp}} == 0) {
push @{$baseHash->{WakeUp}}, ""; # Block the next
Im sub ZWave_parse wird dieses "" immer entfernt und der nächste Befehl gesendet. Dies ist im Patch-Code nicht berücksichtigt.
- Warum wird mal hash und mal baseHash (und auch noch wu) verwendet? Laut den zusätzlichen Logs die ich eingebaut habe, ist der Inhalt immer gleich. Im Patch wird hash verwendet.

Weitere ungelöste Probleme
Zwingend:
Prüfung darf nicht nur auf "wakeup notification" laufen, ansonsten erhalten WAKE_UP-Geräte, die zwar WAKE_UP class haben aber aufgrund der config frequentListening sind, niemals die Befehle. Beispiel:  EZMotion 3-in-1 (HSM100) kann mit set <device> configStayAwake 1 auf frequentListening umgestellt werden. Dadurch entfällt "wakeup notification" event und Befehle können immer empfangen werden. Abhilfe: Befehl nodeInfo um

Code Auswählen Erweitern

push @list, "frequentListening:" . ($r[3] & ( 0x20 | 0x40 ));
push @list, "beaming:" . ($r[3] & 0x10);
ergänzen und in der Abfrage bei frequentListening <> 0, das Gerät als "wach" behandeln. Soll man diese nodeInfo-Abfrage bei jedem Durchlauf stellen (mMn richtig) oder nur beim fhem-Start, oder... Abfrageergebnisse müssten wohl sinnvollerweise auch als Reading beim Gerät gespeichert werden.
Optimierung:
Wenn kein ACK, dann sollte der fehlgeschlagene Befehl im sendstack verbleiben und keine weiteren Befehle verschickt werden. Erst bei der nächsten "wakeup notification" sollte erneut verschickt werden. Das ganze vielleicht maximal 3 mal, bevor man es endgültig verwirft/aufgibt.

Leider bin ich mangels Programmierkünsten jetzt wieder auf Hilfe angewiesen. Sorry. Insgesamt halte ich den Patch persönlich für zu unvollständig zum Einchecken. Zumindest die frequentListenung-Thematik sollte abgedeckt werden, auch wenn es nur eine geringe Geräteanzahl betreffen sollte.

[rudolfkoenig]

- Im sub ZWave_cmd wird hier ein "" in den Sendstack eingefügt:

Theorie (evtl. falsch): man darf nur ein nicht beantwortetes Befehl an das Geraet senden, da das Dongle keine Warteschlange verwaltet. Falls der Benutzer zwei Befehle absetzt, und das Geraet wach ist, dann sendet FHEM eins direkt, den zweiten muss es aber (wg. der Theorie) blockieren. Um zu wissen, dass etwas noch nicht beantwortet ist, wird "" eingefuegt. Falls die Theorie falsch ist, dann ist das ueberfluessig, und die Schlange wird vom Dongle verwaltet. Wuesste gerne, wie lange seine Schlange sein kann.

- Warum wird mal hash und mal baseHash (und auch noch wu) verwendet?

$baseHash und $hash ist nur fuer MULTI_CHANNEL Geraete ab Kanal 2 unterschiedlich. Heisst aber nicht, dass man es ignorieren sollte.
$wu ist Abkuerzung fuer $baseHash->{WakeUp}. Erstens ist kuerzer zu schreiben/lesbarer, zweitens schneller in der Abarbeitung.
Wenn ich sowas mehr als einmal brauche, dann kuerze ich es gerne ab.

[krikan]

Schlange wird vom Dongle verwaltet. Wuesste gerne, wie lange seine Schlange sein kann.

Habe jetzt bis zu 80 Befehle in einem Rutsch übertragen und stelle in meiner Mini-Zwave-Umgebung keine Probleme fest.
Dennoch bin ich wieder auf dem Weg zu Deiner Theorie: Nur ein unbeantworteten Befehl an das Gerät senden.
Gründe:
-openzwave (ozw) macht das genauso und die beschäftigen sich schon länger damit
-in den ozw-groups wird vom mitsniffen des Zwave-Funkverkehrs einer closed Source Software berichtet, die auch so vorgeht
-entscheidend: könnten das wirklich alle Controller?  ACKs Zuordnung zu Telegrammen ist nur bei einem unbeantworteten Befehl sicher durchführbar
Mal schauen wie weit ich komme....

[hanske]

Hallo,
gibt es schon was neues?
Ist mein Patch (evtl. mit Anpassungen) eigentlich mal eingepflegt worden?
Soll ich noch etwas ändern oder testen?
Es wäre gut wenn meine Änderungen mit reinkommen, sonst kann ich nicht mehr so einfach updaten.

Grüße

[rudolfkoenig]

@hanske: kannst du bitte krikans Patch testen, wenn es funktioniert, wuerde ich es einchecken.

[krikan]

Bitte unbedingt aber meine erwähnten "weiteren ungelösten Probleme" von hier http://forum.fhem.de/index.php/topic,27984.msg212622.html#msg212622 beachten.
Der Patch ist also noch nicht optimal. Ich werde mich weiter an der Problemlösung versuchen, wenn es kein anderer übernimmt. Schaffe das aber nur langfristig. Mir fehlt monentan die Zeit.

[rudolfkoenig]

Es muessen nicht auf Anhieb alle Probleme geloest sein, aber ich haette gerne diesen Patch von mind 2 Leuten getestet.

[hanske]

Ich denke auch, dass nicht alles auf einmal gelöst werden muss.
Der Patch wird das WakeUp Verhalten aber insgesamt deutlich verbessern.

Ich wende den Patch von Krikan mal auf die aktuelle Version an und probiere übers Wochenende mal einiges aus.
Bis dann

[hanske]

Hat alles gut funktioniert. Die Stapel wurden komplett abgearbeitet und die Rückmeldungen kamen auch an.
Ich hatte allerdings ein anderes Problem in der Testzeit, welches mir vorher nicht aufgefallen war, aber mit dem Patch wohl trotzdem nichts zu tun hat:
Als ich meine Fritzbox neu startete, hatte ich im WebUi plötzlich 3 Tage alte Readings. Neue Readings und States der ZWave Geräte kamen weder im Log noch im UI an. Ich konnte die Geräte aber trotzdem über das UI steuern. Ein "shutdown restart" brachte auch nichts.
Erst nach einem Fritzbox Neustart am nächsten Tag ging wieder alles.
Hattet Ihr so was schon mal?

[hanske]

Hallo,

der Patch läuft immer noch ohne Probleme und ich würde mich freuen, wenn er mit in das Release käme.
Man sollte allerdings auch bei "ZW_APPLICATION_UPDATE" den ganzen Stapel abarbeiten.

Ich hatte gerade einen neuen Sensor eingerichtet und gleich eine ganze Menge Setting abgesetzt.
Leider hatte ich nicht als erstes das Wakeupinterval und den Empfängerknoten angegeben.

Ich habe dann manuell Wakeups ausgelöst, die aber nur als  "ZW_APPLICATION_UPDATE" ankamen.
Es wurde dann aber immer nur ein gespeicherter Befehl abgesetzt.
Ich habe dann das foreach aus dem Wakeup auch dorthin kopiert und schon lief es perfekt.

Also, es wäre schön wenn das mal in das Release kommt, dann kann ich auch wieder updaten

[krikan]

Hallo hanske,
könntest Du bitte einen Patch gegen die aktuelle svn-Version hochladen. Dann würde ich auch noch mal testen und Rudi hätte einen getesten Patch, den er einfach einbauen könnte.
Danke, Christian