Bei Befehlen an Endpoints über CC Multichannel, erhalte ich immer den Log-Eintrag "ZWAVE: NO_ACK from <device> after 5s for sentackget:xyz", obwohl alles ordnungsgemäß abläuft.
Beispiel-Log
2016.06.12 20:06:45.436 2: ZWave get ZWave_SWITCH_BINARY_62.01 swbStatus
2016.06.12 20:06:45.437 5: ZWDongle_Write 00133e06600d01012502252b (e345c452)
2016.06.12 20:06:45.437 5: SW: 010d00133e06600d01012502252b9d
2016.06.12 20:06:45.440 5: ACK received, WaitForAck=>2 for 010d00133e06600d01012502252b9d
2016.06.12 20:06:45.441 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.06.12 20:06:45.441 5: SW: 06
2016.06.12 20:06:45.442 5: ZWDongle_0 dispatch 011301
2016.06.12 20:06:45.508 4: ZWDongle_Read ZWDongle_0: rcvd 00132b00 (request ZW_SEND_DATA), sending ACK
2016.06.12 20:06:45.509 5: SW: 06
2016.06.12 20:06:45.510 5: device ack reveived, removing 010d00133e06600d01012502252b9d from dongle sendstack
2016.06.12 20:06:45.510 5: ZWDongle_0 dispatch 00132b00
2016.06.12 20:06:45.510 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:2b
2016.06.12 20:06:45.511 4: ZWDongle_0 transmit OK for CB 2b, target ZWave_SWITCH_BINARY_62
2016.06.12 20:06:45.585 4: ZWDongle_Read ZWDongle_0: rcvd 0004003e07600d01012503ff (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.06.12 20:06:45.585 5: SW: 06
2016.06.12 20:06:45.586 5: ZWDongle_0 dispatch 0004003e07600d01012503ff
2016.06.12 20:06:45.587 4: CMD:APPLICATION_COMMAND_HANDLER ID:3e ARG:07600d01012503ff CB:00
2016.06.12 20:06:50.437 2: ZWave: No ACK from ZWave_SWITCH_BINARY_62 after 5s for sentackget:133e06600d01012502252b
Mir fehlt noch viel Zwave-KnowHow, aber ich stelle diese Meldungen bei mir auch fest. Bei mir sind das aber normale Fibaro/Greenwave-Zwischenstecker. Und es könnte evtl. auch ein Sendeproblem sein. Nach nem Update der Neighbour-Liste habe ich Ruhe. :-)
Zitat von: FunkOdyssey am 12 Juni 2016, 21:59:51
Mir fehlt noch viel Zwave-KnowHow, aber ich stelle diese Meldungen bei mir auch fest. Bei mir sind das aber normale Fibaro/Greenwave-Zwischenstecker. Und es könnte evtl. auch ein Sendeproblem sein. Nach nem Update der Neighbour-Liste habe ich Ruhe. :-)
Du hattest demnach wirkliche Kommunikationsprobleme im ZWave-Netz.
Mein Problem ist mMn nur falsches Logging in einem Spezialfall, nämlich get-Abfragen mit CC MULTI_CHANNEL, und sollte Info für Rudi sein. Sorry, dass ich es nicht dazugeschrieben habe.
Hall Christian!
Habe dieses verhalten auch bei einem FIBARO System FGS222 Double Relay Switch 2x1.5kW beobachten können:
Bei den "Subdevices" ZWave_SWITCH_BINARY_27.01 und ZWave_SWITCH_BINARY_27.02 bekomme ich nach Absetzen des Get ZWave_SWITCH_BINARY_27.01 swbStatus Befehls (andere Get Befehle hat das "Subdevice" nicht) zwar die Statusmeldung, aber zusätzlich die Fehlermeldung:
ZWave: No ACK from ZWave_SWITCH_BINARY_27 after 5s for sentackget:131b06600d0101250225ac
Die FM bezieht sich aber auf das "Hauptdevice" (auch bei deinem Logaustzug)!
die Set-befehle funktionieren ohne FM!
LG
Rainer
Hoffentlich habe ich es gefixt, leider ohne Test, da mein einziger Multi-Endpoint anderweitig verwendet wird: bitte testen und berichten.
Habe auch bei Security was geaendert, bin unsicher, ob es da auch sinnvoll war.
Problem ist hier leider nicht weg. Version von 10_ZWave.pm habe ich diverse Male kontrolliert und ist "11656 2016-06-13 16:53:36Z"
SECURITY habe ich nicht probiert.
2016.06.13 19:37:16.241 2: ZWave get ZWave_SWITCH_BINARY_62.01 basicStatus
2016.06.13 19:37:16.242 5: ZWDongle_Write 00133e06600d010120022501 (e345c452)
2016.06.13 19:37:16.242 5: SW: 010d00133e06600d010120022501b2
2016.06.13 19:37:16.246 5: ACK received, WaitForAck=>2 for 010d00133e06600d010120022501b2
2016.06.13 19:37:16.248 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.06.13 19:37:16.248 5: SW: 06
2016.06.13 19:37:16.250 5: ZWDongle_0 dispatch 011301
2016.06.13 19:37:16.323 4: ZWDongle_Read ZWDongle_0: rcvd 00130100 (request ZW_SEND_DATA), sending ACK
2016.06.13 19:37:16.323 5: SW: 06
2016.06.13 19:37:16.324 5: device ack reveived, removing 010d00133e06600d010120022501b2 from dongle sendstack
2016.06.13 19:37:16.325 5: ZWDongle_0 dispatch 00130100
2016.06.13 19:37:16.325 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:01
2016.06.13 19:37:16.325 4: ZWDongle_0 transmit OK for CB 01, target ZWave_SWITCH_BINARY_62
2016.06.13 19:37:16.401 4: ZWDongle_Read ZWDongle_0: rcvd 0004003e07600d01012003ff (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.06.13 19:37:16.401 5: SW: 06
2016.06.13 19:37:16.402 5: ZWDongle_0 dispatch 0004003e07600d01012003ff
2016.06.13 19:37:16.403 4: CMD:APPLICATION_COMMAND_HANDLER ID:3e ARG:07600d01012003ff CB:00
2016.06.13 19:37:21.243 2: ZWave: No ACK from ZWave_SWITCH_BINARY_62 after 5s for sentackget:133e06600d010120022501
Komisch, nach meiner Simulation muesste es tun.
Kannst du es bitte mit dem angehaengten Version testen, und das Log hier anhaengen?
Log:
2016.06.13 20:14:34.244 2: ZWave get ZWave_SWITCH_BINARY_62.01 basicStatus
2016.06.13 20:14:34.244 1: aTSS: ZWave_SWITCH_BINARY_62, get, 133e06600d010120022503
2016.06.13 20:14:34.244 1: pSS: ZWave_SWITCH_BINARY_62, next
2016.06.13 20:14:34.245 5: ZWDongle_Write 00133e06600d010120022503 (e345c452)
2016.06.13 20:14:34.245 5: SW: 010d00133e06600d010120022503b0
2016.06.13 20:14:34.247 5: ACK received, WaitForAck=>2 for 010d00133e06600d010120022503b0
2016.06.13 20:14:34.249 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.06.13 20:14:34.249 5: SW: 06
2016.06.13 20:14:34.250 5: ZWDongle_0 dispatch 011301
2016.06.13 20:14:34.329 4: ZWDongle_Read ZWDongle_0: rcvd 00130300 (request ZW_SEND_DATA), sending ACK
2016.06.13 20:14:34.330 5: SW: 06
2016.06.13 20:14:34.331 5: device ack reveived, removing 010d00133e06600d010120022503b0 from dongle sendstack
2016.06.13 20:14:34.331 5: ZWDongle_0 dispatch 00130300
2016.06.13 20:14:34.401 4: ZWDongle_Read ZWDongle_0: rcvd 0004003e07600d01012003ff (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.06.13 20:14:34.401 5: SW: 06
2016.06.13 20:14:34.402 5: ZWDongle_0 dispatch 0004003e07600d01012003ff
2016.06.13 20:14:39.245 2: ZWave: No ACK from ZWave_SWITCH_BINARY_62 after 5s for sentget:133e06600d010120022503
2016.06.13 20:14:39.246 1: pSS: ZWave_SWITCH_BINARY_62, next
2016.06.13 20:15:09.817 2: ZWave get ZWave_SWITCH_BINARY_62.01 swbStatus
2016.06.13 20:15:09.817 1: aTSS: ZWave_SWITCH_BINARY_62, get, 133e06600d010125022504
2016.06.13 20:15:09.817 1: pSS: ZWave_SWITCH_BINARY_62, next
2016.06.13 20:15:09.817 5: ZWDongle_Write 00133e06600d010125022504 (e345c452)
2016.06.13 20:15:09.818 5: SW: 010d00133e06600d010125022504b2
2016.06.13 20:15:09.820 5: ACK received, WaitForAck=>2 for 010d00133e06600d010125022504b2
2016.06.13 20:15:09.821 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.06.13 20:15:09.822 5: SW: 06
2016.06.13 20:15:09.823 5: ZWDongle_0 dispatch 011301
2016.06.13 20:15:09.895 4: ZWDongle_Read ZWDongle_0: rcvd 00130400 (request ZW_SEND_DATA), sending ACK
2016.06.13 20:15:09.896 5: SW: 06
2016.06.13 20:15:09.897 5: device ack reveived, removing 010d00133e06600d010125022504b2 from dongle sendstack
2016.06.13 20:15:09.897 5: ZWDongle_0 dispatch 00130400
2016.06.13 20:15:09.970 4: ZWDongle_Read ZWDongle_0: rcvd 0004003e07600d01012503ff (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.06.13 20:15:09.971 5: SW: 06
2016.06.13 20:15:09.972 5: ZWDongle_0 dispatch 0004003e07600d01012503ff
2016.06.13 20:15:15.408 2: ZWave: No ACK from ZWave_SWITCH_BINARY_62 after 5s for sentget:133e06600d010125022504
2016.06.13 20:15:15.408 1: pSS: ZWave_SWITCH_BINARY_62, next
Falls Du mehr brauchst, bitte melden.
Habe jetzt auch bei Geräten ohne Endpoint die NO_ACK (keine Ahnung, ob das an der Testversion liegt):
2016.06.13 21:35:26.475 2: ZWave get ZWave_SWITCH_MULTILEVEL_26 position
2016.06.13 21:35:26.476 1: aTSS: ZWave_SWITCH_MULTILEVEL_26, get, 131a0891010f26020200002508
2016.06.13 21:35:26.476 1: pSS: ZWave_SWITCH_MULTILEVEL_26, next
2016.06.13 21:35:26.476 5: ZWDongle_Write 00131a0891010f26020200002508 (e345c452)
2016.06.13 21:35:26.477 5: SW: 010f00131a0891010f2602020000250865
2016.06.13 21:35:26.480 2: ZWave get ZWave_SWITCH_MULTILEVEL_27 position
2016.06.13 21:35:26.481 1: aTSS: ZWave_SWITCH_MULTILEVEL_27, get, 131b0891010f26020200002509
2016.06.13 21:35:26.481 1: pSS: ZWave_SWITCH_MULTILEVEL_27, next
2016.06.13 21:35:26.481 5: ZWDongle_Write 00131b0891010f26020200002509 (e345c452)
2016.06.13 21:35:26.483 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 position
2016.06.13 21:35:26.484 1: aTSS: ZWave_SWITCH_MULTILEVEL_4, get, 13040891010f2602020000250a
2016.06.13 21:35:26.484 1: pSS: ZWave_SWITCH_MULTILEVEL_4, next
2016.06.13 21:35:26.484 5: ZWDongle_Write 0013040891010f2602020000250a (e345c452)
2016.06.13 21:35:26.486 5: ACK received, WaitForAck=>2 for 010f00131a0891010f2602020000250865
2016.06.13 21:35:26.487 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.06.13 21:35:26.487 5: SW: 06
2016.06.13 21:35:26.488 5: ZWDongle_0 dispatch 011301
2016.06.13 21:35:26.525 4: ZWDongle_Read ZWDongle_0: rcvd 00130800 (request ZW_SEND_DATA), sending ACK
2016.06.13 21:35:26.525 5: SW: 06
2016.06.13 21:35:26.527 5: device ack reveived, removing 010f00131a0891010f2602020000250865 from dongle sendstack
2016.06.13 21:35:26.527 5: ZWDongle_0 dispatch 00130800
2016.06.13 21:35:26.527 5: SW: 010f00131b0891010f2602020000250965
2016.06.13 21:35:26.529 5: ACK received, WaitForAck=>2 for 010f00131b0891010f2602020000250965
2016.06.13 21:35:26.531 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.06.13 21:35:26.532 5: SW: 06
2016.06.13 21:35:26.533 5: ZWDongle_0 dispatch 011301
2016.06.13 21:35:26.577 4: ZWDongle_Read ZWDongle_0: rcvd 00130900 (request ZW_SEND_DATA), sending ACK
2016.06.13 21:35:26.577 5: SW: 06
2016.06.13 21:35:26.578 5: device ack reveived, removing 010f00131b0891010f2602020000250965 from dongle sendstack
2016.06.13 21:35:26.578 5: ZWDongle_0 dispatch 00130900
2016.06.13 21:35:26.579 5: SW: 010f0013040891010f2602020000250a79
2016.06.13 21:35:26.581 5: ACK received, WaitForAck=>2 for 010f0013040891010f2602020000250a79
2016.06.13 21:35:26.582 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.06.13 21:35:26.582 5: SW: 06
2016.06.13 21:35:26.583 5: ZWDongle_0 dispatch 011301
2016.06.13 21:35:26.880 4: ZWDongle_Read ZWDongle_0: rcvd 00130a00 (request ZW_SEND_DATA), sending ACK
2016.06.13 21:35:26.880 5: SW: 06
2016.06.13 21:35:26.881 5: device ack reveived, removing 010f0013040891010f2602020000250a79 from dongle sendstack
2016.06.13 21:35:26.881 5: ZWDongle_0 dispatch 00130a00
2016.06.13 21:35:26.929 4: ZWDongle_Read ZWDongle_0: rcvd 000400040891010f2603030000 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.06.13 21:35:26.929 5: SW: 06
2016.06.13 21:35:26.930 5: ZWDongle_0 dispatch 000400040891010f2603030000
2016.06.13 21:35:31.477 2: ZWave: No ACK from ZWave_SWITCH_MULTILEVEL_26 after 5s for sentget:131a0891010f26020200002508
2016.06.13 21:35:31.477 1: pSS: ZWave_SWITCH_MULTILEVEL_26, next
2016.06.13 21:35:31.477 2: ZWave: No ACK from ZWave_SWITCH_MULTILEVEL_27 after 5s for sentget:131b0891010f26020200002509
2016.06.13 21:35:31.477 1: pSS: ZWave_SWITCH_MULTILEVEL_27, next
2016.06.13 21:35:31.478 2: ZWave: No ACK from ZWave_SWITCH_MULTILEVEL_4 after 5s for sentget:13040891010f2602020000250a
2016.06.13 21:35:31.478 1: pSS: ZWave_SWITCH_MULTILEVEL_4, next
ZitatHabe jetzt auch bei Geräten ohne Endpoint die NO_ACK (keine Ahnung, ob das an der Testversion liegt):
Eher nicht, bei mir funktioniert es, und die Testversion hat nur 2 zusaetzliche Zeilen an Debugausgabe.
Was mich total wurmt: nach "ZWDongle_0 dispatch 00130a00" muesste "CMD:ZW_SEND_DATA ID:00 ARG: CB:0a" kommen, jedenfalls bei gesetzten ZWDongle_0 verbose 4+. Habe z.Zt. keine Idee, wieso das bei dir nicht kommt, da muss was grundsaetzlich faul sein.
Mein Log schaut so aus:
2016.06.13 21:38:40.633 2: ZWave get an158 swbStatus
2016.06.13 21:38:40.633 1: aTSS: an158, get, 134d0225022501
2016.06.13 21:38:40.633 1: pSS: an158, next
2016.06.13 21:38:40.633 5: ZWDongle_Write 00134d0225022501 (00123456)
2016.06.13 21:38:40.633 5: SW: 010900134d0225022501a9
2016.06.13 21:38:40.634 5: ACK received, WaitForAck=>2 for 010900134d0225022501a9
2016.06.13 21:38:40.640 4: ZWDongle_Read zwd: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.06.13 21:38:40.640 5: SW: 06
2016.06.13 21:38:40.641 5: zwd dispatch 011301
2016.06.13 21:38:40.657 4: ZWDongle_Read zwd: rcvd 001301000002 (request ZW_SEND_DATA), sending ACK
2016.06.13 21:38:40.657 5: SW: 06
2016.06.13 21:38:40.658 5: device ack reveived, removing 010900134d0225022501a9 from dongle sendstack
2016.06.13 21:38:40.658 5: zwd dispatch 001301000002
2016.06.13 21:38:40.659 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:01
2016.06.13 21:38:40.659 4: zwd transmit OK for CB 01, target an158
2016.06.13 21:38:40.659 1: pSS: an158, ack
2016.06.13 21:38:40.668 4: ZWDongle_Read zwd: rcvd 0004004d032503ff (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.06.13 21:38:40.668 5: SW: 06
2016.06.13 21:38:40.669 5: zwd dispatch 0004004d032503ff
2016.06.13 21:38:40.669 4: CMD:APPLICATION_COMMAND_HANDLER ID:4d ARG:032503ff CB:00
2016.06.13 21:38:40.670 1: pSS: an158, msg
Dann sollte noch jemand anderes testen. Habe jetzt auf die Schnelle mal Rechner neu geboot, Stick an- und ausgestöpselt. Keine Änderung.
Einzige mir bekannte Besonderheit des Controllers: Hat einen 4er Chipsatz. Aber ich bin sowieso in der Vorbereitung für Controllerwechsel...
Der Haken: das Problem (bzw. was mir gerade in deinem Log Kopfschmerzen verursacht) kann nicht vom Controller abhaengen.
In deinem Log steht schon "ZWDongle_0 dispatch 00130800", d.h. 00_ZWDongle.pm hat vom Controller 00130800 bekommen, CRC verifiziert, und diese Daten per Dispatch verteilt. Dispatch sollte es an ZWave_Parse schicken, und da muesste die Meldung mit CMD:... generiert werden (bei ZWDongle_0 verbose 4+, was bei dir offensichtlich der Fall ist), das kommt aber nicht.
Und ich sehe nicht, was diese Meldung verhindern kann.
Wenn ZWave_Parse nicht aufgerufen wird/zu frueh sich verabschiedet, dann ist der Rest klar.
Ok. Kann ich irgendwie mit Tests helfen, die Kopfschmerzen zu beseitigen?
Kann das mit Perl-Versionen, Betriebssystem oder ähnlichem zusammenhängen? Das war jetzt ein Raspi mit Raspian Jessie und Perl 5.20.
Einzige Besonderheit, die mir mit der Testversion im Nachhinein noch aufgefallen ist: PopUp mit Abfrageergebnis bzw. Timeout kam nicht.
Streu mal am Anfang von ZWave_Parse() ein paar
Log 1, "Line:". __LINE__;
Zeilen ein (bis die CMD: Ausgabe), und sag mir, wo es klemmt.
Tja,
das CMD: .. bekomme ich jetzt immer.
Das Ausgangsproblem ist weiterhin vorhanden.
Nach einiger Laufzeit geht aber das Chaos los:
- Nach SW fehlt ACK und noch mal SW. Antworten kommen dann mehrfach oder
- Antworten kommen einfach so mehrfach
- Antwort kommt vor 0013
Mein letztes Highlight war das Log mit "Schluckauf" (NO ACK diesmal nicht vorhanden!):
2016.06.14 19:41:17.675 2: ZWave get ZWave_SWITCH_BINARY_62.01 swbStatus
2016.06.14 19:41:17.676 1: aTSS: ZWave_SWITCH_BINARY_62, get, 133e06600d01012502251d / L:1
2016.06.14 19:41:17.676 1: pSS: ZWave_SWITCH_BINARY_62, next get:133e06600d01012502251d
2016.06.14 19:41:17.676 5: ZWDongle_Write 00133e06600d01012502251d (e345c452)
2016.06.14 19:41:17.676 5: SW: 010d00133e06600d01012502251dab
2016.06.14 19:41:17.679 5: ACK received, WaitForAck=>2 for 010d00133e06600d01012502251dab
2016.06.14 19:41:17.680 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.06.14 19:41:17.681 5: SW: 06
2016.06.14 19:41:17.682 5: ZWDongle_0 dispatch 011301
2016.06.14 19:41:17.682 1: Line:3715
2016.06.14 19:41:17.683 1: Line:3726
2016.06.14 19:41:17.683 1: Line:3728
2016.06.14 19:41:17.683 1: Line:3730
2016.06.14 19:41:17.683 1: Line:3748
2016.06.14 19:41:18.590 4: ZWDongle_Read ZWDongle_0: rcvd 0004003e07600d01012503ff (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.06.14 19:41:18.591 5: SW: 06
2016.06.14 19:41:18.592 5: ZWDongle_0 dispatch 0004003e07600d01012503ff
2016.06.14 19:41:18.592 1: Line:3715
2016.06.14 19:41:18.593 1: Line:3816
2016.06.14 19:41:18.593 1: Line:3818
2016.06.14 19:41:18.593 1: Line:3837
2016.06.14 19:41:18.593 1: Line:3839
2016.06.14 19:41:18.593 1: Line:3844
2016.06.14 19:41:18.593 4: CMD:APPLICATION_COMMAND_HANDLER ID:3e ARG:07600d01012503ff CB:00
2016.06.14 19:41:18.594 1: pSS: ZWave_SWITCH_BINARY_62, msg sentget:133e06600d01012502251d
2016.06.14 19:41:19.430 4: ZWDongle_Read ZWDongle_0: rcvd 00131d00 (request ZW_SEND_DATA), sending ACK
2016.06.14 19:41:19.431 5: SW: 06
2016.06.14 19:41:19.433 5: device ack reveived, removing 010d00133e06600d01012502251dab from dongle sendstack
2016.06.14 19:41:19.433 5: ZWDongle_0 dispatch 00131d00
2016.06.14 19:41:19.434 1: Line:3715
2016.06.14 19:41:19.434 1: Line:3816
2016.06.14 19:41:19.434 1: Line:3818
2016.06.14 19:41:19.435 1: Line:3837
2016.06.14 19:41:19.435 1: Line:3839
2016.06.14 19:41:19.435 1: Line:3844
2016.06.14 19:41:19.435 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:1d
2016.06.14 19:41:19.436 4: ZWDongle_0 transmit OK for CB 1d, target ZWave_SWITCH_BINARY_62
2016.06.14 19:41:19.506 4: ZWDongle_Read ZWDongle_0: rcvd 0004003e07600d01012503ff (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.06.14 19:41:19.506 5: SW: 06
2016.06.14 19:41:19.508 5: ZWDongle_0 dispatch 0004003e07600d01012503ff
2016.06.14 19:41:19.509 1: Line:3715
2016.06.14 19:41:19.509 1: Line:3816
2016.06.14 19:41:19.509 1: Line:3818
2016.06.14 19:41:19.509 1: Line:3837
2016.06.14 19:41:19.510 1: Line:3839
2016.06.14 19:41:19.510 1: Line:3844
2016.06.14 19:41:19.510 4: CMD:APPLICATION_COMMAND_HANDLER ID:3e ARG:07600d01012503ff CB:00
2016.06.14 19:41:19.721 4: ZWDongle_Read ZWDongle_0: rcvd 0004003e07600d01012503ff (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.06.14 19:41:19.721 5: SW: 06
2016.06.14 19:41:19.723 5: ZWDongle_0 dispatch 0004003e07600d01012503ff
2016.06.14 19:41:19.724 1: Line:3715
2016.06.14 19:41:19.724 1: Line:3816
2016.06.14 19:41:19.724 1: Line:3818
2016.06.14 19:41:19.725 1: Line:3837
2016.06.14 19:41:19.725 1: Line:3839
2016.06.14 19:41:19.725 1: Line:3844
2016.06.14 19:41:19.725 4: CMD:APPLICATION_COMMAND_HANDLER ID:3e ARG:07600d01012503ff CB:00
2016.06.14 19:41:20.714 4: ZWDongle_Read ZWDongle_0: rcvd 0004003e07600d01012503ff (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.06.14 19:41:20.714 5: SW: 06
2016.06.14 19:41:20.715 5: ZWDongle_0 dispatch 0004003e07600d01012503ff
2016.06.14 19:41:20.716 1: Line:3715
2016.06.14 19:41:20.716 1: Line:3816
2016.06.14 19:41:20.716 1: Line:3818
2016.06.14 19:41:20.716 1: Line:3837
2016.06.14 19:41:20.716 1: Line:3839
2016.06.14 19:41:20.716 1: Line:3844
2016.06.14 19:41:20.716 4: CMD:APPLICATION_COMMAND_HANDLER ID:3e ARG:07600d01012503ff CB:00
2016.06.14 19:41:20.746 4: ZWDongle_Read ZWDongle_0: rcvd 0004003e07600d01012503ff (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.06.14 19:41:20.746 5: SW: 06
2016.06.14 19:41:20.748 5: ZWDongle_0 dispatch 0004003e07600d01012503ff
2016.06.14 19:41:20.748 1: Line:3715
2016.06.14 19:41:20.748 1: Line:3816
2016.06.14 19:41:20.748 1: Line:3818
2016.06.14 19:41:20.748 1: Line:3837
2016.06.14 19:41:20.748 1: Line:3839
2016.06.14 19:41:20.749 1: Line:3844
2016.06.14 19:41:20.749 4: CMD:APPLICATION_COMMAND_HANDLER ID:3e ARG:07600d01012503ff CB:00
2016.06.14 19:41:21.715 4: ZWDongle_Read ZWDongle_0: rcvd 0004003e07600d01012503ff (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.06.14 19:41:21.715 5: SW: 06
2016.06.14 19:41:21.716 5: ZWDongle_0 dispatch 0004003e07600d01012503ff
2016.06.14 19:41:21.717 1: Line:3715
2016.06.14 19:41:21.717 1: Line:3816
2016.06.14 19:41:21.717 1: Line:3818
2016.06.14 19:41:21.717 1: Line:3837
2016.06.14 19:41:21.717 1: Line:3839
2016.06.14 19:41:21.717 1: Line:3844
2016.06.14 19:41:21.717 4: CMD:APPLICATION_COMMAND_HANDLER ID:3e ARG:07600d01012503ff CB:00
2016.06.14 19:41:21.746 4: ZWDongle_Read ZWDongle_0: rcvd 0004003e07600d01012503ff (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.06.14 19:41:21.747 5: SW: 06
2016.06.14 19:41:21.748 5: ZWDongle_0 dispatch 0004003e07600d01012503ff
2016.06.14 19:41:21.748 1: Line:3715
2016.06.14 19:41:21.748 1: Line:3816
2016.06.14 19:41:21.749 1: Line:3818
2016.06.14 19:41:21.749 1: Line:3837
2016.06.14 19:41:21.749 1: Line:3839
2016.06.14 19:41:21.749 1: Line:3844
2016.06.14 19:41:21.749 4: CMD:APPLICATION_COMMAND_HANDLER ID:3e ARG:07600d01012503ff CB:00
2016.06.14 19:41:22.714 4: ZWDongle_Read ZWDongle_0: rcvd 0004003e07600d01012503ff (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.06.14 19:41:22.718 5: SW: 06
2016.06.14 19:41:22.719 5: ZWDongle_0 dispatch 0004003e07600d01012503ff
2016.06.14 19:41:22.719 1: Line:3715
2016.06.14 19:41:22.719 1: Line:3816
2016.06.14 19:41:22.720 1: Line:3818
2016.06.14 19:41:22.720 1: Line:3837
2016.06.14 19:41:22.720 1: Line:3839
2016.06.14 19:41:22.720 1: Line:3844
2016.06.14 19:41:22.720 4: CMD:APPLICATION_COMMAND_HANDLER ID:3e ARG:07600d01012503ff CB:00
2016.06.14 19:41:23.715 4: ZWDongle_Read ZWDongle_0: rcvd 0004003e07600d01012503ff (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.06.14 19:41:23.715 5: SW: 06
2016.06.14 19:41:23.716 5: ZWDongle_0 dispatch 0004003e07600d01012503ff
2016.06.14 19:41:23.716 1: Line:3715
2016.06.14 19:41:23.717 1: Line:3816
2016.06.14 19:41:23.717 1: Line:3818
2016.06.14 19:41:23.717 1: Line:3837
2016.06.14 19:41:23.717 1: Line:3839
2016.06.14 19:41:23.717 1: Line:3844
2016.06.14 19:41:23.717 4: CMD:APPLICATION_COMMAND_HANDLER ID:3e ARG:07600d01012503ff CB:00
2016.06.14 19:41:24.714 4: ZWDongle_Read ZWDongle_0: rcvd 0004003e07600d01012503ff (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.06.14 19:41:24.715 5: SW: 06
2016.06.14 19:41:24.717 5: ZWDongle_0 dispatch 0004003e07600d01012503ff
2016.06.14 19:41:24.717 1: Line:3715
2016.06.14 19:41:24.718 1: Line:3816
2016.06.14 19:41:24.718 1: Line:3818
2016.06.14 19:41:24.718 1: Line:3837
2016.06.14 19:41:24.718 1: Line:3839
2016.06.14 19:41:24.719 1: Line:3844
2016.06.14 19:41:24.719 4: CMD:APPLICATION_COMMAND_HANDLER ID:3e ARG:07600d01012503ff CB:00
Ich werde mal das System und den Stick wechseln.
- "Das Ausgangsproblem ist weiterhin vorhanden"... "NO ACK diesmal nicht vorhanden!" Was nu: gibts das Anfangsproblem mit No ACK oder nicht. Ich sehe es jedenfalls nicht.
- "Antworten kommen einfach so mehrfach" Was nu: einfach oder mehrfach :)
Ich tippe darauf, dass der Controller das 06 nicht bekommt, und deswegen die Daten immer wieder schickt. 10-mal. Ziemlich geduldig, der Bursche. Stellt sich aber die Frage, wieso der Controller den Get sauber kriegt, und auch die ACKs auf 011301 bzw. 00131d00, aber nicht fuer die Antwort. Und wieso die Antwort vor dem 0013 kommt.
Hmmm. Totally lost :)
Zitat von: rudolfkoenig am 14 Juni 2016, 22:08:09
- "Das Ausgangsproblem ist weiterhin vorhanden"... "NO ACK diesmal nicht vorhanden!" Was nu: gibts das Anfangsproblem mit No ACK oder nicht. Ich sehe es jedenfalls nicht.
Anfangsproblem noch vorhanden; nur einmalig (im geposteten Log) nicht.
Zitat
"Antworten kommen einfach so mehrfach" Was nu: einfach oder mehrfach
Mehrfache Antwort auf ein durch FHEM verschicktes Telegramm :P
ZitatIch tippe darauf, dass der Controller das 06 nicht bekommt, und deswegen die Daten immer wieder schickt. 10-mal. Ziemlich geduldig, der Bursche. Stellt sich aber die Frage, wieso der Controller den Get sauber kriegt, und auch die ACKs auf 011301 bzw. 00131d00, aber nicht fuer die Antwort. Und wieso die Antwort vor dem 0013 kommt.
Ich schrieb ja: Chaos. Kann Dir auch andere Varianten mit unerklärlichen Wiederholungen von 0113 und 0013 liefern. In grauer Vorzeit hattest Du dem Controller schon mal Merkwürdigkeiten attestiert. Meine 0013 fehlte eine Zeit lang.
Und Du solltest Dir keine Kopfschmerzen wegen meines Sonderproblems machen und es vergessen. :)
Mich würde aber doch mal interessieren, ob das Thread-Ausgangsproblem bei anderen weg ist.
Hi,
Zitat von: krikan am 14 Juni 2016, 22:21:51
Mich würde aber doch mal interessieren, ob das Thread-Ausgangsproblem bei anderen weg ist.
ich habe leider kein Multichannel Device, kann daher auch nicht testen.
Ich kann mich jetzt leider nicht mehr so genau an die Details erinnern, aber ich hatte auch mal SEHR merkwürdige Effekte als ich einige CAN durch das ConfigAll bekommen hatte (im Zuge der Einführung der Sendestacks). Da waren mit einem Mal auch etliche Nachrichten verschwunden, dafür tauchten andere unerklärlich oft auf, und das obwohl die ACKs eigentlich alle "passend" waren. Ich habe das dann allerdings nicht mehr reproduzieren können um es weiter zu untersuchen. Ist von alleine gekommen und ist auch wieder von alleine verschwunden... ;-)
Mit was für einem Dongle arbeitest Du eigentlich auf dem Testsystem?
Gruß,
Andreas.
Ist ein Vision Z-Wave USB Stick ZU 1401 EU mit SDK 6.02 und 4er Chipsatz. Wesentlichen Funktionen von ZWave-Plus (100k, EF, usw) sind schon drin. War mein 1. Controller als ZWave-Plus noch kein Thema war.
Das Merkwürdige ist: Im Normalbetrieb ist alles unauffällig. Wenn ich "Stresstests" mache, funktioniert es meistens. Ab und an und ohne für mich erkennbare Logik passt irgendetwas nicht und das auch teilweise nach Neustarts. Im Fazit nichts, was uns wirklich weiterbringt :( .
Hab grad "update" laufen lassen und nach einem FHEM Neustart ein "get ZWave_SWITCH_BINARY_27.01 swbStatus" ausgeführt:
2016.06.15 18:19:21 2: ZWave get ZWave_SWITCH_BINARY_27.01 swbStatus
2016.06.15 18:19:21 2: ZWave get ZWave_SWITCH_BINARY_27.01 swbStatus
2016.06.15 18:19:26 2: ZWave: No ACK from ZWave_SWITCH_BINARY_27 after 5s for sentackget:131b06600d010125022505
...
LG
Rainer
PS.: Controller ist ZME_UZB1
Die NO_ACK bei Multichannel-Devices kommt bei meinen Tests mit meinen beiden anderen Controllern und auf anderem System immer noch und regelmäßig. Wenn ich Dir irgendwie bei der Analyse mit Logs helfen kann, lass es mich wissen. Habe selbst schon erfolglos gesucht.
Bezüglich der Schmerzmedikamente-fördernden Logs:
Habe den Vision 4er auf meinen Vision Zwave+-Controller repliziert und anschließend auch auf einen UZB1.
Dann habe ich versucht jeweils die gleichen Stresstests mit Win und Debian bei jedem Controller durchzuführen: Beim 4er Vision kommen immer wieder in unregelmäßigen Abständen merkwürdige Logs. Bei den ZWavePlus Controllern gibt es auch schon einmal Auffälligkeiten, aber nicht so häufig. Darum mein Vermutung, dass es evtl. doch mit dem Controller zusammenhängt, auch wenn Deine für mich nachvollziehbare Vermutung in eine andere Richtung geht. Werde zukünftig für Tests nur noch die Plus-Controller einsetzen, da der 4er Chipsatz sowieso eine Seltenheit darstellt.
Hi,
ich habe den UZB1 mit Firmware 5.6 am Pi3 im Einsatz. Als Device dient ein FIBARO FGS-222. Am Endpoint 1 habe ich einen EG_Terrasse_LampeWS (reales Device) konfiguriert, am Endpoint 2 einen EG_Terrasse_SteckdoseWS (Endpoint Device). Wenn ich "get EG_Terrasse_SteckdoseWS swbStatus" (über WEB UI) ausführe, bekomme ich folgendes Log:
2016.06.18 17:23:21.229 2: ZWave get EG_Terrasse_SteckdoseWS swbStatus
2016.06.18 17:23:21.283 2: ZWave set EG_Terrasse_Steckdose off
2016.06.18 17:23:26.234 2: ZWave: No ACK from EG_Terrasse_LampeWS after 5s for sentackget:130f06600d01022502250b
Listing vom Device:
Internals:
DEF dad62400 15
IODev ZWDongle_0
LASTInputDev ZWDongle_0
MSGCNT 24
NAME EG_Terrasse_LampeWS
NR 57
STATE aus
TYPE ZWave
ZWDongle_0_MSGCNT 24
ZWDongle_0_RAWMSG 0004000f057006100101
ZWDongle_0_TIME 2016-06-18 17:32:54
homeId dad62400
isWakeUp
lastMsgSent 1466263989.26927
nodeIdHex 0f
timeToAck 0.028
Readings:
2016-06-18 17:32:44 assocGroup_1 Max 5 Nodes ZWDongle_0
2016-06-18 17:32:44 assocGroup_2 Max 5 Nodes
2016-06-18 17:32:44 assocGroup_3 Max 1 Nodes ZWDongle_0
2016-06-18 17:32:44 assocGroups 3
2016-06-18 17:32:54 configALARMFLASHINGAlarmTime 600
2016-06-18 17:32:54 configAutoOffForRelay1 0
2016-06-18 17:32:54 configAutoOffForRelay2 0
2016-06-18 17:32:54 configAutoOffRelayAfterSpecifiedTime ManualOverrideDisabled
2016-06-18 17:32:54 configDimmerRollerShutterControl DisableDimmerRollerShutter0
2016-06-18 17:32:54 configEnableDisableALLONOFF ALLONActiveALLOFFActive
2016-06-18 17:32:54 configInputsBehaviour Toggle
2016-06-18 17:32:54 configInputsButtonSwitchConfiguration MonoStableInputButton
2016-06-18 17:32:54 configManagingTheTransmissionOfControl6 TheControlCommandsAreSentWhenThe0
2016-06-18 17:32:54 configManagingTheTransmissionOfControl7 TheControlCommandsAreSentWhenThe0
2016-06-18 17:32:54 configRelay1ResponseToGeneralAlarm ALARMFLASHINGRelayWillTurnONAndO3
2016-06-18 17:32:54 configRelay1ResponseToSmokeCOCO2Alarm ALARMFLASHINGRelayWillTurnONAndO3
2016-06-18 17:32:54 configRelay1ResponseToTemperatureAlarm ALARMRELAYONRelayWillTurnONUpon1
2016-06-18 17:32:54 configRelay1ResponseToWaterFloodAlarm ALARMRELAYOFFRelayWillTurnOFF2
2016-06-18 17:32:54 configRelay2ResponseToGeneralAlarm ALARMFLASHINGRelayWillTurnONAndO3
2016-06-18 17:32:54 configRelay2ResponseToSmokeCOCO2Alarm ALARMFLASHINGRelayWillTurnONAndO3
2016-06-18 17:32:54 configRelay2ResponseToTemperatureAlarm ALARMRELAYONRelayWillTurnONUpon1
2016-06-18 17:32:54 configRelay2ResponseToWaterFloodAlarm ALARMRELAYOFFRelayWillTurnOFF2
2016-06-18 17:32:54 configSavingStateBeforePowerFailure StateSavedAtPowerFailureAll1
2016-05-25 08:02:49 mcCapability_01 SWITCH_BINARY
2016-05-25 08:02:49 mcCapability_02 SWITCH_BINARY
2016-05-25 08:02:49 mcEndpoints total 2, identical
2016-05-25 08:02:49 model FIBARO System FGS222 Double Relay Switch 2x1.5kW
2016-05-25 08:02:49 modelConfig fibaro/fgs222.xml
2016-05-25 08:02:49 modelId 010f-0202-1002
2016-06-18 17:21:28 reportedState off
2016-06-18 17:21:28 state off
2016-06-18 17:33:09 transmit OK
Attributes:
IODev ZWDongle_0
classes MANUFACTURER_SPECIFIC VERSION CONFIGURATION ASSOCIATION MULTI_CHANNEL_ASSOCIATION MULTI_CHANNEL SWITCH_BINARY SWITCH_ALL FIRMWARE_UPDATE_MD POWERLEVEL MARK SWITCH_BINARY MULTI_CHANNEL
eventMap on:an off:aus
group Wandsender
room Terrasse,ZWave
vclasses ASSOCIATION:2 CONFIGURATION:1 FIRMWARE_UPDATE_MD:1 MANUFACTURER_SPECIFIC:1 MULTI_CHANNEL:2 MULTI_CHANNEL_ASSOCIATION:1 POWERLEVEL:1 SWITCH_ALL:1 SWITCH_BINARY:1 VERSION:1
Komischerweise wird ein "set EG_Terrasse_Steckdose off" gemeldet, ich verstehe nicht, warum? Ist es mein Fehler?
Danke schon mal im Voraus!
Habe es auf meinem verbauten fgs221 nachgestellt und das Problem gefixt. Duerfte seit ca 3 Monaten vorhanden sein. Es geht darum, dass beim get die gesendete Klasse mit der Empfangenen verglichen wird, leider einmal mit Multi-Channel Encapsulation, einmal ohne.
Hallo Rudolf,
sieht gut aus, der Fehler kommt nicht mehr:
2016.06.19 12:50:29.378 2: ZWave get EG_Terrasse_SteckdoseWS swbStatus
2016.06.19 12:50:29.378 5: ZWDongle_Write 00130f06600d010225022505 (dad62400)
2016.06.19 12:50:29.379 5: SW: 010d00130f06600d01022502250581
2016.06.19 12:50:29.381 5: ACK received, WaitForAck=>2 for 010d00130f06600d01022502250581
2016.06.19 12:50:29.387 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.06.19 12:50:29.387 5: SW: 06
2016.06.19 12:50:29.388 5: ZWDongle_0 dispatch 011301
2016.06.19 12:50:29.405 4: ZWDongle_Read ZWDongle_0: rcvd 001305000002 (request ZW_SEND_DATA), sending ACK
2016.06.19 12:50:29.405 5: SW: 06
2016.06.19 12:50:29.406 5: device ack reveived, removing 010d00130f06600d01022502250581 from dongle sendstack
2016.06.19 12:50:29.406 5: ZWDongle_0 dispatch 001305000002
2016.06.19 12:50:29.406 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:05
2016.06.19 12:50:29.407 4: ZWDongle_0 transmit OK for CB 05, target EG_Terrasse_LampeWS
2016.06.19 12:50:29.416 4: ZWDongle_Read ZWDongle_0: rcvd 0004000f07600d0201250300 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.06.19 12:50:29.416 5: SW: 06
2016.06.19 12:50:29.418 5: ZWDongle_0 dispatch 0004000f07600d0201250300
2016.06.19 12:50:29.418 4: CMD:APPLICATION_COMMAND_HANDLER ID:0f ARG:07600d0201250300 CB:00
2016.06.19 12:50:29.424 2: ZWave set EG_Terrasse_Steckdose off
2016.06.19 12:50:29.425 5: ZWDongle_Write 00130e07600d01022501002506 (dad62400)
2016.06.19 12:50:29.425 5: SW: 010e00130e07600d0102250100250682
2016.06.19 12:50:29.433 5: ACK received, WaitForAck=>2 for 010e00130e07600d0102250100250682
2016.06.19 12:50:29.434 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.06.19 12:50:29.434 5: SW: 06
2016.06.19 12:50:29.435 5: ZWDongle_0 dispatch 011301
2016.06.19 12:50:29.452 4: ZWDongle_Read ZWDongle_0: rcvd 001306000003 (request ZW_SEND_DATA), sending ACK
2016.06.19 12:50:29.452 5: SW: 06
2016.06.19 12:50:29.453 5: device ack reveived, removing 010e00130e07600d0102250100250682 from dongle sendstack
2016.06.19 12:50:29.453 5: ZWDongle_0 dispatch 001306000003
2016.06.19 12:50:29.454 4: CMD:ZW_SEND_DATA ID:00 ARG:0003 CB:06
2016.06.19 12:50:29.454 4: ZWDongle_0 transmit OK for CB 06, target EG_Terrasse_Lampe
Danke!
Zitatsieht gut aus, der Fehler kommt nicht mehr:
kann ich bestätigen!
Danke!
Rainer
Hallo!
Bein Switch ist's behoben, aber beim Dimmer (FIBARO System FGD212 Dimmer 2) scheint es noch zu bestehen:
2016.06.24 14:53:55.879 2: ZWave get ZWave_ZWAVEPLUS_INFO_20.01 swmStatus
2016.06.24 14:53:55.879 5: ZWDongle_Write 00131406600d0101260225c3 (cb838b79)
2016.06.24 14:53:55.880 5: SW: 010d00131406600d0101260225c35c
2016.06.24 14:53:55.883 5: ACK received, WaitForAck=>2 for 010d00131406600d0101260225c35c
2016.06.24 14:53:55.889 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.06.24 14:53:55.889 5: SW: 06
2016.06.24 14:53:55.891 5: ZWDongle_0 dispatch 011301
2016.06.24 14:53:55.905 4: ZWDongle_Read ZWDongle_0: rcvd 0013c3000002 (request ZW_SEND_DATA), sending ACK
2016.06.24 14:53:55.905 5: SW: 06
2016.06.24 14:53:55.907 5: device ack reveived, removing 010d00131406600d0101260225c35c from dongle sendstack
2016.06.24 14:53:55.907 5: ZWDongle_0 dispatch 0013c3000002
2016.06.24 14:53:55.907 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:c3
2016.06.24 14:53:55.908 4: ZWDongle_0 transmit OK for CB c3, target ZWave_SWITCH_MULTILEVEL_20
2016.06.24 14:53:55.918 4: ZWDongle_Read ZWDongle_0: rcvd 0004001407600d010126034d (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.06.24 14:53:55.918 5: SW: 06
2016.06.24 14:53:55.920 5: ZWDongle_0 dispatch 0004001407600d010126034d
2016.06.24 14:53:55.920 4: CMD:APPLICATION_COMMAND_HANDLER ID:14 ARG:07600d010126034d CB:00
2016.06.24 14:54:00.881 2: ZWave: No ACK from ZWave_SWITCH_MULTILEVEL_20 after 5s for sentackget:131406600d0101260225c3
...nur zur Info, hat keine Priorität...
(die Sub-Devices mit den "komischen" Namen hat FHEM automatisch angelegt:
ZWave_SWITCH_MULTILEVEL_20, ZWave_ZWAVEPLUS_INFO_20.01 und ZWave_ZWAVEPLUS_INFO_20.02)
Da ich so'n Geraet nicht habe: kannst du bitte:
- in FHEM/10_ZWave.pm, Funktion ZWave_processSendStack die Log Zeile mit pSS aktivieren (# entfernen)
- in der Funktion ZWave_addToSendStack die Log Zeile mit aTSS aktivieren
- FHEM neu starten
- Problem reproduzieren
- Ausgabe hier anhaengen
Hallo Rudolf!
Danke für Deine Antwort!
Hab' leider erst jetzt Zeit gefunden, Deiner Anleitung zu folgen.
Hier ist der Log-Auszug:
2016.07.05 12:36:28.522 3: ZWave get ZWave_ZWAVEPLUS_INFO_20.01 swmStatus
2016.07.05 12:36:28.523 1: aTSS: ZWave_SWITCH_MULTILEVEL_20, get, 131406600d010126022501 / L:1
2016.07.05 12:36:28.523 1: pSS: ZWave_SWITCH_MULTILEVEL_20, next get:131406600d010126022501
2016.07.05 12:36:28.565 1: pSS: ZWave_SWITCH_MULTILEVEL_20, ack sentget:131406600d010126022501
2016.07.05 12:36:28.569 1: pSS: ZWave_SWITCH_MULTILEVEL_20, msg sentackget:131406600d010126022501
2016.07.05 12:36:33.525 2: ZWave: No ACK from ZWave_SWITCH_MULTILEVEL_20 after 5s for sentackget:131406600d010126022501
2016.07.05 12:36:33.525 1: pSS: ZWave_SWITCH_MULTILEVEL_20, next sentackget:131406600d010126022501
LG
Rainer
Sorry, reicht leider nicht. Bitte die pSS Zeile durch die Folgende ersetzen, und nochmal probieren:
Log 1, "pSS: $hash->{NAME}, $ackType $ss->[0]".($omsg ? " omsg:$omsg" : "");
kein Problem!
Hier das neue Log:
2016.07.06 10:47:59.767 3: ZWave get ZWave_ZWAVEPLUS_INFO_20.01 swmStatus
2016.07.06 10:47:59.768 1: aTSS: ZWave_SWITCH_MULTILEVEL_20, get, 131406600d010126022501 / L:1
2016.07.06 10:47:59.768 1: pSS: ZWave_SWITCH_MULTILEVEL_20, next get:131406600d010126022501
2016.07.06 10:47:59.768 5: ZWDongle_Write 00131406600d010126022501 (cb838b79)
2016.07.06 10:47:59.769 5: SW: 010d00131406600d0101260225019e
2016.07.06 10:47:59.772 5: ACK received, WaitForAck=>2 for 010d00131406600d0101260225019e
2016.07.06 10:47:59.778 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.07.06 10:47:59.779 5: SW: 06
2016.07.06 10:47:59.780 5: ZWDongle_0 dispatch 011301
2016.07.06 10:47:59.808 4: ZWDongle_Read ZWDongle_0: rcvd 001301000002 (request ZW_SEND_DATA), sending ACK
2016.07.06 10:47:59.808 5: SW: 06
2016.07.06 10:47:59.810 5: device ack reveived, removing 010d00131406600d0101260225019e from dongle sendstack
2016.07.06 10:47:59.811 5: ZWDongle_0 dispatch 001301000002
2016.07.06 10:47:59.812 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:01
2016.07.06 10:47:59.812 4: ZWDongle_0 transmit OK for CB 01, target ZWave_SWITCH_MULTILEVEL_20
2016.07.06 10:47:59.813 1: pSS: ZWave_SWITCH_MULTILEVEL_20, ack sentget:131406600d010126022501 omsg:01
2016.07.06 10:47:59.814 4: ZWDongle_Read ZWDongle_0: rcvd 0004001407600d010126034d (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.07.06 10:47:59.815 5: SW: 06
2016.07.06 10:47:59.816 5: ZWDongle_0 dispatch 0004001407600d010126034d
2016.07.06 10:47:59.817 4: CMD:APPLICATION_COMMAND_HANDLER ID:14 ARG:07600d010126034d CB:00
2016.07.06 10:47:59.819 1: pSS: ZWave_SWITCH_MULTILEVEL_20, msg sentackget:131406600d010126022501 omsg:0326034d
2016.07.06 10:48:04.770 2: ZWave: No ACK from ZWave_SWITCH_MULTILEVEL_20 after 5s for sentackget:131406600d010126022501
2016.07.06 10:48:04.770 1: pSS: ZWave_SWITCH_MULTILEVEL_20, next sentackget:131406600d010126022501
2016.07.06 10:48:22.460 4: ZWDongle_Read ZWDongle_0: rcvd 0004001306310504220000 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.07.06 10:48:22.460 5: SW: 06
2016.07.06 10:48:22.462 5: ZWDongle_0 dispatch 0004001306310504220000
2016.07.06 10:48:22.462 4: CMD:APPLICATION_COMMAND_HANDLER ID:13 ARG:06310504220000 CB:00
Danke, habs gefixt und eingecheckt, ab morgen per update.
Multichannel get hat bisher nur fuer swbStatus funktioniert, da ich das Explorer-Frame-Byte (25) mit der Klasse (25 fuer SWITCH_BINARY) verwechselt habe. swbStatus funktioniert bei mir immer noch :)
Ja, getzt gibt's beim Dimmer auch keine Fehlermeldung mehr.
Danke!!!
:-)