Z-Wave Multichannel Problem

[dt2510]

Ich hab' die gleiche Frage schonmal gestellt, aber der Titel war vielleicht verwirrend, also hier nochmal die Frage:

Ich habe heute ein Fibaro 2-fach Relais FGS222 in Betrieb genommen. Inkludiert wurden es über die Aeon Labs Software und erschien dann auch in FHEM als UNKNOWN_12.
Danach hab' ich die neue ID 12 mit

Code Auswählen Erweitern

set <dongle> createNode 12
angelegt und danach mit

Code Auswählen Erweitern

set <node> mcCreateAll
die beiden einzelnen Schalter angelegt. Ich habe jetzt 3 ZWave Devices:
- FGS222_ID12 (das 2-fach Relais)
- FGS222_ID12.01 (den 1. Schalter)
- FGS222_ID12.02 (den 2. Schalter)
Soweit funktioniert auch alles, allerdings wird beim manuellen Schalten nicht der Status des 1. Schalters (FGS222_ID12.01) sondern der des gesamten Relais (FGS222_ID12) aktualisiert. Beim 2. Schalter klappt alles. Ist das normal oder kann man das Verhalten ändern ?

Zur Verdeutlichung hier ein Screenshot mit den 3 Devices - das rot eingekreiste ändert sich bei manueller Betätigung des Schalters nie.

