Vision ZD2102 scheint nicht mehr richtig zu funktionieren

[Baerli34]

Moinsen,

die 0.1 sec könnten tatsächlich ein wenig Probleme verursachen bei mir laut ersten Tests - ich werde das aber nochmals genauer verifizieren nach meinem Urlaub und mich ggfs dazu melden. Noch für alle die ein Vision inkludieren wollen ein kleiner Tipp für das abfragen der Werte (was ich bisher auch noch nciht wusste) - wenn der Deckel offen ist, dann nehmt "WAKE_UP" kurzfristig aus den classes, denn das Device ist solange "immer" ready  Danach natürlich wieder einnehmen, wenn ihr ihn installiert - das hatte es mir dann auch noch etwas einfacher gemacht mit dem basicSet bekommen. Dazu dann einfach den Magneten ranhalten im geöffneten Zustand und basicReport abfragen....vielleicht hilft es ja noch jemanden....so long...

vg, Jörg

[rudolfkoenig]

Wg. der 0.1 Sekunden: das soll sicherstellen, dass alle notifies, die ein set/get Befehl loswerden wollen, vor dem wakeupNoMoreInformation dran sind. Koennte genausogut auch 0.0001 sein, da die "InternalTimer" Funktionen erst dann aufgerufen werden, wenn alle notifies durch sind. Danach sind alle Befehle in der Warteschlage, und werden der Reihe nach abgearbeitet.

Wg. basicSet/basicReport: koennte das bitte jemand sauber zusammenfassen, ich bin etwas verwirrt.

[krikan]

Wg. der 0.1 Sekunden: das soll sicherstellen, dass alle notifies, die ein set/get Befehl loswerden wollen, vor dem wakeupNoMoreInformation dran sind. Koennte genausogut auch 0.0001 sein, da die "InternalTimer" Funktionen erst dann aufgerufen werden, wenn alle notifies durch sind. Danach sind alle Befehle in der Warteschlage, und werden der Reihe nach abgearbeitet.

Meine Bedenken: Telegramme haben ZWave-Netz unterschiedliche Laufzeiten. Gerade bei größeren Installationen könnte es vorkommen, dass das später abgeschickte wakeupNoMoreInformation allein aufgrund einer kürzeren Telegrammlaufzeit im Netz (bspw. optimalere Route) schneller am Gerät ankommt als ein früher abgeschickter set-/get-Befehl. Der set-/get-Befehl also ins Leere läuft. Zudem verhindert ggfs. ein zu schnelles wakeupNoMoreInformation direkte Kommunikationen zwischen Endgeräten: Fhem schickt WakeUp-Gerät in den Ruhezustand und lässt direkte assozierten Endgeräten keine Chance die Funknachrichten auszutauschen. Darum meine Gedanken an größere  Werte als 0.1 Sek. Oder mißverstehe ich etwas?

[rudolfkoenig]

Prinzipiell hast du Recht.
Was mir unklar ist: schickt der Dongle die zweite Nachricht raus, bevor die erste bestaetigt wurde?
Ich habe kein Problem die Zeit zu erhoehen, am liebsten waere mir aber, fundierten Daten oder tatsaechliche Probleme zu haben.

[krikan]

Was mir unklar ist: schickt der Dongle die zweite Nachricht raus, bevor die erste bestaetigt wurde?

Mir nicht definitiv bekannt. Gehe aber vom Versand der nächsten Nachricht aus, nachdem ZW_SENDDATA ordnungsgemäßes Verschicken mit 011301 bestätigt hat. Denn alles was danach am Controller eintrifft kann über die -bei Fhem noch nicht eindeutige- CallbackID identifziert und einer bestimmten ZW_SENDDATA-Nachricht zugeordnet werden.

Sollte meine Annahme falsch sein: Wenn der Controller wegen Ausbleibens der Antwort des Gerätes auf ZW_SENDDATA in timeout geht, wird doch definitiv die nächste Nachricht verschickt. Danach könnte auch noch die vorherige Antwort eintreffen. Dann hätten wir schon ein Problem. Ja, könnte, hätte. Darum wären mir auch fundierte Daten lieber, TE hat diese ja angekündigt.

