Moinsen,
hatte mich seit geraumer Zeit über meine Türsensoren Vision ZD2102 gewundert, da ich aber am umbauen bin erst mal nicht dabei gedacht. Früher wurde der basicReport gesetzt, dies scheint jetzt nciht mehr der Fall zu sein. Bei einigen habe ich ein basicSet, bei einigen nicht - dieses wird allerdings korrekt mit 00 / ff gesetzt sollte es da sein. Da ich noch einen rumliegen hatte, mal schnell includiert und ich krieg es ums verrecken nicht hin ein basicReport zu bekommen ;(
2015-07-24 19:33:16 Global global UNDEFINED ZWave_SENSOR_BINARY_22 ZWave d9d0af0b 22 71858072308684
2015-07-24 19:33:16 Global global DEFINED ZWave_SENSOR_BINARY_22
2015-07-24 19:33:16 Global global DEFINED FileLog_ZWave_SENSOR_BINARY_22
2015-07-24 19:33:16 Global global SAVE
2015-07-24 19:33:19 ZWave ZWave_SENSOR_BINARY_22 associationAdd 1 01
2015-07-24 19:33:20 ZWave ZWave_SENSOR_BINARY_22 model: Vision ZD2102 AU Door/Window Sensor
2015-07-24 19:33:20 ZWave ZWave_SENSOR_BINARY_22 modelId: 0109-2001-0102
2015-07-24 19:33:20 ZWave ZWave_SENSOR_BINARY_22 modelConfig: vision/zd2102.xml
2015-07-24 19:33:29 ZWDongle ZWDongle_1 addNode off
2015-07-24 19:36:02 ZWave ZWave_SENSOR_BINARY_22 alarm: HomeSecurity: Tampering, product covering removed, arg 0000
2015-07-24 19:36:21 ZWave ZWave_SENSOR_BINARY_22 wakeup: notification
2015-07-24 19:36:22 ZWave ZWave_SENSOR_BINARY_22 alarm: HomeSecurity: Tampering, product covering removed, arg 0000
2015-07-24 19:36:22 readingsGroup battStatus ZWave_SENSOR_BINARY_22.battery: 100 %
2015-07-24 19:36:22 ZWave ZWave_SENSOR_BINARY_22 battery: 100 %
Beim basicSet:
2015.07.24 19:48:20 4: HTTP FHEMWEB:192.168.0.152:2487 GET /fhem?detail=ZWave_SENSOR_BINARY_22&dev.getZWave_SENSOR_BINARY_22=ZWave_SENSOR_BINARY_22&cmd.getZWave_SENSOR_BINARY_22=get&arg.ge
tZWave_SENSOR_BINARY_22=basicStatus&val.getZWave_SENSOR_BINARY_22=&XHR=1&addLinks=1
2015.07.24 19:48:20 5: Cmd: >get ZWave_SENSOR_BINARY_22 basicStatus<
2015.07.24 19:48:20 2: ZWave get ZWave_SENSOR_BINARY_22 basicStatus
2015.07.24 19:48:20 4: 32329:FHEMWEB:192.168.0.152:2487: /fhem?detail=ZWave_SENSOR_BINARY_22&dev.getZWave_SENSOR_BINARY_22=ZWave_SENSOR_BINARY_22&cmd.getZWave_SENSOR_BINARY_22=get&arg.getZ
Wave_SENSOR_BINARY_22=basicStatus&val.getZWave_SENSOR_BINARY_22=&XHR=1&addLinks=1 / RL:56 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
und das war es dann - jemand eine Idee wie ich den basicStatus / report bekomme? Natürlich wurde das Device mehrfach aufgeweckt etc
dankeschön schon mal,lg
Jörg
Enthält das Attribut classes BASIC? Zeige bitte mal ein "list".
Enthält es^^ Bütteschön..
Internals:
CFGFN
DEF d9d0af0b 22
IODev ZWDongle_1
LASTInputDev ZWDongle_1
MSGCNT 94
NAME ZWave_SENSOR_BINARY_22
NR 981
STATE associationAdd 1 01
TYPE ZWave
ZWDongle_1_MSGCNT 94
ZWDongle_1_RAWMSG 00040416028407
ZWDongle_1_TIME 2015-07-24 21:06:57
homeId d9d0af0b
id 16
lastMsgTimestamp 1437764817
Readings:
2015-07-24 19:52:30 CMD ZW_APPLICATION_UPDATE
2015-07-24 19:43:05 UNPARSED BATTERY 0a800364ff00ff07030000
2015-07-24 20:06:30 alarm HomeSecurity: Tampering, product covering removed, arg 0000
2015-07-24 19:43:05 battery 100 %
2015-07-24 19:33:20 model Vision ZD2102 AU Door/Window Sensor
2015-07-24 19:33:20 modelConfig vision/zd2102.xml
2015-07-24 19:33:20 modelId 0109-2001-0102
2015-07-24 19:33:19 state associationAdd 1 01
2015-07-24 21:06:57 transmit OK
2015-07-24 21:06:57 wakeup notification
WakeUp:
Attributes:
IODev ZWDongle_1
classes ALARM ASSOCIATION BATTERY MANUFACTURER_SPECIFIC SENSOR_BINARY VERSION WAKE_UP BASIC
room ZWave
Hab gerade http://forum.fhem.de/index.php?topic=39212.0 (basicSet) gesehen - was macht es und warum ist es in meinen Readings? Dachte ist ein Command? Und warum funktioniert da 00/ff wenn es denn da ist?? ::) :o
vg
Hast Du denn schon die Version vom 16.07. oder eine ältere? Meine an dem Tag war sourceforge nur noch zeitweise anwesend.
Ich erkenne die Lösung für Dein Problem nicht, nur hast Du auch -wie http://forum.fhem.de/index.php/topic,39377.0.html - eine merkwürdige UNPARSED - Message. Ich habe bei mir noch mal die Devices durchgeschaut und habe bei einem netzgespeisten Aktor am 19.07 die merkwürdig
UNPARSED BATTERY 0d80100632022144000000090000
So etwas habe ich vorher auch noch nicht gesehen. Zufall?
Hi,
ich habe jetzt ein basicValue 00 gesetzt und siehe da ich habe in den Readings ein basicSet welches korrekt mit 00/ff gefüttert wird für Door open/close. So jetzt bin ich dann ganz confused - sorry.
Wer erklärt mir die Änderung und was es damit auf sich hat? Vorher war es definitiv der wunderhübsche basicReport der bei class basic abfragbar war und dann "automatisiert" nach wakeup verfügbar war ;(
So ist das ganze eher nicht so hübsch ???
PS- Version 7/13 - also wohl nicht^^
lg
Moinsen,
kurzes Update - hatte bei einem Sensor (neu inkludiert) es partou nicht hinbekommen wieder an den basicSet zu kommen (der ja jetzt statt basicReport hier aktualisiert wird bei Tür auf/zu). Dies funktioniert komischerweise wohl nur wenn der Stick selbst auf nodeAdd steht. Da ich aber gleich nach inkludieren immer wieder ausschalte war ich da etwas am verzweifeln. Es war dann auch nicht nötig ein basicValue zu setzen - somit laufen die Dinger jetzt wieder über diesen Umweg. Aber so nen kurzes Statement oder nen Link wo ich was zu dem Untschied basicSet/Report lesen könnte wäre nice...
tx, Jörg
Zitat von: Baerli34 am 26 Juli 2015, 10:11:28
Dies funktioniert komischerweise wohl nur wenn der Stick selbst auf nodeAdd steht.
Das dürfte so nicht sein. Kannst Du das Log-mäßig untermauern.
ZitatAber so nen kurzes Statement oder nen Link wo ich was zu dem Untschied basicSet/Report lesen könnte wäre nice...
Die Behandlung der Class BASIC ist in letzter Zeit ein paar Mal verbessert worden. BASIC-Antworten sind nicht mehr automatisch im "state" http://sourceforge.net/p/fhem/code/8539/ und die Bezeichnungen der Events/Readings wurden angepasst. Zur Bezeichnung und zugehörigem Telegramm siehe Code der aktuellen 10_ZWave.pm oder eben probieren und beobachten.
So mal schnell meinen altes Dongle genommen und ne Virtu an meinem Lapi gebastelt.
So richtig habe ich es nicht nachgestellt bekommen, wann genau ich "endlich" den basicSet bekommen habe. Es kann Zufall sein, aber es war nachdem ich NodeInklusion on hatte und basicValue 1, danach 0 gesetzt hatte und eine get Abfrage gestartet hatte. versuche vorher mit set basicValue 0 und Abfrage (ohne NodeAdd on) brachten kein Resultat. Auf jeden Fall ist es für jemanden mit den "alten" Vision ZD Sensoren einen Tipp wert, denn ohne basicSet mit 00/ff ist es nicht toll abzufragen.
http://www.filedropper.com/zwave (http://www.filedropper.com/zwave) (log)
Internals:
CFGFN
DEF 0184e89f 24
IODev ZWDongle_0
LASTInputDev ZWDongle_0
MSGCNT 81
NAME ZWave_SENSOR_BINARY_24
NR 205
STATE open
TYPE ZWave
ZWDongle_0_MSGCNT 81
ZWDongle_0_RAWMSG 000400180a710507ff00ff07030000
ZWDongle_0_TIME 2015-07-26 12:45:17
homeId 0184e89f
id 18
lastMsgTimestamp 1437907517
Readings:
2015-07-26 12:30:06 CMD ZW_APPLICATION_UPDATE
2015-07-26 12:45:17 alarm HomeSecurity: Tampering, product covering removed, arg 0000
2015-07-26 12:30:05 basicReport 00
2015-07-26 12:29:40 basicSet 00
2015-07-26 12:27:33 model Vision ZD2102 AU Door/Window Sensor
2015-07-26 12:27:33 modelConfig vision/zd2102.xml
2015-07-26 12:27:33 modelId 0109-2001-0102
2015-07-26 12:28:59 reportedState open
2015-07-26 12:28:59 state open
2015-07-26 12:30:06 transmit OK
2015-07-26 12:29:33 wakeup notification
WakeUp:
Attributes:
IODev ZWDongle_0
classes ALARM ASSOCIATION BATTERY MANUFACTURER_SPECIFIC SENSOR_BINARY VERSION WAKE_UP BASIC
room ZWave
Der Link zum Log funktioniert leider nicht. Es wäre auch besser, das hier ggfs. komprimiert anzuhängen, damit auch ein Developer ein paar Tage/Wochen später noch darauf zugreifen kann. Ob ich alleine helfen kann ist nun mal fraglich.
Bin mir auch nicht sicher, ob wir nicht aneinandervorbeischreiben:
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. Das ist nicht mehr im state, sondern muss mit Attribut "stateFormat" in den state gesetzt werden. Abfragen kann man in der CC Basic mit "get <device> basicStatus", worauf das Gerät jetzt mit Event/Reading "basicReport" mit 00/ff antwortet. Das sollte derzeit auch funktionieren. Zusätzlich wird mit den aktuellen Modul-Versionen auch noch das Attribut classesum das im NIF fehlende BASIC ergänzt; musste vorher manuell gemacht werden. Darum bin ich auch mangels Log noch unsicher, ob es wirklich nicht funktioniert oder Dich die Änderungen an den Event/Reading-Namen verwirren.
Sers,
so richtig reden wir nicht aneinander vorbei 8)
Nach inkludieren ist ja mein Hauptproblem das baiscSet in den Readings fehlt!!
Wenn ich abfrage (basicStatus) kommt ja leider nur der basicReport der neuerdings ja nicht mehr aktualisiert wird!
Wenn ich nun basicValue setze (0/1) kommt irgendwann dann der ersehnte basicSet (möglicherweise auch erst wenn
der Dongle auf lernen steht). Anbei der log...
Zusammengefasst:
1) basicReport wird nicht mehr aktualisiert (kann aber abgefragt werden)
2) basicSet wird sofort automatisch mit 00/ff gefüllt wenn er denn da ist^^
3) basicSet taucht ohne weiteres nicht in den Readings auf (mehrmaliges basicValue setzen und get / bzw. Dongle lernmode)
4) Wäre der Workaround auf Alarm zu prüfen und dann ein get für den Report zu machen => Overhead
lg, Jörg
Zitat1) basicReport wird nicht mehr aktualisiert (kann aber abgefragt werden)
grds. korrekt.basicReport ist die Antwort auf eine get-Abfrage; könnte aber je nach Gerät auch automatisch kommen.
Zitat2) basicSet wird sofort automatisch mit 00/ff gefüllt wenn er denn da ist
grds. korrekt.
Zitat3) basicSet taucht ohne weiteres nicht in den Readings auf (mehrmaliges basicValue setzen und get / bzw. Dongle lernmode)
4) Wäre der Workaround auf Alarm zu prüfen und dann ein get für den Report zu machen => Overhead
Das sollte nicht so sein. Schaue mir das Log mal an und grübel noch mal.
Sieht für mich relativ normal aus; nur recht viele CANs.
Das bringt mich aber auf folgenden Überlegung:
Bitte mal testweise in 10_ZWave.pm Zeile 1603
InternalTimer(gettimeofday()+0.1, sub($) {
abändern auf einen höheren Wert bspw.
InternalTimer(gettimeofday()+1.0, sub($) {
und dann erneut testen, ob das etwas verbessert.
Hintergrund: Fhem schickt den Sensor neuerdings 0.1 Sekunden nach Wakeup wieder in den Schlaf. Vielleicht ist das zu schnell. Die anderen OpenSource-Softs warten (auf Kosten Batterielebensdauer) länger mit dem Schlafen schicken.
STOP.
Nach nochmaliger Überlegung halte ich meinen Vorschlag für Quatsch. Open/Close werden unabhängig von wakeup verschickt. Sorry.
Trotzdem auch dazu meinen Dank - dann verstehe ich warum meine Batterieabfrage für alle Devices nciht mehr funtzt ::)
Da ist nämlich ne kleine Pause drinnen^^ Gibts eigentlich ne Zusammenfassung für den jeweilgen Deploy ausserhalb Subversion?
Hab echt Probleme sowas mitzubekommen ;D
Und für das andere Problem fällt Rudolf oder sonst jemanden ja noch was ein - im Moment gehts ja wieder - wenn man auch tricks brauch bis der basicSet
da ist....
lg
Zitat von: krikan am 26 Juli 2015, 19:30:51
Hintergrund: Fhem schickt den Sensor neuerdings 0.1 Sekunden nach Wakeup wieder in den Schlaf. Vielleicht ist das zu schnell. Die anderen OpenSource-Softs warten (auf Kosten Batterielebensdauer) länger mit dem Schlafen schicken.
Das sind 0.1 Sek. nach dem letzten verschickten Befehl und keine fest eingebauten 0.1; bevor Verwirrungen auftreten.
Dennoch wenn das Hochsetzen der Zeit bei Dir etwas verbessern sollte, dann bitte Info, damit das ggfs. angepasst werden kann. Laut Deiner Fußnote hast Du recht viele ZWave-Geräte und dort könnten sich solche Sachen ggfs. schneller bemerkbar machen, als in meinem Kleinsttestsystem.
Änderungen sieht man derzeit nur im SVN und genauem aufpassen im Forum. ZWave ist gerade recht dynamisch in der Fortentwicklung. Hoffe auch, dass das auch noch ein bißchen so bleibt.
Ja, bitte auf Rudi oder andere warten... (Geduld, ist Urlaubszeit...)
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 8) 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
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.
ZitatWg. 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?
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.
Zitat von: rudolfkoenig am 10 August 2015, 11:58:11
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?
Habe mich ergeben, und es auf 1 Sekunde geaendert.
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
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.
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
ZitatDer 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?
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
Bitte die Version von heute nochmal testen, ich habe diese Stelle im Modul umgebaut, siehe mein Kommentar hier (http://forum.fhem.de/index.php/topic,39525.msg324695.html#msg324695).
DONE - erst mal danke für deine rasante Entwicklungsgeschwindigkeit - respekt 8)
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?
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
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
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.
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