(https://dl.dropboxusercontent.com/u/47493657/FGS222.png)

[Ralf.E]

Moin,

das Verhalten habe ich gestern bei mir auch festgestellt.

Ich verwende den ersten Endpoint eines FGS222, um das Schalten eines Bewegungsmelders weiter zu verwenden. Bei einem weiteren FGS222 hängt ein Schalter am zweiten Endpoint und dort werden Schaltvorgänge gemeldet.

Ich bin auch der Meinung, dass es bis vor kurzem noch mit dem Bewegungsmelder am Endpoint 1 funktioniert hat. Warum es jetzt nicht mehr geht oder ich mich da irre - bin noch am suchen...

Ralf

[rudolfkoenig]

Mit dem Endpoint 1 hat es noch nie funktioniert, aber bis vor kurzem wurde auch kein Endpoint 1 angelegt.
Dass es kein Kind#1 gibt, war fuer manche verwirrend, deswegen haben wir das angelegt.
Dass die Meldungen nicht korrekt zugeordnet werden, habe ich erstmals ausgeblendet.
@Christian: soll ich das fixen (und hoffen, dass es keine weiteren Nebeneffekte hat), oder das Feature mit Kind#1 zurueckdrehen. Ich tendiere zum Ersteren.

[dt2510]

Also aus meiner Sicht logisch wäre es wenn die beiden Kinder #1 und #2 auch wirklich den Zustand anzeigen, in dem sie sich befinden und das Gerät selbst beide Kanäle darstellt, also

- Kind #1 und #2 anschaltet, wenn man auf on clickt
- Kind #1 und #2 ausschaltet, wenn man auf off clickt
- Status "on" anzeigt, wenn beide an sind, sonst "off" (nicht ganz korrekt, aber denke ich nicht anders darstellbar)

Alternativ könnte man dem Gerät die Schalter Klasse entziehen und die nur den Kindern zuordnen

[krikan]

soll ich das fixen (und hoffen, dass es keine weiteren Nebeneffekte hat), oder das Feature mit Kind#1 zurueckdrehen. Ich tendiere zum Ersteren.

Zurückdrehen finde ich nicht gut.
Warum landet das nicht in Kind#1? Kenne raw-Messages von Fibaro nicht.
Weil Fibaro nicht Multichannel für Kanal 1 nutzt, sondern die "normale" Statusrückmeldung? -> Dann wäre es aktuell in FHEM korrekt und Fibaro macht was falsch
Weil FHEM fälschlich Multichannel für Kanal 1 dem Hauptdevice zuordnet? -> Kann eigentlich nicht, da mEn bei meinem 2-Kanal-Philio-Aktor alles richtig läuft.
Hättest Du mal nicht gefragt.. 

[krikan]

In den Config-XMLs gibt es auch eine Angabe zur Behandlung der Endpoints unter "mapping". Der FGS222 hat "mapping=endpoints". Erläutert ist die Bedeutung des mappings hier https://groups.google.com/d/msg/openzwave/FeFNBI8GAKk/dyXAO54BiqgJ . So richtig verständlich ist mir das aber anhand der Erfahrung mit Endpoint-Devices nicht; insbesondere, da der Philio PAN04 das gleiche mapping wie der FGS222 haben soll.

@dt2510:
Könntest Du bitte ein Log mit verbose 5 von manuellen Schalten von Kanal 1 und Kanal 2 posten, wenn Du dazu Zeit hast?

[Ralf.E]

Da ich mir den FGS222 gerade zum Testen auf den Tisch gelegt habe...

Wenn hier von 'verbose 5' gesprochen wird: bezogen auf den (hier) ZWDongle oder 'global'?

Ralf

[Ralf.E]

Ist es das wonach Du gefragt hast?

Code Auswählen Erweitern

S1 on/off
2016.03.04 17:51:04 4: ZWDongle_Read ZWAVE1: sending ACK, processing 0004000f032503ff
2016.03.04 17:51:04 5: SW: 06
2016.03.04 17:51:04 5: ZWAVE1 dispatch 0004000f032503ff
2016.03.04 17:51:04 4: CMD:APPLICATION_COMMAND_HANDLER ID:0f ARG:032503ff
2016.03.04 17:51:04 5: Triggering cp_Device_FGS222 (2 changes)
2016.03.04 17:51:04 5: Notify loop for cp_Device_FGS222 on
2016.03.04 17:51:10 4: ZWDongle_Read ZWAVE1: sending ACK, processing 0004000f03250300
2016.03.04 17:51:10 5: SW: 06
2016.03.04 17:51:10 5: ZWAVE1 dispatch 0004000f03250300
2016.03.04 17:51:10 4: CMD:APPLICATION_COMMAND_HANDLER ID:0f ARG:03250300
2016.03.04 17:51:10 5: Triggering cp_Device_FGS222 (2 changes)
2016.03.04 17:51:10 5: Notify loop for cp_Device_FGS222 off


S2 on/off
2016.03.04 17:51:43 4: ZWDongle_Read ZWAVE1: sending ACK, processing 0004000f07600d02022503ff
2016.03.04 17:51:43 5: SW: 06
2016.03.04 17:51:43 5: ZWAVE1 dispatch 0004000f07600d02022503ff
2016.03.04 17:51:43 4: CMD:APPLICATION_COMMAND_HANDLER ID:0f ARG:07600d02022503ff
2016.03.04 17:51:43 5: Triggering cp_Light_e2 (2 changes)
2016.03.04 17:51:43 5: Notify loop for cp_Light_e2 on
2016.03.04 17:51:46 4: ZWDongle_Read ZWAVE1: sending ACK, processing 0004000f07600d0202250300
2016.03.04 17:51:46 5: SW: 06
2016.03.04 17:51:46 5: ZWAVE1 dispatch 0004000f07600d0202250300
2016.03.04 17:51:46 4: CMD:APPLICATION_COMMAND_HANDLER ID:0f ARG:07600d0202250300
2016.03.04 17:51:46 5: Triggering cp_Light_e2 (2 changes)
2016.03.04 17:51:46 5: Notify loop for cp_Light_e2 off


Und das 'list xyz' vom Device ...

Code Auswählen Erweitern

Internals:
   DEF        deefb60e 15
   IODev      ZWAVE1
   LASTInputDev ZWAVE1
   MSGCNT     162
   NAME       cp_Device_FGS222
   NR         32
   STATE      off
   TYPE       ZWave
   ZWAVE1_MSGCNT 162
   ZWAVE1_RAWMSG 0004000f03250300
   ZWAVE1_TIME 2016-03-04 17:51:10
   homeId     deefb60e
   isWakeUp
   lastMsgSent 1457072981.72314
   nodeIdHex  0f
   Readings:
     2016-02-06 15:55:11   CMD             ZW_APPLICATION_UPDATE
     2016-03-03 22:42:54   assocGroup_1    Max 5 Nodes ZWAVE1
     2016-03-03 22:42:54   assocGroup_2    Max 5 Nodes
     2016-03-03 22:42:54   assocGroup_3    Max 1 Nodes ZWAVE1
     2016-03-03 22:42:54   assocGroups     3
     2016-03-03 22:33:39   configALARMFLASHINGAlarmTime 600
     2016-03-03 22:33:40   configAutoOffForRelay1 0
     2016-03-03 22:33:40   configAutoOffForRelay2 0
     2016-03-03 22:33:40   configAutoOffRelayAfterSpecifiedTime ManualOverrideDisabled
     2016-03-03 22:33:40   configControlKey2Behaviour DeviceStatusIsNotChecked
     2016-03-04 07:29:41   configDimmerRollerShutterControl EnableDimmerRollerShutterControl
     2016-03-03 22:33:32   configEnableDisableALLONOFF ALLONActiveALLOFFActive
     2016-03-03 22:33:41   configInputsBehaviour FollowSwitchContactClosedONOpenO1
     2016-03-03 22:33:32   configInputsButtonSwitchConfiguration BiStableInputSwitch
     2016-03-03 22:33:33   configRelay1ResponseToGeneralAlarm ALARMFLASHINGRelayWillTurnONAndO3
     2016-03-03 22:33:41   configRelay1ResponseToSmokeCOCO2Alarm ALARMFLASHINGRelayWillTurnONAndO3
     2016-03-03 22:33:41   configRelay1ResponseToTemperatureAlarm ALARMRELAYONRelayWillTurnONUpon1
     2016-03-03 22:33:38   configRelay1ResponseToWaterFloodAlarm ALARMRELAYOFFRelayWillTurnOFF2
     2016-03-03 22:33:42   configRelay2ResponseToGeneralAlarm ALARMFLASHINGRelayWillTurnONAndO3
     2016-03-03 22:33:38   configRelay2ResponseToSmokeCOCO2Alarm ALARMFLASHINGRelayWillTurnONAndO3
     2016-03-03 22:33:39   configRelay2ResponseToTemperatureAlarm ALARMRELAYONRelayWillTurnONUpon1
     2016-03-03 22:33:39   configRelay2ResponseToWaterFloodAlarm ALARMRELAYOFFRelayWillTurnOFF2
     2016-03-03 22:33:42   configSavingStateBeforePowerFaillure StateSavedAtPowerFailureAll1
     2016-03-03 22:33:43   configSeparationOfAssociationSending6 MapStatusToAllDevicesInGroup10
     2016-03-03 23:24:51   mcCapability_01 SWITCH_BINARY
     2016-03-03 23:24:54   mcCapability_02 SWITCH_BINARY
     2016-03-03 23:24:59   mcEndpoints     total 2, identical
     2016-03-03 23:24:06   mcaSupportedGroupings 2
     2016-03-03 23:25:12   mca_01          max:05 param:00000101
     2016-03-03 23:25:15   mca_02          max:05 param:00000102
     2016-03-02 22:32:20   mca_03          max:00 param:00
     2016-03-04 07:12:39   model           FIBARO System FGS222 Double Relay Switch 2x1.5kW
     2016-03-04 07:12:39   modelConfig     fibaro/fgs222.xml
     2016-03-04 07:12:39   modelId         010f-0202-1002
     2016-03-02 21:20:43   neighborList    ZWAVE1 tr_Device_FGS222 wz_JalousieFenster wz_JalousieTuer
     2016-02-16 19:37:28   off             0
     2016-02-16 19:36:37   on              0
     2016-02-06 18:29:09   powerlvl        current 0 remain 0
     2016-03-02 22:49:05   powerlvlTest    node 1 status 0 frameAck 0
     2016-03-04 17:51:10   reportedState   off
     2016-03-04 17:51:10   state           off
     2016-03-03 23:24:12   swa             on off
     2016-03-04 07:29:41   transmit        OK
     2016-03-02 22:46:59   version         Lib 3 Prot 3.52 App 2.2
Attributes:
   IODev      ZWAVE1
   classes    MANUFACTURER_SPECIFIC VERSION CONFIGURATION ASSOCIATION MULTI_CHANNEL_ASSOCIATION MULTI_CHANNEL SWITCH_BINARY SWITCH_ALL FIRMWARE_UPDATE_MD POWERLEVEL MARK SWITCH_BINARY MULTI_CHANNEL
   comment    Device reflecting endpoint 1
   icon       edit_settings@grey
   room       Carport,ZWave

Und vom Endpoint_1

Code Auswählen Erweitern

Internals:
   DEF        deefb60e 3841
   IODev      ZWAVE1
   LASTInputDev ZWAVE1
   MSGCNT     5
   NAME       cp_MotionSensor
   NR         73
   STATE      off
   TYPE       ZWave
   ZWAVE1_MSGCNT 5
   ZWAVE1_RAWMSG 0004000f07600d0101250300
   ZWAVE1_TIME 2016-03-02 22:41:09
   homeId     deefb60e
   isWakeUp
   nodeIdHex  0f01
   Readings:
     2016-03-03 23:22:57   reportedState   off
     2016-03-03 23:34:42   state           off
Attributes:
   IODev      ZWAVE1
   classes    SWITCH_BINARY
   comment    MotionSensor @ Endpoint 1
   devStateIcon off:people_sensor@lightgrey on:people_sensor@tomato
   group      Terasse
   icon       people_sensor
   room       Carport,Terasse,ZWave

Und Enpoint_2:

Code Auswählen Erweitern

Internals:
   DEF        deefb60e 3842
   IODev      ZWAVE1
   LASTInputDev ZWAVE1
   MSGCNT     8
   NAME       cp_Light_e2
   NR         34
   STATE      off
   TYPE       ZWave
   ZWAVE1_MSGCNT 8
   ZWAVE1_RAWMSG 0004000f07600d0202250300
   ZWAVE1_TIME 2016-03-04 17:51:46
   homeId     deefb60e
   isWakeUp
   nodeIdHex  0f02
   Readings:
     2016-03-04 17:51:46   reportedState   off
     2016-03-04 17:51:46   state           off
Attributes:
   IODev      ZWAVE1
   classes    SWITCH_BINARY
   devStateIcon off:light_light_dim_00 on:light_light_dim_100@orange
   icon       control_x@lightgrey
   room       Carport,ZWave

Ralf

[Ralf.E]

Dass die Meldungen nicht korrekt zugeordnet werden, habe ich erstmals ausgeblendet.
@Christian: soll ich das fixen (und hoffen, dass es keine weiteren Nebeneffekte hat), oder das Feature mit Kind#1 zurueckdrehen. Ich tendiere zum Ersteren.

D.h. es ist jetzt erstmal Fhem das keine Zuordnung zum EP#1 vornimmt und nicht der FGS222, welcher aufgrund einer fehlenden/falschen Konfig keine Messages für EP#1 sendet?

[krikan]

Ist es das wonach Du gefragt hast?

Hallo Ralf!

Danke, genau das suchte ich.
verbose 5 bezog sich auf ZWDongle, aber global ist auch ok.

Schaltvorgang Kanal 1:
wird ohne Kanalangabe durch den Aktor gemeldet

Schaltvorgang Kanal 2:
wird mit Kanalangabe durch den Aktor über CC Multichannel gemeldet

-> also uneinheitlich und FHEM macht meiner Meinung nach nichts Falsches: Schaltvorgang Kanal 1 gehört in Hauptdevice und Schaltvorgang Kanal 2 in EP-Device .02

es ist jetzt erstmal Fhem das keine Zuordnung zum EP#1 vornimmt und nicht der FGS222, welcher aufgrund einer fehlenden/falschen Konfig keine Messages für EP#1 sendet?

Ich behaupte nach Deinem Log FHEM macht es richtig, aber das bleibt mMn Auslegungssache.

Was passiert, wenn Du im Hauptdevice und in EP-Device .01 den Status mit "get <device> swbStatus" abrufst? Stimmen die Rückgaben und landen sie im korrekten Device?

Gruß, Christian

[Ralf.E]

Schaltvorgang Kanal 1:
wird ohne Kanalangabe durch den Aktor gemeldet

Schaltvorgang Kanal 2:
wird mit Kanalangabe durch den Aktor über CC Multichannel gemeldet

-> also uneinheitlich und FHEM macht meiner Meinung nach nichts Falsches: Schaltvorgang Kanal 1 gehört in Hauptdevice und Schaltvorgang Kanal 2 in EP-Device .02

Wenn es der FGS222 nicht anders kann - spannende Frage, ob man ihm das durch irgendwelche Settings beibringen kann?
Letztendlich stört es (at least) mich nicht wirklich, wenn man es weiß

Wenn das Haupt-Device == EP#1 und dort keine sinnvolle Trennung möglich ist, dann sollte nur das zugehörige EP#1-Device nicht angelegt werden - das ist dann eher irreführend.

Was passiert, wenn Du im Hauptdevice und in EP-Device .01 den Status mit "get <device> swbStatus" abrufst? Stimmen die Rückgaben und landen sie im korrekten Device?

Wenn ich nur danach gehe welches reading rot dargestellt wird ja.

Man beachte das 'No ACK from cp_Device_FGS222' beim Abfragen von EP#1 und Ep#2!

Das Haupt-Device:

Code Auswählen Erweitern

Device (S1=S2=off):
2016.03.04 20:53:28 2: ZWave get cp_Device_FGS222 swbStatus
2016.03.04 20:53:28 5: ZWDongle_Write 00130f022502250f (deefb60e)
2016.03.04 20:53:28 5: SW: 010900130f022502250fe5
2016.03.04 20:53:28 4: ZWDongle_ReadAnswer arg:swbStatus regexp:^0004000f..25
2016.03.04 20:53:28 5: ACK received, WaitForAck=>2 for 010900130f022502250fe5
2016.03.04 20:53:28 4: ZWDongle_Read ZWAVE1: sending ACK, processing 011301
2016.03.04 20:53:28 5: SW: 06
2016.03.04 20:53:28 5: ZWAVE1 dispatch 011301
2016.03.04 20:53:28 4: ZWDongle_Read ZWAVE1: sending ACK, processing 00130f000002
2016.03.04 20:53:28 5: SW: 06
2016.03.04 20:53:28 5: device ack reveived, removing 010900130f022502250fe5 from dongle sendstack
2016.03.04 20:53:28 5: ZWAVE1 dispatch 00130f000002
2016.03.04 20:53:28 4: CMD:ZW_SEND_DATA ID:00 ARG:0002
2016.03.04 20:53:28 4: ZWAVE1 transmit OK for 0f
2016.03.04 20:53:28 4: ZWDongle_Read ZWAVE1: sending ACK, processing 0004000f03250300
2016.03.04 20:53:28 5: SW: 06
2016.03.04 20:53:28 4: ZWDongle_ReadAnswer for swbStatus: 0004000f03250300
2016.03.04 20:53:28 4: CMD:APPLICATION_COMMAND_HANDLER ID:0f ARG:03250300

Device (S1=on,S2=off)
2016.03.04 20:55:34 2: ZWave get cp_Device_FGS222 swbStatus
2016.03.04 20:55:34 5: ZWDongle_Write 00130f022502250f (deefb60e)
2016.03.04 20:55:34 5: SW: 010900130f022502250fe5
2016.03.04 20:55:34 4: ZWDongle_ReadAnswer arg:swbStatus regexp:^0004000f..25
2016.03.04 20:55:34 5: ACK received, WaitForAck=>2 for 010900130f022502250fe5
2016.03.04 20:55:34 4: ZWDongle_Read ZWAVE1: sending ACK, processing 011301
2016.03.04 20:55:34 5: SW: 06
2016.03.04 20:55:34 5: ZWAVE1 dispatch 011301
2016.03.04 20:55:34 4: ZWDongle_Read ZWAVE1: sending ACK, processing 00130f000002
2016.03.04 20:55:34 5: SW: 06
2016.03.04 20:55:34 5: device ack reveived, removing 010900130f022502250fe5 from dongle sendstack
2016.03.04 20:55:34 5: ZWAVE1 dispatch 00130f000002
2016.03.04 20:55:34 4: CMD:ZW_SEND_DATA ID:00 ARG:0002
2016.03.04 20:55:34 4: ZWAVE1 transmit OK for 0f
2016.03.04 20:55:34 4: ZWDongle_Read ZWAVE1: sending ACK, processing 0004000f032503ff
2016.03.04 20:55:34 5: SW: 06
2016.03.04 20:55:34 4: ZWDongle_ReadAnswer for swbStatus: 0004000f032503ff
2016.03.04 20:55:34 4: CMD:APPLICATION_COMMAND_HANDLER ID:0f ARG:032503ff

EP#1-Device:

Code Auswählen Erweitern

EP#1 (S1=S2=off):
2016.03.04 20:54:00 2: ZWave get cp_MotionSensor swbStatus
2016.03.04 20:54:00 5: ZWDongle_Write 00130f06600d01012502250f (deefb60e)
2016.03.04 20:54:00 5: SW: 010d00130f06600d01012502250f88
2016.03.04 20:54:00 4: ZWDongle_ReadAnswer arg:swbStatus regexp:^0004000f..60
2016.03.04 20:54:00 5: ACK received, WaitForAck=>2 for 010d00130f06600d01012502250f88
2016.03.04 20:54:00 4: ZWDongle_Read ZWAVE1: sending ACK, processing 011301
2016.03.04 20:54:00 5: SW: 06
2016.03.04 20:54:00 5: ZWAVE1 dispatch 011301
2016.03.04 20:54:00 4: ZWDongle_Read ZWAVE1: sending ACK, processing 00130f000002
2016.03.04 20:54:00 5: SW: 06
2016.03.04 20:54:00 5: device ack reveived, removing 010d00130f06600d01012502250f88 from dongle sendstack
2016.03.04 20:54:00 5: ZWAVE1 dispatch 00130f000002
2016.03.04 20:54:00 4: CMD:ZW_SEND_DATA ID:00 ARG:0002
2016.03.04 20:54:00 4: ZWAVE1 transmit OK for 0f
2016.03.04 20:54:00 4: ZWDongle_Read ZWAVE1: sending ACK, processing 0004000f07600d0101250300
2016.03.04 20:54:00 5: SW: 06
2016.03.04 20:54:00 4: ZWDongle_ReadAnswer for swbStatus: 0004000f07600d0101250300
2016.03.04 20:54:00 4: CMD:APPLICATION_COMMAND_HANDLER ID:0f ARG:07600d0101250300
2016.03.04 20:54:05 2: ZWave: No ACK from cp_Device_FGS222 after 5s for sentackget:130f06600d01012502250f

EP#1 (S1=on,S2=off)
2016.03.04 20:56:11 2: ZWave get cp_MotionSensor swbStatus
2016.03.04 20:56:11 5: ZWDongle_Write 00130f06600d01012502250f (deefb60e)
2016.03.04 20:56:11 5: SW: 010d00130f06600d01012502250f88
2016.03.04 20:56:11 4: ZWDongle_ReadAnswer arg:swbStatus regexp:^0004000f..60
2016.03.04 20:56:11 5: ACK received, WaitForAck=>2 for 010d00130f06600d01012502250f88
2016.03.04 20:56:11 4: ZWDongle_Read ZWAVE1: sending ACK, processing 011301
2016.03.04 20:56:11 5: SW: 06
2016.03.04 20:56:11 5: ZWAVE1 dispatch 011301
2016.03.04 20:56:11 4: ZWDongle_Read ZWAVE1: sending ACK, processing 00130f000002
2016.03.04 20:56:11 5: SW: 06
2016.03.04 20:56:11 5: device ack reveived, removing 010d00130f06600d01012502250f88 from dongle sendstack
2016.03.04 20:56:11 5: ZWAVE1 dispatch 00130f000002
2016.03.04 20:56:11 4: CMD:ZW_SEND_DATA ID:00 ARG:0002
2016.03.04 20:56:11 4: ZWAVE1 transmit OK for 0f
2016.03.04 20:56:11 4: ZWDongle_Read ZWAVE1: sending ACK, processing 0004000f07600d01012503ff
2016.03.04 20:56:11 5: SW: 06
2016.03.04 20:56:11 4: ZWDongle_ReadAnswer for swbStatus: 0004000f07600d01012503ff
2016.03.04 20:56:11 4: CMD:APPLICATION_COMMAND_HANDLER ID:0f ARG:07600d01012503ff
2016.03.04 20:56:16 2: ZWave: No ACK from cp_Device_FGS222 after 5s for sentackget:130f06600d01012502250f

Code Auswählen Erweitern

EP#2 (S1=S2=off):
2016.03.04 20:54:32 2: ZWave get cp_Light_e2 swbStatus
2016.03.04 20:54:32 5: ZWDongle_Write 00130f06600d01022502250f (deefb60e)
2016.03.04 20:54:32 5: SW: 010d00130f06600d01022502250f8b
2016.03.04 20:54:32 4: ZWDongle_ReadAnswer arg:swbStatus regexp:^0004000f..60
2016.03.04 20:54:32 5: ACK received, WaitForAck=>2 for 010d00130f06600d01022502250f8b
2016.03.04 20:54:32 4: ZWDongle_Read ZWAVE1: sending ACK, processing 011301
2016.03.04 20:54:32 5: SW: 06
2016.03.04 20:54:32 5: ZWAVE1 dispatch 011301
2016.03.04 20:54:32 4: ZWDongle_Read ZWAVE1: sending ACK, processing 00130f000002
2016.03.04 20:54:32 5: SW: 06
2016.03.04 20:54:32 5: device ack reveived, removing 010d00130f06600d01022502250f8b from dongle sendstack
2016.03.04 20:54:32 5: ZWAVE1 dispatch 00130f000002
2016.03.04 20:54:32 4: CMD:ZW_SEND_DATA ID:00 ARG:0002
2016.03.04 20:54:32 4: ZWAVE1 transmit OK for 0f
2016.03.04 20:54:32 4: ZWDongle_Read ZWAVE1: sending ACK, processing 0004000f07600d0201250300
2016.03.04 20:54:32 5: SW: 06
2016.03.04 20:54:32 4: ZWDongle_ReadAnswer for swbStatus: 0004000f07600d0201250300
2016.03.04 20:54:32 4: CMD:APPLICATION_COMMAND_HANDLER ID:0f ARG:07600d0201250300
2016.03.04 20:54:37 2: ZWave: No ACK from cp_Device_FGS222 after 5s for sentackget:130f06600d01022502250f


[krikan]

Ralf, Danke für die Logs und das Ausprobieren.

Die ungekapselten (d.h. ohne Kanalangabe durch Nutzung von CC MULTI_CHANNEL) Commands entsprechen beim FGSS den Telegrammen des Endpoints 1. Demnach ist es gleich, ob man ungekapselte Commands oder CC MULTI_CHANNEL Commands zur Steuerung von Endpoint 1 nutzt/bekommt.

Nach Lektüre von SDS komme ich zu dem Ergebnis, dass Fibaro nichts falsch macht. Die Behandlung der ungekapselten Commands ist laut zwapi den Geräte-/Firmware-Entwickler überlassen. Unter anderem ist es erlaubt, dass die Firmware zur "Vereinfachung" alle ungekapselten Commands an den (identical) Endpoint 1 weiterleitet. So macht es der FGSS. Diese Vereinfachung ist aber nur eine Variante. Der Geräteentwickler kann bei ungekapselten Commands auch andere Aktionen und/oder Antworten des Gerätes hinterlegen. So können bspw. Messwerte des ganzen Gerätes und nicht nur eines Kanals übermittelt werden, alle Kanäle an/aus ausgeschaltet werden und anderes mehr. Diese Variante der Behandlung ungekapselter Commands nutzen mMn unter anderem Greenwave Powernode 6 und Philio PAN04-1B.

FHEM macht damit mMn derzeit auch nichts falsch. Es werden alle Endpoint-Devices für CC MULTI_CHANNEL Commands und Hauptdevice für ungekapselte Commands automatisch bei der Inklusion angelegt, da FHEM nicht ermitteln kann, wie das Gerät ungekapselte Commands behandelt. Die ungekapselten Commands werden eben dem Hauptdevice und die mit CC MULTI_CHANNEL übermittelten Commands den Endpoint-Devices zugeordnet. Letztlich muss der Anwender wissen, wie sich das Gerät verhält und/oder es ggfs. ausprobieren. Dazu ist es hilfreich automatisch alle FHEM-Devices anzulegen. Sollte man ein FHEM-Device nicht benötigen, kann man es löschen. Jetzt aufgrund der Vereinfachung des FGSS generell bei allen Geräten sämtliche ungekapselten Befehle auf den Endpoint 1 umzuleiten ist mMn falsch und würde bei Powernode und PAN04 zu Fehlern/Funktionseinschränkungen/Verwirrung führen.

Lösungsansätze in FHEM, die mir einfallen:

• nichts ändern. Anwender ist verantwortlich, die Umsetzung der ungekapselten Commands bei seinem Gerät zu ermitteln und entsprechend zu handeln. Dokumentieren kann man so etwas bspw. im Wiki.
  
• evtl. Attribut zum Umleiten der ungekapselten Befehle auf FHEM-Endpoint-Device 1 einführen. Setzt aber auch aktives Anwenderhandeln voraus.
  
• keine Endpoint-Devices mehr anlegen. Für mich der komplett falsche Weg.

[rudolfkoenig]

Attribut zum Umleiten der ungekapselten Befehle auf FHEM-Endpoint-Device 1 einführen

So ein Attribut hat den Vorteil, dass es dem Benutzer eher auffaellt, und den Nachteil, dass FHEM wissen muss, welche Nachrichten bei der Endpoint-Instanz landen sollten, und welche nicht, z.Bsp. Antwort auf Config-Anfrage, verschluesselte Nachrichten, etc. Da das fuer mich nach kompliziert und fehleranfaellig klingt, bin erstmal dagegen.

da FHEM nicht ermitteln kann, wie das Gerät ungekapselte Commands behandelt.

Ich sehe zwei Moeglichkeiten: im Modul diese Eigenschaft in zwave_deviceSpecial hinterlegen, und Kanal 1 dann nicht anlegen, oder diese Besonderheit in Wiki dokumentieren, und dem Benutzer zu empfehlen, Endpoint 1 nachtraeglich zu entfernen. Beide haben ihre Vor- und Nachteile, man koennte sogar beides machen. Meinungen?

[krikan]

Mir reicht Wiki-Dokumentation. Ein wenig Anwender-Eigenverantwortung ist mMn auch OK und Du ersparst Dir Codeänderungen für einzelne Geräte.

Btw. Hattest Du die NO_ACK im Log der Endpoints gesehen? Warum die kommen verstehe ich nicht, da ACK doch vorliegt!?

[Ralf.E]

Moin,

Mir reicht Wiki-Dokumentation. Ein wenig Anwender-Eigenverantwortung ist mMn auch OK und Du ersparst Dir Codeänderungen für einzelne Geräte.

Meinungen?

Ich kann Eure Diskussion weitestgehend nachvollziehen (mein Brötchenerwerb beschäftigt sich mit der Interpretation von Standards/Protokollen im Embedded-Umfeld), möchte aber eher meine Meinung aus der Sicht eines Fhem-Anwenders seit ~3 Monaten beitragen.

Persönlich würde ich mich an der von Euch gedachten Zielgruppe von Fhem orientieren.

Z-Wave ist und war nicht unbedingt einfach zu verstehen und ich habe noch nicht komplett herausgefunden wann z.B. Multi-Channel-Associations erforderlich oder hilfreich sind. Was ist der Unterschied von reportedState und state? D.h. Dokumentation von bestimmten Geräte-Eigenarten ist schon mal sehr hilfreich.

Am Beispiel des FGS-222: wenn Haupt-Device und die Endpoints automatisch angelegt werden (ein kurzes warum könnte helfen erneute Diskussionen zu vermeiden), sollte nur deutlich werden, dass EP#1 nur steuernd verwendet werden kann und dessen Status im Haupt-Device zu finden ist. Wer EP#1 nicht braucht löscht das Fhem-Device dazu und betrachtet das Haupt-Device dann als EP#1.

Doch noch eine Meinung aus Entwicklersicht: Zumindest in meiner Branche ist es nicht ungewöhnlich, dass Geräte Standards/Protokolle unterschiedlich implementieren und Geräte spezifische Behandlung erfordern. Manchmal ist das sinnvoll einzubauen und manchmal richtig Mist.

BTW: Benötigt Ihr noch weitere Tests? Ich würde den FGS sonst wieder seiner Besimmung zuführen...

Gruß Ralf