Aber selbst, wenn wir kein Problem mit versandten Controller-Messages haben, verhindert Fhem ggfs. die Kommunikation zwischen den direkt assoziierten Endgeräten. Nach Wakeup schickt Fhem ununterbrochen Nachrichten und schickt dann sofort in den Schlaf. Telegrammlaufzeiten (zwischen direkt assozierten Geräten) von über 0.1 Sek halte ich nun nicht für ausgeschlossen oder äußerst ungewöhnlich.

Was sind die neagtiven Effekte bei einer Erhöhung des Wertes von 0.1, außer es nie genau herauszufinden?

[rudolfkoenig]

Habe mich ergeben, und es auf 1 Sekunde geaendert.

[Baerli34]

Moinsen,

nochmal kurze Verständnisfrage, da ich immer noch Probleme mit so ziemlich allen Batteriebetrieben Geräten habe.
Setze ich eine Abfrage (z.b. batterie für den Vision - 13180280022518) in den sendstack wird er wohl auch abgearbeitet:

2015.08.20 10:23:42 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 00040418028407
2015.08.20 10:23:42 5: SW: 06
2015.08.20 10:23:42 5: ZWDongle_1 dispatch 00040418028407
2015.08.20 10:23:42 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:18 ARG:028407
2015.08.20 10:23:42 5: ZWDongle_Write 00 13180280022518
2015.08.20 10:23:42 5: SW: 0109001318028002251840
2015.08.20 10:23:42 4: Sending stored command: 13180280022518
2015.08.20 10:23:42 4: Sending wakeupNoMoreInformation to node: 18
2015.08.20 10:23:42 5: ZWDongle_Write 00 131802840805
2015.08.20 10:23:42 5: Triggering WZ_Tuer3 (1 changes)
2015.08.20 10:23:42 5: Notify loop for WZ_Tuer3 wakeup: notification
2015.08.20 10:23:42 5: Tueren: not on any display, ignoring notify
2015.08.20 10:23:42 5: ACK received, removing 0109001318028002251840 from sendstack
2015.08.20 10:23:42 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 011301
2015.08.20 10:23:42 5: SW: 06
2015.08.20 10:23:42 5: ZWDongle_1 dispatch 011301
2015.08.20 10:23:42 5: SW: 01080013180284080577
2015.08.20 10:23:42 5: ACK received, removing 01080013180284080577 from sendstack
2015.08.20 10:23:42 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 011301
2015.08.20 10:23:42 5: SW: 06
2015.08.20 10:23:42 5: ZWDongle_1 dispatch 011301
2015.08.20 10:23:42 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 00131800
2015.08.20 10:23:42 5: SW: 06
2015.08.20 10:23:42 5: ZWDongle_1 dispatch 00131800
2015.08.20 10:23:42 4: ZWDongle_1 CMD:ZW_SEND_DATA ID:00 ARG:
2015.08.20 10:23:42 4: ZWDongle_1 transmit OK for 18
2015.08.20 10:23:42 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 00131800
2015.08.20 10:23:42 5: SW: 06
2015.08.20 10:23:42 5: ZWDongle_1 dispatch 00131800
2015.08.20 10:23:42 4: ZWDongle_1 CMD:ZW_SEND_DATA ID:00 ARG:
2015.08.20 10:23:42 4: ZWDongle_1 transmit OK for 18

