Hi,
ich habe mir für mein Garagentor den Vision Sensor geholt.
List liefert mir folgendes:
CFGFN
DEF c1aa9dda 17
IODev ZWAVE1
LASTInputDev ZWAVE1
MSGCNT 458
NAME ZWave_SENSOR_BINARY_17
NR 774
STATE 00
TYPE ZWave
ZWAVE1_MSGCNT 458
ZWAVE1_RAWMSG 000400110a7105070000ff07020000
ZWAVE1_TIME 2016-03-02 00:18:48
homeId c1aa9dda
isWakeUp 1
lastMsgSent 1456873955.39823
nodeIdHex 11
Readings:
2016-03-02 00:12:28 CMD ZW_APPLICATION_UPDATE
2016-03-01 22:25:32 UNPARSED WAKE_UP 06840301050000
2016-03-02 00:18:48 alarm HomeSecurity: Event cleared: Intrusion, Unknown Location
2016-03-02 00:12:35 assocGroup_1 Max 5 Nodes ZWAVE1
2016-03-02 00:12:35 assocGroups 1
2016-03-02 00:18:48 basicSet 00
2016-03-01 18:54:56 battery 100 %
2016-03-01 18:51:37 model Vision ZG8101 Garage Door Detector
2016-03-01 18:51:37 modelConfig vision/zg8101.xml
2016-03-01 18:51:37 modelId 0109-200a-0a02
2016-03-02 00:12:35 state associationRequest 1
2016-03-02 00:12:37 transmit OK
2016-03-01 20:02:49 wakeup notification
2016-03-01 22:15:55 wakeupReport interval 600 target 200
Versionhash:
ALARM
ASSOCIATION
BASIC
BATTERY
MANUFACTURER_SPECIFIC
SENSOR_BINARY
VERSION
Attributes:
IODev ZWAVE1
classes ALARM ASSOCIATION BATTERY MANUFACTURER_SPECIFIC SENSOR_BINARY VERSION WAKE_UP BASIC
room ZWave
stateFormat basicSet
Mein erstes Problem ist, dass ich trotz dem Attribut stateFormat basicSet nicht den Zustand des Sensors in das State Reading bekomme. Dort steht bei mir immer "associationRequest 1".
2. Problem: Trotz vieler Artikel hier und auch im Wiki ist mir nicht 100%ig klar, was es mit den Assoziationsgruppen auf sich hat. Gibt es irgendwo eine für Anfänger geschriebene Übersicht? Und kann ich jeden Sensor in verschiedene Gruppen setzen?
Danke
Gruss
Dennis
1. siehe stateFormat
2. Es gibt das Buch von Paetz. Eine Assoziationsgruppe ist sowas wie ein Twitter-Account: Sensoren/Schalter posten Nachrichten, und FHEM bzw. Aktoren koennen ein Kanal abonnieren. Welche Events ueber eine bestimmte Gruppe gesendet werden, ist vom Sensor/Schalter abhaengig, und manchmal per configXXX konfigurierbar. FHEM meldet sich beim Anlegen automatisch in der Gruppe 1 an.
Hallo Rudi,
zu 1: ich habe stateFormat in den Attributen ja gesetzt, aber leider wird es nicht übernommen.
zu 2: Gibt es denn eine Übersicht aller Z-Wave Geräte, die zeigt, welche Gruppen pro Hersteller/Device unterstützt werden?
3. Macht es denn Sinn, in meinem Beispiel mit dem Vision Garage Sensor, den aus der Gruppe 1 zu entfernen und in eine andere Gruppe zu stecken?
Gruss
Dennis
Hi,
also Buch habe ich gefunden und werde ich mir zulegen.
Jetzt geht es mit eigentlich nur noch um das Reading.
Ich verstehe nicht, wieso ich mit "stateFormat basicSet" keinen Zugriff auf das Reading habe. Was mache ich falsch?
Wenn ich mit eventmap open:ff und close:00 mache, dann ändert er mir das basicSet Reading, aber eben nicht das state Reading.
Gruss
Dennis
Hallo Dennis,
wie sieht es den bei dem reading "reportedState" aus?. Meine Fibaro Tür/Fenster Sensoren ändern beides. Und überhaupt, funktioniert das wakeup?
Vielleicht hilft ja noch einmal excluden/includen.
Grüße,
Josef
Wakeup funktioniert talellos.
Aber das state Reading ändert sich nicht. Ich kann machen was ich will.
Ich habe basicSet und basicReport. Diese Readings ändern sich auch. Aber eben nicht state.
Gruss
Dennis
P.S. Hier noch ein aktuelles list:
Internals:
DEF c1aa9dda 17
IODev ZWAVE1
LASTInputDev ZWAVE1
MSGCNT 7
NAME ZWave_SENSOR_BINARY_17
NR 122
STATE zu
TYPE ZWave
ZWAVE1_MSGCNT 7
ZWAVE1_RAWMSG 00040011028407
ZWAVE1_TIME 2016-03-02 20:39:22
homeId c1aa9dda
isWakeUp 1
lastMsgSent 1456947562.56263
nodeIdHex 11
Readings:
2016-03-02 16:47:06 CMD ZW_APPLICATION_UPDATE
2016-03-01 22:25:32 UNPARSED WAKE_UP 06840301050000
2016-03-02 20:25:57 alarm HomeSecurity: Event cleared: Intrusion, Unknown Location
2016-03-02 00:12:35 assocGroup_1 Max 5 Nodes ZWAVE1
2016-03-02 16:25:24 assocGroups 1
2016-03-02 16:43:46 basicReport 00
2016-03-02 20:25:57 basicSet 00
2016-03-01 18:54:56 battery 100 %
2016-03-01 18:51:37 model Vision ZG8101 Garage Door Detector
2016-03-01 18:51:37 modelConfig vision/zg8101.xml
2016-03-01 18:51:37 modelId 0109-200a-0a02
2016-03-02 18:41:37 state TRANSMIT_NO_ACK
2016-03-02 20:39:24 transmit OK
2016-03-02 20:39:22 wakeup notification
2016-03-02 17:02:20 wakeupReport interval 600 target 1
Attributes:
IODev ZWAVE1
alias Garage_Sensor
classes ALARM ASSOCIATION BATTERY MANUFACTURER_SPECIFIC SENSOR_BINARY VERSION WAKE_UP BASIC
eventMap 00:zu ff:auf
room Aussen,Information
stateFormat basicSet
Also ich habe mein Problem jetzt mit einem DOIF gelöst bekommen.
([ZWave_SENSOR_BINARY_18] eq "00" )(setreading ZWave_SENSOR_BINARY_18 state ZU)
DOELSEIF ([ZWave_SENSOR_BINARY_18] eq "ff" )(setreading ZWave_SENSOR_BINARY_18 state AUF)
Gruss
Dennis
ZitatIch verstehe nicht, wieso ich mit "stateFormat basicSet" keinen Zugriff auf das Reading habe. Was mache ich falsch?
Scheint bei dir das gleiche Problem zu sein, wie mit userReadings:
fhem> attr ZWave_SENSOR_BINARY_18 stateFormat basicSet
fhem> {Dispatch($defs{zwc}, "0004001203200100", undef) }
fhem> list
...
ZWave_SENSOR_BINARY_18 (00)
...da bei mir auch stateFormat tadellos funktioniert.
Hallo Rudi,
hast Du noch einen Tipp wie ich dem Problem auf die Schliche komme?
Habe soeben noch einmal extra auf die neuste Version aktualisiert. Veraltete Version kann ich ausschließen.
Und lokal habe ich auch nichts angepasst oder verändert.
Danke
Gruss
Dennis
Hallo,
ich hänge mich hier einmal 'ran weil ich mit meinem Vision Security Fenstersensor ZD2102EU-5 (also die ZWave+ Version) ähnliches erlebe.
Ist für mich ein Verhalten, was ich so von anderen Sensoren (z.B. Fibaro Fenstersensor) nicht kenne.
Bei einem Öffnen/Schliessen ist im Event-Monitor folgendes zu sehen (kein eventMap, stateFormat oder event-on-.* Attribute gesetzt):
2016-03-05 19:22:16 ZWave XXXX_101_ZF basicSet: ff
2016-03-05 19:22:17 ZWave XXXX_101_ZF alarm: AccessControl: Window/Door is open, arg 0000
2016-03-05 19:22:28 ZWave XXXX_101_ZF basicSet: 00
2016-03-05 19:22:28 ZWave XXXX_101_ZF alarm: AccessControl: Event cleared: Window/Door is closed
Logischerweise werden die Readings "alarm" und "basicSet" aktualisiert, das Reading "state" und Internal "STATE" werden nicht aktualisiert, s. Screenshot:
(https://forum.fhem.de/index.php?action=dlattach;topic=50100.0;attach=47934;image)
Im Vergleich der Fibaro Fenstersensor:
2016-03-05 19:37:14 ZWave SZOG_ZF open
2016-03-05 19:37:14 ZWave SZOG_ZF reportedState: open
2016-03-05 19:37:14 ZWave SZOG_ZF basicSet: ff
2016-03-05 19:37:22 ZWave SZOG_ZF closed
2016-03-05 19:37:22 ZWave SZOG_ZF reportedState: closed
2016-03-05 19:37:22 ZWave SZOG_ZF basicSet: 00
Beim Fibaro Sensor taucht also auch der "state" im Event-Monitor auf, beim Vision Security Sensor nicht.
Nun gut, über das Attribut "stateFormat" kann man zumindest das Internal STATE anpassen, was auch funktioniert (allerdings wird ein über stateFormat aktualisierter Wert von STATE zumindest bei mir erst nach einem manuellem Reload z.B. der Detailseite des Devices korrekt angezeigt). In Kombination mit dem Attribut "eventMap" dann sogar mit sprechenderen Bezeichnungen.
Beispiel mit
attr XXXX_101_ZF eventMap basicSet..00:closed basicSet..ff:opened
attr XXXX_101_ZF stateFormat {if (ReadingsVal($name,"basicSet","unknown") eq "00") {return "closed";} elsif (ReadingsVal($name,"basicSet","unknown") eq "ff") {return "opened";} else {return "unknown";}}:
(https://forum.fhem.de/index.php?action=dlattach;topic=50100.0;attach=47936;image)
Und das Reading "state" bleibt trotz der nun im Monitor auftretenden Events:
2016-03-05 20:47:53 ZWave XXXX_101_ZF opened
2016-03-05 20:47:54 ZWave XXXX_101_ZF alarm: AccessControl: Window/Door is open, arg 0000
2016-03-05 20:48:01 ZWave XXXX_101_ZF closed
2016-03-05 20:48:01 ZWave XXXX_101_ZF alarm: AccessControl: Event cleared: Window/Door is closed leider ziemlich unbeeindruckt und unverändert (s. obiger zweiter Screenshot).
Meiner Meinung nach also wohl erklärbar, ohne einen wirklich direkt vom Sensor gemeldeten "state" kann sich das Reading "state" eben nicht ändern.
Aber: kann es wirklich so erklärt werden, liegt vielleicht doch ein Fehler vor oder gibt es andere Wege, mit diesem Verhalten der Vision Security Sensoren umzugehen?
Viele Grüße,
Andreas
PS: Ich weiss nicht, ob das hilfreich ist, aber anbei ein aktuelles list des Vision Security Fenstersensor und ein verbose 5 Log mit einem Öffnungs-/Schließvorgang:
Internals:
DEF d79c8805 101
IODev ZW_Dongle
LASTInputDev ZW_Dongle
MSGCNT 68
NAME XXXX_101_ZF
NR 620
STATE opened
TYPE ZWave
ZW_Dongle_MSGCNT 68
ZW_Dongle_RAWMSG 000400651e988123640b9b98f0b40cabd1d36e3a41af17a647462aa0fb2a02f5c0f982
ZW_Dongle_TIME 2016-03-05 21:07:20
homeId d79c8805
isWakeUp 1
lastMsgSent 1457208440.29872
nodeIdHex 65
secTime 1457208440.29517
Readings:
2016-03-05 13:26:00 CMD ZW_APPLICATION_UPDATE
2016-03-05 13:04:32 SECURITY ENABLED
2016-03-05 21:07:20 alarm AccessControl: Window/Door is open, arg 0000
2016-03-05 13:08:22 assocGroup_1 Max 5 Nodes ZW_Dongle
2016-03-05 13:08:22 assocGroups 1
2016-03-05 21:07:20 basicSet ff
2016-03-05 13:22:45 battery 90 %
2016-03-05 13:09:54 configExternalSwitch Off
2016-03-05 13:04:35 model Vision ZD2102 EU Door/Window Sensor
2016-03-05 13:04:35 modelConfig vision/zd2102.xml
2016-03-05 13:04:35 modelId 0109-2001-0106
2016-03-05 13:04:33 state wakeupInterval 86400 01
2016-03-05 21:07:20 transmit OK
2016-03-05 13:22:45 wakeup notification
2016-03-05 13:10:28 wakeupReport interval 86400 target 1
secMsg:
Attributes:
IODev ZW_Dongle
classes ZWAVEPLUS_INFO MANUFACTURER_SPECIFIC DEVICE_RESET_LOCALLY BATTERY POWERLEVEL VERSION WAKE_UP ASSOCIATION ASSOCIATION_GRP_INFO ALARM CONFIGURATION FIRMWARE_UPDATE_MD SECURITY MARK BASIC
eventMap basicSet..00:closed basicSet..ff:opened
group XX
icon max_fensterkontakt
room ZWave
secure_classes MANUFACTURER_SPECIFIC DEVICE_RESET_LOCALLY BATTERY POWERLEVEL VERSION WAKE_UP ASSOCIATION ASSOCIATION_GRP_INFO ALARM CONFIGURATION FIRMWARE_UPDATE_MD MARK
stateFormat {if (ReadingsVal($name,"basicSet","unknown") eq "00") {return "closed";} elsif (ReadingsVal($name,"basicSet","unknown") eq "ff") {return "opened";} else {return "unknown";}}
2016.03.05 21:00:29.521 4: ZWDongle_Read ZW_Dongle: sending ACK, processing 00040065029840
2016.03.05 21:00:29.522 5: SW: 06
2016.03.05 21:00:29.523 5: ZW_Dongle dispatch 00040065029840
2016.03.05 21:00:29.524 4: CMD:APPLICATION_COMMAND_HANDLER ID:65 ARG:029840
2016.03.05 21:00:29.526 5: ZWDongle_Write 0013650a9880e7caa7f4c9a6af0f2565 (d79c8805)
2016.03.05 21:00:29.528 5: SW: 01110013650a9880e7caa7f4c9a6af0f25657b
2016.03.05 21:00:29.533 5: ACK received, WaitForAck=>2 for 01110013650a9880e7caa7f4c9a6af0f25657b
2016.03.05 21:00:29.537 4: ZWDongle_Read ZW_Dongle: sending ACK, processing 011301
2016.03.05 21:00:29.538 5: SW: 06
2016.03.05 21:00:29.539 5: ZW_Dongle dispatch 011301
2016.03.05 21:00:29.554 4: ZWDongle_Read ZW_Dongle: sending ACK, processing 001365000002
2016.03.05 21:00:29.554 5: SW: 06
2016.03.05 21:00:29.556 5: device ack reveived, removing 01110013650a9880e7caa7f4c9a6af0f25657b from dongle sendstack
2016.03.05 21:00:29.556 5: ZW_Dongle dispatch 001365000002
2016.03.05 21:00:29.557 4: CMD:ZW_SEND_DATA ID:00 ARG:0002
2016.03.05 21:00:29.557 4: ZW_Dongle transmit OK for 65
2016.03.05 21:00:29.572 4: ZWDongle_Read ZW_Dongle: sending ACK, processing 0004006517988191dde5e89a5d93b2d85556c6e75261c001fd68f282
2016.03.05 21:00:29.573 5: SW: 06
2016.03.05 21:00:29.574 5: ZW_Dongle dispatch 0004006517988191dde5e89a5d93b2d85556c6e75261c001fd68f282
2016.03.05 21:00:29.575 4: CMD:APPLICATION_COMMAND_HANDLER ID:65 ARG:17988191dde5e89a5d93b2d85556c6e75261c001fd68f282
2016.03.05 21:00:29.579 4: CMD:APPLICATION_COMMAND_HANDLER ID:65 ARG:032001ff
2016.03.05 21:00:29.623 4: ZWDongle_Read ZW_Dongle: sending ACK, processing 00040065029840
2016.03.05 21:00:29.623 5: SW: 06
2016.03.05 21:00:29.625 5: ZW_Dongle dispatch 00040065029840
2016.03.05 21:00:29.625 4: CMD:APPLICATION_COMMAND_HANDLER ID:65 ARG:029840
2016.03.05 21:00:29.627 5: ZWDongle_Write 0013650a9880cfb8cb0114f9f1992565 (d79c8805)
2016.03.05 21:00:29.629 5: SW: 01110013650a9880cfb8cb0114f9f1992565f2
2016.03.05 21:00:29.637 5: ACK received, WaitForAck=>2 for 01110013650a9880cfb8cb0114f9f1992565f2
2016.03.05 21:00:29.641 4: ZWDongle_Read ZW_Dongle: sending ACK, processing 011301
2016.03.05 21:00:29.641 5: SW: 06
2016.03.05 21:00:29.643 5: ZW_Dongle dispatch 011301
2016.03.05 21:00:29.656 4: ZWDongle_Read ZW_Dongle: sending ACK, processing 001365000002
2016.03.05 21:00:29.657 5: SW: 06
2016.03.05 21:00:29.659 5: device ack reveived, removing 01110013650a9880cfb8cb0114f9f1992565f2 from dongle sendstack
2016.03.05 21:00:29.659 5: ZW_Dongle dispatch 001365000002
2016.03.05 21:00:29.660 4: CMD:ZW_SEND_DATA ID:00 ARG:0002
2016.03.05 21:00:29.660 4: ZW_Dongle transmit OK for 65
2016.03.05 21:00:29.675 4: ZWDongle_Read ZW_Dongle: sending ACK, processing 000400651e988114b269dd2727e483c34138b952dda7325d2d6acffb24dd44b996c3f0
2016.03.05 21:00:29.676 5: SW: 06
2016.03.05 21:00:29.678 5: ZW_Dongle dispatch 000400651e988114b269dd2727e483c34138b952dda7325d2d6acffb24dd44b996c3f0
2016.03.05 21:00:29.684 4: CMD:APPLICATION_COMMAND_HANDLER ID:65 ARG:1e988114b269dd2727e483c34138b952dda7325d2d6acffb24dd44b996c3f0
2016.03.05 21:00:29.688 4: CMD:APPLICATION_COMMAND_HANDLER ID:65 ARG:0a710506ff00ff06160000
2016.03.05 21:00:34.152 4: ZWDongle_Read ZW_Dongle: sending ACK, processing 0004003912600d0103320221340000004b00090000005a
2016.03.05 21:00:34.152 5: SW: 06
2016.03.05 21:00:34.154 5: ZW_Dongle dispatch 0004003912600d0103320221340000004b00090000005a
2016.03.05 21:00:34.155 4: CMD:APPLICATION_COMMAND_HANDLER ID:39 ARG:12600d0103320221340000004b00090000005a
2016.03.05 21:00:34.413 4: ZWDongle_Read ZW_Dongle: sending ACK, processing 00040065029840
2016.03.05 21:00:34.414 5: SW: 06
2016.03.05 21:00:34.415 5: ZW_Dongle dispatch 00040065029840
2016.03.05 21:00:34.416 4: CMD:APPLICATION_COMMAND_HANDLER ID:65 ARG:029840
2016.03.05 21:00:34.418 5: ZWDongle_Write 0013650a988076b336466c73c91c2565 (d79c8805)
2016.03.05 21:00:34.420 5: SW: 01110013650a988076b336466c73c91c2565b5
2016.03.05 21:00:34.429 5: ACK received, WaitForAck=>2 for 01110013650a988076b336466c73c91c2565b5
2016.03.05 21:00:34.433 4: ZWDongle_Read ZW_Dongle: sending ACK, processing 011301
2016.03.05 21:00:34.433 5: SW: 06
2016.03.05 21:00:34.437 5: ZW_Dongle dispatch 011301
2016.03.05 21:00:34.446 4: ZWDongle_Read ZW_Dongle: sending ACK, processing 001365000002
2016.03.05 21:00:34.447 5: SW: 06
2016.03.05 21:00:34.449 5: device ack reveived, removing 01110013650a988076b336466c73c91c2565b5 from dongle sendstack
2016.03.05 21:00:34.449 5: ZW_Dongle dispatch 001365000002
2016.03.05 21:00:34.450 4: CMD:ZW_SEND_DATA ID:00 ARG:0002
2016.03.05 21:00:34.450 4: ZW_Dongle transmit OK for 65
2016.03.05 21:00:34.464 4: ZWDongle_Read ZW_Dongle: sending ACK, processing 00040065179881d9d78305fec3dacd320e0b0e760f3ef41e50606466
2016.03.05 21:00:34.465 5: SW: 06
2016.03.05 21:00:34.466 5: ZW_Dongle dispatch 00040065179881d9d78305fec3dacd320e0b0e760f3ef41e50606466
2016.03.05 21:00:34.467 4: CMD:APPLICATION_COMMAND_HANDLER ID:65 ARG:179881d9d78305fec3dacd320e0b0e760f3ef41e50606466
2016.03.05 21:00:34.470 4: CMD:APPLICATION_COMMAND_HANDLER ID:65 ARG:03200100
2016.03.05 21:00:34.513 4: ZWDongle_Read ZW_Dongle: sending ACK, processing 00040065029840
2016.03.05 21:00:34.514 5: SW: 06
2016.03.05 21:00:34.515 5: ZW_Dongle dispatch 00040065029840
2016.03.05 21:00:34.516 4: CMD:APPLICATION_COMMAND_HANDLER ID:65 ARG:029840
2016.03.05 21:00:34.518 5: ZWDongle_Write 0013650a98802d6e788d0ecd8f052565 (d79c8805)
2016.03.05 21:00:34.520 5: SW: 01110013650a98802d6e788d0ecd8f05256535
2016.03.05 21:00:34.525 5: ACK received, WaitForAck=>2 for 01110013650a98802d6e788d0ecd8f05256535
2016.03.05 21:00:34.530 4: ZWDongle_Read ZW_Dongle: sending ACK, processing 011301
2016.03.05 21:00:34.531 5: SW: 06
2016.03.05 21:00:34.532 5: ZW_Dongle dispatch 011301
2016.03.05 21:00:34.547 4: ZWDongle_Read ZW_Dongle: sending ACK, processing 001365000002
2016.03.05 21:00:34.547 5: SW: 06
2016.03.05 21:00:34.548 5: device ack reveived, removing 01110013650a98802d6e788d0ecd8f05256535 from dongle sendstack
2016.03.05 21:00:34.549 5: ZW_Dongle dispatch 001365000002
2016.03.05 21:00:34.550 4: CMD:ZW_SEND_DATA ID:00 ARG:0002
2016.03.05 21:00:34.550 4: ZW_Dongle transmit OK for 65
2016.03.05 21:00:34.567 4: ZWDongle_Read ZW_Dongle: sending ACK, processing 000400651e98816a57e10bdbdc4f73a5fe48fcaaf0ae145975162d1962b4f54bbc0aa7
2016.03.05 21:00:34.567 5: SW: 06
2016.03.05 21:00:34.569 5: ZW_Dongle dispatch 000400651e98816a57e10bdbdc4f73a5fe48fcaaf0ae145975162d1962b4f54bbc0aa7
2016.03.05 21:00:34.570 4: CMD:APPLICATION_COMMAND_HANDLER ID:65 ARG:1e98816a57e10bdbdc4f73a5fe48fcaaf0ae145975162d1962b4f54bbc0aa7
2016.03.05 21:00:34.572 4: CMD:APPLICATION_COMMAND_HANDLER ID:65 ARG:0a7105060000ff06170000
2016.03.05 21:00:43.150 4: ZWDongle_Read ZW_Dongle: sending ACK, processing 0004003912600d0103320221340000005600090000004b
2016.03.05 21:00:43.151 5: SW: 06
2016.03.05 21:00:43.153 5: ZW_Dongle dispatch 0004003912600d0103320221340000005600090000004b
2016.03.05 21:00:43.153 4: CMD:APPLICATION_COMMAND_HANDLER ID:39 ARG:12600d0103320221340000005600090000004b
2016.03.05 21:00:52.152 4: ZWDongle_Read ZW_Dongle: sending ACK, processing 0004003912600d0103320221340000004d000900000056
2016.03.05 21:00:52.152 5: SW: 06
2016.03.05 21:00:52.154 5: ZW_Dongle dispatch 0004003912600d0103320221340000004d000900000056
2016.03.05 21:00:52.155 4: CMD:APPLICATION_COMMAND_HANDLER ID:39 ARG:12600d0103320221340000004d000900000056
@Dennis: sorry, keine Idee.
@Andreas: Das Problem von Dennis ist was ganz anderes: beim ihm scheint stateFormat und userReadings nicht zu funktionieren.
Dein Vision meldet kein Status, sondern versucht ein anderes Geraet per basicSet zu schalten. Der Fibaro meldet ein Status.
Alles klar, kam mir nur komisch vor.
Aber wieder 'was gelernt, war mir nicht bewusst (und selbst bisher auch keine im Einsatz), dass es auch ZWave-Komponenten gibt, die ihren Status nicht senden, sondern nur andere Geräte schalten wollen.
Vielen Dank für die Erklärung und sorry an dennis_n für's Kapern seines Threads,
Andreas