TKBHome TZ66D Dual Wall Switch

Begonnen von mattwire, 07 Mai 2015, 12:11:16

Vorheriges Thema - Nächstes Thema

krikan

ZitatWeiss jemand was "MULTI_CHANNEL 03600d01" bedeutet?
Habe ich gestern auch versucht zu verstehen: Wenn 0d = Command "MultiChannelEncap", dann habe ich keine Vorstellung, was nur "01" sein soll!?

zu "state":
Mein Probelm in 10_Zwave.pm ist, dass beim Setzen von state nicht gleichzeitig ein anderes, benanntes Reading mit dem "Wert von state" angelegt wird. Dadurch wird insbesondere bei Geräten, die viele Command Classes unterstützten, der state unter Umständen mehrfach angesprochen und überschrieben. Hoffe, das ist halbwegs verständlich. Oder übersehe ich etwas?

rudolfkoenig

@Christian: ich verstehe deine Argumentation bzgl. state, ich will aber auch, dass man ohne Benutzer-Zutun sinnvolle Meldungen im Frontend-Uebersicht erscheinen. Vlt. finden wir einen Kompromiss.

micha80

Hallo zusammen,

jetzt sieht es wieder besser aus :)

gestern hatte ich noch folgendes im Log
(dabei ist mir erst gar nicht aufgefallen, dass state zunächst auf open gesetzt wird und direkt danach dann auf basicSet..)

2015-05-11_12:08:07 EG_MotionSensor open
2015-05-11_12:08:07 EG_MotionSensor reportedState: open
2015-05-11_12:08:07 EG_MotionSensor basicSet ff
2015-05-11_12:08:07 EG_MotionSensor reportedState: basicSet ff
2015-05-11_12:08:07 EG_MotionSensor UNPARSED: MULTI_CHANNEL 03600d01
....
2015-05-11_12:08:37 EG_MotionSensor closed
2015-05-11_12:08:37 EG_MotionSensor reportedState: closed
2015-05-11_12:08:37 EG_MotionSensor basicSet 00
2015-05-11_12:08:37 EG_MotionSensor reportedState: basicSet 00



Heute mit der neuesten 10_ZWave.pm svn:8552 wird als state wieder open/closed verwendet:

2015.05.11 13:19:39 5: ZWDongle/RAW: /010d000400170756
2015.05.11 13:19:39 5: ZWDongle/RAW: 010d000400170756/01300300cf3b76
2015.05.11 13:19:39 5: SW: 06
2015.05.11 13:19:39 5: ZWDongle_Read ZWDongle_0: 00040017075601300300cf3b
2015.05.11 13:19:39 5: ZWDongle_0 dispatch 00040017075601300300cf3b
2015.05.11 13:19:39 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:17 ARG:075601300300cf3b
2015.05.11 13:19:39 5: Triggering EG_MotionSensor (2 changes)
2015.05.11 13:19:39 5: Notify loop for EG_MotionSensor closed
2015-05-11_13:19:39 EG_MotionSensor closed
2015-05-11_13:19:39 EG_MotionSensor reportedState: closed
2015.05.11 13:19:39 5: ZWDongle/RAW: /0109000400170320
2015.05.11 13:19:39 5: ZWDongle/RAW: 0109000400170320/0100c7
2015.05.11 13:19:39 5: SW: 06
2015.05.11 13:19:39 5: ZWDongle_Read ZWDongle_0: 0004001703200100
2015.05.11 13:19:39 5: ZWDongle_0 dispatch 0004001703200100
2015.05.11 13:19:39 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:17 ARG:03200100
2015.05.11 13:19:39 5: Triggering EG_MotionSensor (1 changes)
2015.05.11 13:19:39 5: Notify loop for EG_MotionSensor basicSet: 00
2015-05-11_13:28:50 EG_MotionSensor basicSet: 00


und wieder das seltsame UNPARSED:

2015.05.11 13:19:39 5: ZWDongle/RAW: /0109000400170360
2015.05.11 13:19:39 5: ZWDongle/RAW: 0109000400170360/0d018a
2015.05.11 13:19:39 5: SW: 06
2015.05.11 13:19:40 5: ZWDongle_Read ZWDongle_0: 0004001703600d01
2015.05.11 13:19:40 5: ZWDongle_0 dispatch 0004001703600d01
2015.05.11 13:19:40 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:17 ARG:03600d01
2015.05.11 13:19:40 5: Triggering EG_MotionSensor (1 changes)
2015.05.11 13:19:40 5: Notify loop for EG_MotionSensor UNPARSED: MULTI_CHANNEL 03600d01


ich rate jetzt mal wild: Kann es sein, dass da 2 virtuelle Schalter angesprochen werden?
Motion: UNPARSED: MULTI_CHANNEL 03600d01
Tamper: UNPARSED: MULTI_CHANNEL 03600d02

mfg
micha

krikan

Internetsuche deutet auf "komische" Zwave-Implementierung von MultiChannelEncap bei alten Fibaro FGRM-001-Firmwares hin:
http://forum.z-wave.me/viewtopic.php?f=3422&t=20539#p51977
http://blog.hekkers.net/2014/12/08/the-fibaro-fgms-001-on-razberry-and-z-wave-the-interoperable-standard/
Wenn es behandelt werden soll, ist das wohl etwas für zwave_deviceSpecial.....

hschmitt

Zitat von: rudolfkoenig am 09 Mai 2015, 12:09:27
Christian meint wirklich stateFormat, und will damit sagen, dass jeder Benutzer damit spezifizieren muss, was als Status (STATE) angezeigt wird, das Modul liefert dazu nur Input. Bin (noch?) nicht dafuer, weil damit insb. Anfaenger zunaechst auf der Oberflaeche nichts funktionierendes haben, nicht mal ein Steckdosenschalter zeigt damit was an.
Könnte man nicht beim Anlegen eines Knotens gleich ein Standard stateformat mit anlegen. Dann hätte man doch das Beste aus beiden Vorschlägen, oder?

rudolfkoenig

Erstens: Ein Attribut hat ein (hoffentlich dokumentiertes) default Wert, und mAn sollte kein Modul fuer den Benutzer Attribute anlegen.

Zweitens: Wenn ich ein stateFormat mit einem bestimmten Wert anlegen wuerde: wo ist das Unterschied zum state direkt schreiben?

hschmitt

Zitat von: rudolfkoenig am 12 Mai 2015, 16:38:20
Erstens: Ein Attribut hat ein (hoffentlich dokumentiertes) default Wert, und mAn sollte kein Modul fuer den Benutzer Attribute anlegen.

Zweitens: Wenn ich ein stateFormat mit einem bestimmten Wert anlegen wuerde: wo ist das Unterschied zum state direkt schreiben?
Zu erstens bist Du der die Regeln festlegt.
Zu Zweitens: Die Änderung würde wie folgt aussehen. Anstatt in "state" zu schreiben, würde z.B. in <classname>State geschrieben werden.
Beim Inkludieren eines Zwave Gerätes würde ein stateFormat in die fhem.cfg eingefügt werden. Falls es mehrere gibt könnte man nach einer Reihenfolge das eines auswählen. Die anderen, vielleicht schon auskommentiert einfügen (oder ein stateFormat so schreiben, dass das letzte gewinnt)
Vorteile: a) Falls ein Gerät mehrere Klassen hat, die zur Zeit state schreiben, überschreiben sich diese nicht mehr.
b) Der User kann sich das reading aussuchen, welches sein state sein soll.
c) Es gibt ein default state.