...bekomme aber danach kein Battery Reading angezeigt ;( Jemand ne Idee?
...sehe ich sofort ne wakeupnomoreinformation - dachte da die kommt später?

Und nochmal kurz für dich Rudi - nach dem inkludieren der Visions ist kein basicset im reading und wird daher auch nicht angezeigt. Dies kriege ich nur nach dem gefühlt 100x set basicValue hin....dann wird es irgendwann angezeigt und für mich nicht nachvollziehbar wann.
"Nach dem Datenblatt (also theoretisch ) sendet der Vision ZD2102 per CC BASIC an den Controller. Nach den aktuellen Änderungen an den 10_ZWave.pm sollte das Öffnen/Schließen durch Event/Reading "basicSet" mit 00/ff signalisiert  werden"

lg, Jörg

[rudolfkoenig]

Kannst du das bitte mit den Aenderungen von gestern (wakeupNoMoreInformation nach 1.0 sek statt 0.1 sek) nochmal pruefen? Falls es immer noch nicht geht, dann bitte die Zeilen mit 02840805 im 10_ZWave.pm auskommentieren, und nochmal testen. Wenn du solche Zeitkritische logs hier anhaengst, dann bitte vorher "attr global mseclog" aktivieren. Wenn das alles nicht hilft, dann bin ich ratlos.
Genauso wie beim basicSet vs. basicReport: meine Fernbedienung hat sich auch irgendwannmal umgestellt, weiss aber nicht wieso.

[Baerli34]

Hi,

ok mit auskommentieren geht es wunderbar und habe sofort ein battery reading nach dem wakeup. Der WakeUpNoMoreLog-Eintrag sagt aber nichts von 1sec Verzögerung oder hab ich es falsch verstanden?

Version # $Id: 10_ZWave.pm 9094 2015-08-19 05:20:22Z rudolfkoenig $

2015.08.20 14:50:20 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 00040410028407
2015.08.20 14:50:20 5: SW: 06
2015.08.20 14:50:20 5: ZWDongle_1 dispatch 00040410028407
2015.08.20 14:50:20 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:10 ARG:028407
2015.08.20 14:50:20 5: ZWDongle_Write 00 13100280022510
2015.08.20 14:50:20 5: SW: 0109001310028002251040
2015.08.20 14:50:20 4: Sending stored command: 13100280022510
2015.08.20 14:50:20 4: Sending wakeupNoMoreInformation to node: 10
2015.08.20 14:50:20 5: Triggering WZ_Tuer2 (1 changes)
2015.08.20 14:50:20 5: Notify loop for WZ_Tuer2 wakeup: notification
2015.08.20 14:50:20 5: Tueren: not on any display, ignoring notify
2015.08.20 14:50:20 5: ACK received, removing 0109001310028002251040 from sendstack
2015.08.20 14:50:20 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 011301
2015.08.20 14:50:20 5: SW: 06
2015.08.20 14:50:20 5: ZWDongle_1 dispatch 011301
2015.08.20 14:50:20 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 00131000
2015.08.20 14:50:20 5: SW: 06
2015.08.20 14:50:20 5: ZWDongle_1 dispatch 00131000
2015.08.20 14:50:20 4: ZWDongle_1 CMD:ZW_SEND_DATA ID:00 ARG:
2015.08.20 14:50:20 4: ZWDongle_1 transmit OK for 10
2015.08.20 14:50:20 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 0004001003800364
2015.08.20 14:50:20 5: SW: 06
2015.08.20 14:50:20 5: ZWDongle_1 dispatch 0004001003800364
2015.08.20 14:50:20 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:10 ARG:03800364
2015.08.20 14:50:20 5: Triggering WZ_Tuer2 (1 changes)
2015.08.20 14:50:20 5: Notify loop for WZ_Tuer2 battery: 100 %
2015.08.20 14:50:20 5: Tueren: not on any display, ignoring notify

lg, Jörg

[rudolfkoenig]

Der WakeUpNoMoreLog-Eintrag sagt aber nichts von 1sec Verzögerung oder hab ich es falsch verstanden?

Da steht was von InternalTimer(gettimeofday()+1, jedenfalls in der aktuellen Version.
1. Kannst du bitte pruefen, ob du mit dieser Version (+1 statt +0.1) zurechtkommst.
2. Wenn nicht, reicht es diese eine Zeile zu loeschen, oder hast du beide auskommentiert?

[Baerli34]

Moinsen,

ich hab nur den IOWrite auskommentiert für den NoMoreInfo und es funktioniert. Die Verzögerung befindet
sich doch aber im "else" Zweig für die notifys?? Im Moment sieht es für mich eher nach einer nötigen Verzögerung
nach dem abarbeiten der strored Commands aus oder was meint ihr?

lg, Jörg

[rudolfkoenig]

Bitte die Version von heute nochmal testen, ich habe diese Stelle im Modul umgebaut, siehe mein Kommentar hier.

[Baerli34]

DONE - erst mal danke für deine rasante Entwicklungsgeschwindigkeit - respekt 
Scheint bei mir nun für einfachen Sendstack zu gehen, sobald mehrere in der queue sind wohl nicht - aber bisher nur 2x getestet -werde weiter verifizieren.

PS. Der NoMoreInfo - Log im Logfile wäre denke ich wieder nice?

Code Auswählen Erweitern


2015.08.21 09:11:17 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 00040410028407
2015.08.21 09:11:17 5: SW: 06
2015.08.21 09:11:17 5: ZWDongle_1 dispatch 00040410028407
2015.08.21 09:11:17 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:10 ARG:028407
2015.08.21 09:11:17 5: ZWDongle_Write 00 13100280022510
2015.08.21 09:11:17 5: SW: 0109001310028002251040
2015.08.21 09:11:17 4: Sending stored command: 13100280022510
2015.08.21 09:11:17 5: ZWDongle_Write 00 13100284052510
2015.08.21 09:11:17 4: Sending stored command: 13100284052510
2015.08.21 09:11:17 5: Triggering WZ_Tuer2 (1 changes)
2015.08.21 09:11:17 5: Notify loop for WZ_Tuer2 wakeup: notification
2015.08.21 09:11:17 5: Tueren: not on any display, ignoring notify
2015.08.21 09:11:17 5: ACK received, removing 0109001310028002251040 from sendstack
2015.08.21 09:11:17 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 011301
2015.08.21 09:11:17 5: SW: 06
2015.08.21 09:11:17 5: ZWDongle_1 dispatch 011301
2015.08.21 09:11:17 5: SW: 0109001310028405251043
2015.08.21 09:11:17 5: ACK received, removing 0109001310028405251043 from sendstack
2015.08.21 09:11:17 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 011301
2015.08.21 09:11:17 5: SW: 06
2015.08.21 09:11:17 5: ZWDongle_1 dispatch 011301
2015.08.21 09:11:17 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 00131000
2015.08.21 09:11:17 5: SW: 06
2015.08.21 09:11:17 5: ZWDongle_1 dispatch 00131000
2015.08.21 09:11:17 4: ZWDongle_1 CMD:ZW_SEND_DATA ID:00 ARG:
2015.08.21 09:11:17 4: ZWDongle_1 transmit OK for 10
2015.08.21 09:11:17 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 00040010068406000e10ff
2015.08.21 09:11:17 5: SW: 06
2015.08.21 09:11:17 5: ZWDongle_1 dispatch 00040010068406000e10ff
2015.08.21 09:11:17 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:10 ARG:068406000e10ff
2015.08.21 09:11:17 5: Triggering WZ_Tuer2 (1 changes)
2015.08.21 09:11:17 5: Notify loop for WZ_Tuer2 wakeupReport: interval 3600 target 255
2015.08.21 09:11:17 5: Tueren: not on any display, ignoring notify
2015.08.21 09:11:17 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 00131000
2015.08.21 09:11:17 5: SW: 06
2015.08.21 09:11:17 5: ZWDongle_1 dispatch 00131000
2015.08.21 09:11:17 4: ZWDongle_1 CMD:ZW_SEND_DATA ID:00 ARG:
2015.08.21 09:11:17 4: ZWDongle_1 transmit OK for 10
2015.08.21 09:11:17 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 00040010068406000e10ff
2015.08.21 09:11:17 5: SW: 06
2015.08.21 09:11:17 5: ZWDongle_1 dispatch 00040010068406000e10ff
2015.08.21 09:11:17 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:10 ARG:068406000e10ff
2015.08.21 09:11:17 5: Triggering WZ_Tuer2 (1 changes)
2015.08.21 09:11:17 5: Notify loop for WZ_Tuer2 wakeupReport: interval 3600 target 255
2015.08.21 09:11:17 5: Tueren: not on any display, ignoring notify
2015.08.21 09:11:18 5: ZWDongle_Write 00 131002840805
2015.08.21 09:11:18 5: SW: 0108001310028408057f
2015.08.21 09:11:18 5: ACK received, removing 0108001310028408057f from sendstack
2015.08.21 09:11:18 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 011301
2015.08.21 09:11:18 5: SW: 06
2015.08.21 09:11:18 5: ZWDongle_1 dispatch 011301
2015.08.21 09:11:18 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 00131000
2015.08.21 09:11:18 5: SW: 06
2015.08.21 09:11:18 5: ZWDongle_1 dispatch 00131000
2015.08.21 09:11:18 4: ZWDongle_1 CMD:ZW_SEND_DATA ID:00 ARG:
2015.08.21 09:11:18 4: ZWDongle_1 transmit OK for 10


Code Auswählen Erweitern


2015.08.21 09:30:48 5: SW: 06
2015.08.21 09:30:48 5: ZWDongle_1 dispatch 00040418028407
2015.08.21 09:30:48 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:18 ARG:028407
2015.08.21 09:30:48 5: ZWDongle_Write 00 13180280022518
2015.08.21 09:30:48 5: SW: 0109001318028002251840
2015.08.21 09:30:48 4: Sending stored command: 13180280022518
2015.08.21 09:30:48 5: Triggering WZ_Tuer3 (1 changes)
2015.08.21 09:30:48 5: Notify loop for WZ_Tuer3 wakeup: notification
2015.08.21 09:30:48 5: Tueren: not on any display, ignoring notify
2015.08.21 09:30:48 5: ACK received, removing 0109001318028002251840 from sendstack
2015.08.21 09:30:48 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 011301
2015.08.21 09:30:48 5: SW: 06
2015.08.21 09:30:48 5: ZWDongle_1 dispatch 011301
2015.08.21 09:30:48 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 00131800
2015.08.21 09:30:48 5: SW: 06
2015.08.21 09:30:48 5: ZWDongle_1 dispatch 00131800
2015.08.21 09:30:48 4: ZWDongle_1 CMD:ZW_SEND_DATA ID:00 ARG:
2015.08.21 09:30:48 4: ZWDongle_1 transmit OK for 18
2015.08.21 09:30:48 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 0004001803800364
2015.08.21 09:30:48 5: SW: 06
2015.08.21 09:30:48 5: ZWDongle_1 dispatch 0004001803800364
2015.08.21 09:30:48 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:18 ARG:03800364
2015.08.21 09:30:48 5: Triggering WZ_Tuer3 (1 changes)
2015.08.21 09:30:48 5: Notify loop for WZ_Tuer3 battery: 100 %
2015.08.21 09:30:48 5: Tueren: not on any display, ignoring notify
2015.08.21 09:30:49 5: ZWDongle_Write 00 131802840805
2015.08.21 09:30:49 5: SW: 01080013180284080577
2015.08.21 09:30:49 5: ACK received, removing 01080013180284080577 from sendstack
2015.08.21 09:30:49 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 011301
2015.08.21 09:30:49 5: SW: 06
2015.08.21 09:30:49 5: ZWDongle_1 dispatch 011301
2015.08.21 09:30:49 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 00131800
2015.08.21 09:30:49 5: SW: 06
2015.08.21 09:30:49 5: ZWDongle_1 dispatch 00131800
2015.08.21 09:30:49 4: ZWDongle_1 CMD:ZW_SEND_DATA ID:00 ARG:
2015.08.21 09:30:49 4: ZWDongle_1 transmit OK for 18

lg, Jörg

[rudolfkoenig]

Rasant ist anders, siehe SECURITY.

Was genau ist das Problem mit 2 Geraeten, bzw. was hast du gemacht, und was klappt/klappt nicht? Was genau wurde mit diesem Log protokolliert? Haengt nach einem Wakeup-Notification noch etwas in der Wakeup-Schlange? Wenn ja, was? Am besten alle Fragen beantworten, nicht nur ausgewaehlte
Bitte bei dieser Art von Logs (d.h. zeitkritisch) vorher "attr global msecloc" aktivieren, und die Logs in einem CODE-Tag einschliessen oder nur anhaengen.

[Baerli34]

Die Codes sind 2 Beispiele; eines mit nur einem get und eines mit zweien; in der warteschlange hängt nie etwas - das war auch vorher nicht das Problem - nur die readings waren ja nicht da! Die waren nach dem auskommentieren des NoMoreInfos wieder funktionabel - sowie anscheinend jetzt auch wieder - jedoch nur wenn in der Warteschlange nur ein Befehl ist. Dies werde ich aber das WE noch weiter beobachten..lg