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

[krikan]

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

Nein, für mich keine Tests mehr notwendig. Danke für Deine Unterstützung.
Btw. bin definitiv kein Entwickler, sondern nur Anwender und erlaube mir daher die von Dir zitierte Aussage  .
Gruß, Christian

[rudolfkoenig]

Btw. Hattest Du die NO_ACK im Log der Endpoints gesehen?

Nope, uebersehen, danke fuer den Hinweis

Warum die kommen verstehe ich nicht, da ACK doch vorliegt!?

Ist eine nette Demonstration des hier diskutierten Problems:
- im SendStack landet ein get an EP#1.
- damit es mit dem naechsten Befehl aus dem Stack weitergeht (bzw. dieses Befehl vom Stack entfernt wird), muss erst ein 0113 (Stick hat Befehl versendet), ein 0013xx00 (Zielgeraet hat Befehl bekommen) und zum Schluss eine Antwort auf die Frage (get) vom _Empfaenger_ eintreffen.
- hier kam zwar alles, allerdings war die Antwort nicht vom EP#1, sondern vom "Vater"-Instanz, und dass das in diesem Fall das Gleiche ist, hat FHEM nicht geschnallt.

[sandembo]

dieses Problem tritt bei mir erst regelmässig auf, seit ich gestern ein fhem update gemacht habe.
das genannte device frage ich alle 10min ab:
/opt/fhem/log/fhem-2016-06.log:2016.06.19 12:20:05 2: ZWave: No ACK from DIELE.Treppenlicht after 5s for sentackget:xxx022593
/opt/fhem/log/fhem-2016-06.log:2016.06.19 12:30:05 2: ZWave: No ACK from DIELE.Treppenlicht after 5s for sentackget:xxx022594
/opt/fhem/log/fhem-2016-06.log:2016.06.19 12:40:05 2: ZWave: No ACK from DIELE.Treppenlicht after 5s for sentackget:xxx022596
/opt/fhem/log/fhem-2016-06.log:2016.06.19 12:50:05 2: ZWave: No ACK from DIELE.Treppenlicht after 5s for sentackget:xxx022598
/opt/fhem/log/fhem-2016-06.log:2016.06.19 13:00:05 2: ZWave: No ACK from DIELE.Treppenlicht after 5s for sentackget:xxx02259a
/opt/fhem/log/fhem-2016-06.log:2016.06.19 13:10:05 2: ZWave: No ACK from DIELE.Treppenlicht after 5s for sentackget:xxx02259c
/opt/fhem/log/fhem-2016-06.log:2016.06.19 13:20:05 2: ZWave: No ACK from DIELE.Treppenlicht after 5s for sentackget:xxx02259f
/opt/fhem/log/fhem-2016-06.log:2016.06.19 13:30:05 2: ZWave: No ACK from DIELE.Treppenlicht after 5s for sentackget:xxx0225a1

root@rpiplus:/opt/fhem# ls  restoreDir/
2015-11-22  2016-01-20  2016-06-19

dieses Problem trat mit der Version, die ich vorher hatte (am 20.1.16 eingespielt) nicht auf.

==> ./restoreDir/2016-06-19/FHEM/10_ZWave.pm <==
##############################################
# $Id: 10_ZWave.pm 10509 2016-01-15 08:55:51Z rudolfkoenig $

Vielleicht hilft diese Info ja, um den Fehler einzugrenzen ...

[rudolfkoenig]

Siehe https://forum.fhem.de/index.php?topic=54555

[sandembo]

danke!

bei der Gelegenheit ist mir aufgefallen, dass diese hier loglevel 2 sind - sollten sie nicht 3 sein?
2016.06.19 14:30:00 2: ZWave get DIELE.Deckenlicht swbStatus
2016.06.19 14:30:00 2: ZWave get DIELE.Treppenlicht swbStatus
2016.06.19 14:39:21 2: ZWave set DIELE.Deckenlicht on
2016.06.19 14:39:37 2: ZWave set DIELE.Deckenlicht off
2016.06.19 14:40:00 2: ZWave get DIELE.Deckenlicht swbStatus
2016.06.19 14:40:00 2: ZWave get DIELE.Treppenlicht swbStatus

verbose:
2 Meldungen über die wichtigsten Ereignisse oder Alarme
3 gesendete Befehle werden protokolliert

[rudolfkoenig]

Stimmt, habs geaendert.

[gamauf]

Hallo!

Habe erst gestern entdeckt, daß bei direktem Schalten des ersten Kanals (FIBARO System FGS222 Double Relay Switch 2x1.5kW) sich der Status des Haupt-Device ändert statt dem des Endpoint 1.

Wenn ich das hir in Thread richtig verstanden hab' ist die Lösung statt des Endpoint 1 zum schalten des ersten Kanals das Haupt-Device zu verwenden. Richtig?

Ich konfiguriere also den Bewegungsmelder so um, daß er jetzt nicht mehr Endpoint 1 sondern das Haupt-Device schaltet, dann ist die Anzeige im FHEM wieder konsistent, heißt egal ob der kanal vom lokalen Schalter, oder via FHEM geschaltet wird es ist immer der Status vom selben (Haupt-)Device der sich ändert.
Paßt!

Danke!
Rainer

[rudolfkoenig]

Wenn ich das hir in Thread richtig verstanden hab' ist die Lösung statt des Endpoint 1 zum schalten des ersten Kanals das Haupt-Device zu verwenden.

Das war jedenfalls meine Absicht. Endpoint 1 sollte gar nicht angelegt werden.

[krikan]

Habe erst gestern entdeckt, daß bei direktem Schalten des ersten Kanals (FIBARO System FGS222 Double Relay Switch 2x1.5kW) sich der Status des Haupt-Device ändert statt dem des Endpoint 1.

Wenn ich das hir in Thread richtig verstanden hab' ist die Lösung statt des Endpoint 1 zum schalten des ersten Kanals das Haupt-Device zu verwenden. Richtig?

Ja. Netter "Reklameaufhänger" : Zusammengefasst stehen die Erkenntnisse zum FGS222  hinsichtlich der Endpoints/Devices seit längerem in unserem Wiki unter http://www.fhemwiki.de/wiki/Z-Wave#FGS-222_Relais_Unterputzeinsatz.
Gruß, Christian

PS: Wenn dort etwas fehlt/unverständlich ist, bitte bei mir beschweren. Aktive Wiki-Schreiber können das gerne selbst ergänzen und sind gesucht...

[gamauf]

Danke für den Hinweis aufs Wiki; ist mir bisher nicht aufgefallen, daß dort der FGS222 erwähnt ist!

LG
Rainer

[FunkOdyssey]

Wenn ich in FHEM den Endpoint 1 einschalte, so wird dies nicht autom. im Hauptdevice angezeigt.
Ich muss manuell ein "get xyt swbStatus" hinterherschicken, um den gleichen Zustand zu erkennen.
Eine (ich nenne es mal) "Synchronisation" zwischen Hauptdevice und EP1 gibt es nicht, oder?

(Ich schalte nur über FHEM - nicht über angeschlossene Schalter)

[krikan]

Wenn ich in FHEM den Endpoint 1 einschalte, so wird dies nicht autom. im Hauptdevice angezeigt.
Ich muss manuell ein "get xyt swbStatus" hinterherschicken, um den gleichen Zustand zu erkennen.
Eine (ich nenne es mal) "Synchronisation" zwischen Hauptdevice und EP1 gibt es nicht, oder?

Nein, weil die Funktion von Haupt- und Endpointdevice geräteabhängig ist (mehr steht oben im Thread).

[A.Harrenberg]

Hi Rudi, hi Christian,

ich habe auch noch mal eine Frage bzgl. MultiChannel bzw. MultiChannel_Association...

Ich habe mit dem Z-Uno ein Gerät mit drei Kanälen "gebaut":
Channel 1: Switch_Mulitlevel "Dimmer"
Channel 2: Sensor_Multilevel "Temperature"
Channel 3: Sensor_Multilevel "Humidity"

Die normale Association für Lifeline habe ich gelöscht und ein mca eingerichtet (es gibt nur eine Gruppe).

Wenn ich nun vom Z-Uno aus die Reports verschicke erhalte ich 5! Nachrichten, eine von jedem Endpoint, Channel 1+2 jedoch auch noch mal von Endpoint 0. (Warum da überhaupt was von 0 gesendet wird und wieso dann nicht auch für den dritten Kanal diskutiere ich gerade mit dem Entwickler...)

Die Nachrichten sehen so aus:

Code Auswählen Erweitern

07600d 01 01 260300
07600d 00 01 260300
0a600d 02 01 3105012200e6
0a600d 00 01 3105012200e6
0a600d 03 01 3105052201cc

Was mich nun wundert ist das die beiden Nachrichten vom root-device im Endpoint 1 landen und nicht im root device. D.h. ich habe aktuell keine Readings im root-device, dafür aber State und Temperatur in Endpoint 1.

Ich hatte diese Diskussion hier eigentlich so verstanden das nur ungekapselte Nachrichten an Endpoint 1 weitergeleitet werden, gekapselte aber schon an den "richtigen" Endpoint gelangen. Nach der Logik würde ich erwarten das jeder Endpoint seinen Report bekommt und das Root-Device zusätzlich die beiden Nachrichten mit Endpoint 0.

So ganz habe ich die Logik hinter der Multichannel Association aber auch noch nicht verstanden...

Würde etwas dagegensprechen Nachrichten die Endpoint 0 haben an das root-device zu senden?

@Rudi: Die Devices haben in Ihrem hash doch sicherlich die Information der Eltern-/Kind Beziehung enthalten, oder? Wäre es möglich in den Internals beim root die Kinder aufzulisten (und als Link zur Verfügung zu haben), ebenso bei den Kindern das root device?

Gruß,
Andreas.

[rudolfkoenig]

Bin etwas verwirrt (oder einfach vergesslich?): wo ist das Unterschied zwischen Channel und Endpoint?

Ich war bisher der Ansicht, dass FHEM Endpoint 1 dem Root-Device zuordnet, das ist (nach Code-Check) aber nicht der Fall. Allerdings meldet mein Zwei-Kanal Sensor EZMotion 3-in-1 die Bewegungen per Root-Device (ohne MULTI_CHANNEL Encapsulation), die anderen Daten (Lich und Temperatur) per Endpoint 2 und 3. Endpoint 1 wird bei diesem Geraet nicht verwendet.

Die Zuordnung deiner Nachrichten in FHEM versteht man mit den folgenden Zeilen besser:

Code Auswählen Erweitern

  if($arg =~ /^..600d(..)(..)(.*)/) { # MULTI_CHANNEL CMD_ENCAP, V2
    $ep = ($1 ne "00" ? $1 : $2);

Warum ich das so gemacht habe, weiss ich allerdings nicht mehr.
Danach landen deine Nachrichten #1,#2 und #3 beim Geraet Endpoint 1.

Nach der Logik würde ich erwarten das jeder Endpoint seinen Report bekommt und das Root-Device zusätzlich die beiden Nachrichten mit Endpoint 0.

Verstehe deine Theorie richtig: $1 bedeutet: "melde es an $1", und $2 "verursacht von $2". Wenn ja, dann koennen wir zwar das implementieren, "verursacht von" waere aber zunaechst von FHEM ignoriert. Bin nicht sicher, dass ein Umbau ohne Nebenwirkungen bei anderen Geraeten ist.

Die Devices haben in Ihrem hash doch sicherlich die Information der Eltern-/Kind Beziehung enthalten, oder?

Bisher nur indirekt ueber nodeIdHex. Habe jetzt die Namen unter endpointChildren/endpointRoot eingetragen.

[A.Harrenberg]

Hi Rudi,

Bin etwas verwirrt (oder einfach vergesslich?): wo ist das Unterschied zwischen Channel und Endpoint?

denke das Channel = Endpoint sein sollte... Beim Z-Uno legt man "Channels" an, daher hatte ich das so beschrieben. Aber mit dem ganzen MultiChannel hatte ich bisher nie was zu tun, meine bisherigen Geräte hatten sowas nie... Allerding habe ich jetzt auch noch 2 Wandtaster die das natürlich auch haben, damit habe ich aber noch nicht "gespielt"...

Ich war bisher der Ansicht, dass FHEM Endpoint 1 dem Root-Device zuordnet, das ist (nach Code-Check) aber nicht der Fall. Allerdings meldet mein Zwei-Kanal Sensor EZMotion 3-in-1 die Bewegungen per Root-Device (ohne MULTI_CHANNEL Encapsulation), die anderen Daten (Lich und Temperatur) per Endpoint 2 und 3. Endpoint 1 wird bei diesem Geraet nicht verwendet.

Ich habe mir die Spezifikation und den Code noch nicht so genau angesehen, aber so wie ich das bisher (auch vom Z-Uno) verstanden haben muss Endpoint 1 dem Root Device zugeordnet sein. Wenn Dein EZMotion Endpoint 1 gar nicht nutzt mag das evtl. sogar konform sein, das kann ich aber momentan noch nicht sagen.

Die Zuordnung deiner Nachrichten in FHEM versteht man mit den folgenden Zeilen besser:

Code Auswählen Erweitern

  if($arg =~ /^..600d(..)(..)(.*)/) { # MULTI_CHANNEL CMD_ENCAP, V2
    $ep = ($1 ne "00" ? $1 : $2);

Warum ich das so gemacht habe, weiss ich allerdings nicht mehr.
Danach landen deine Nachrichten #1,#2 und #3 beim Geraet Endpoint 1.

Die Zeile hatte ich mittlerweile auch gefunden, den Grund dafür kann ich Dir aber auch nicht sagen ,-)
Ich denke Du meinst hier aber #1, #2 und #4, oder?

Verstehe deine Theorie richtig: $1 bedeutet: "melde es an $1", und $2 "verursacht von $2". Wenn ja, dann koennen wir zwar das implementieren, "verursacht von" waere aber zunaechst von FHEM ignoriert. Bin nicht sicher, dass ein Umbau ohne Nebenwirkungen bei anderen Geraeten ist.

Jetzt bin ich verwirrt... Habe gerade kurz in die Spec geschaut, $1 ist als "source end point" und $2 als "destination end point" deklariert. Umbauen solltest wir erst mal nichts bis das etwas näher analysiert ist. Und wahrscheinlich hat Christian da auch noch was beizusteuern, er hat das glaube ich ziemlich gut verstanden was da abgeht.
Bei $1 würde ich Dir zustimmen, wobei dann 0=root Device ist. $2 würde ich mir noch mal anschauen, das hängt vielleicht damit zusammen wie man die mca macht?? Das habe ich bisher auch noch nicht so ganz verstanden.

Bisher nur indirekt ueber nodeIdHex. Habe jetzt die Namen unter endpointChildren/endpointRoot eingetragen.

Danke, schaue ich mir gleich mal an!

Gruß,
Andreas.

[A.Harrenberg]

Hi Rudi,

Bisher nur indirekt ueber nodeIdHex. Habe jetzt die Namen unter endpointChildren/endpointRoot eingetragen.

Einträge sind da, der Eintrag "endpointRoot" ist anklickbar und man landet beim rootdevice, die Einträge "endpointChildren" lassen sich aber nicht anklicken... Wäre es möglich hier auch noch die links zu erzeugen?

Gruß,
Andreas.

[A.Harrenberg]

Hi Rudi,

nach einer ersten Lektüre der MultiChannel Spezifikation bin ich jetzt auch noch nicht viel schlauer, da sind so einige "MAY" und "SHOULD" drin...

Ich habe aber die MultiChannel Assoziation mal neu erstellt und nur 1:0 als Ziel angegeben (set mcaAdd 10 1 0), und keine normale Lifeline Assoziation mehr gemacht. Dadurch bekomme ich jetzt jeden Endpoint in der multichannel Kapselung wie vorher auch, die beiden anderen Messages werden jetzt aber ungekapselt an das root-Device geschickt. Man kann das also durch entsprechende Konfiguration irgendwie hinbekommen...

Trotzdem können solche Nachrichten ja ankommen und bei "0" sollte das root device gemeint sein. Ob das dann auch für endpoint 1 "dupliziert"  werden muss kann ich momentan nicht sagen, würde es aber erwarten.

Gruß,
Andreas.

[rudolfkoenig]

Habe endpointRoot in endpointParent umbenannt, und endpointChildren sind jetzt anklickbar in FHEMWEB
Merke: Trenner fuer solche Listen ist Komma und nicht Leerzeichen.

Wenn ich dich richtig verstehe, bist fuer $1=0: endpointParent, sonst: endpointChild.
Da das eine Aenderung bei notifies/logs der Leute bedeuten kann, wuerde ich gerne noch die Meinung von Christian hoeren.

[A.Harrenberg]

Hi Rudi,

Habe endpointRoot in endpointParent umbenannt, und endpointChildren sind jetzt anklickbar in FHEMWEB
Merke: Trenner fuer solche Listen ist Komma und nicht Leerzeichen.

Danke, werde ich mir gleich mal ansehen

Wenn ich dich richtig verstehe, bist fuer $1=0: endpointParent, sonst: endpointChild.
Da das eine Aenderung bei notifies/logs der Leute bedeuten kann, wuerde ich gerne noch die Meinung von Christian hoeren.

Tendenziell wäre das meine Meinung, ich bin aber auch dafür das noch mal in aller Ruhe zu überlegen und abzuwägen. Ich habe wie gesagt mit dem ganzen Multichannel nichts zu tun gehabt und kann die Folgen von einer Änderungen momentan noch nicht mal ansatzweise abschätzen. Außerdem kommen diese Nachrichten mit $1=0 nicht wenn man die mca "vernünftig" konfiguriert.

Ich denke das hier Christian den besten Überblick hat und am ehesten die Folgen abschätzen kann. Da das Thema nicht dringend ist kann das ja in Ruhe überlegt werden.

Gruß,
Andreas.

[krikan]

Ich denke das hier Christian den besten Überblick hat und am ehesten die Folgen abschätzen kann.

(Leider) zuviel der Ehre. Ich habe ein wenig Probleme Euch zu folgen. Anhand meiner Geraete erkenne ich keinen Fehler/Problem in FHEM und würde erst einmal ungerne Anpassungen befürworten, wenn es nur auf dem uno basiert. Schaue aber auch noch mal in die zwapi und krame in meiner Erinnerung...

Was ich nicht begriffen habe: Existiert das Problem beim uno nur im Zusammenspiel von MultiChannel und MultiChannel_Association oder auch bei MultiChannel alleine?

[A.Harrenberg]

Hi Christian,

also das "Basisproblem" ist das ZWave+ anscheinend zwingend fordert (was aber anscheinend einige Hersteller wieder ignorieren...) das bei Multichannel der Kanal 0 auf das Root-Device gemappt werden soll. Wenn man nun die Associations nun so setzt das man da das Root-Device angibt (ohne Multi-Channel Definition) dann sendet der Zuno Multichannel Nachrichten die von "0" kommen, diese werden in FHEM aber dem ersten Kanal zugeordnet und landen eben nicht im Root-Device, was eigentlich logischer wäre.

Ich habe beim Z-Uno nun die normale Assoziation gelöscht und nur eine MultiChannel-Assoziation gemacht und erhalte dadurch jetzt nur Nachrichten von den einzelnen Kanälen und keine mehr vom Rootdevice.

Ich denke aber das immer mehr Geräte das gleiche Verhalten zeigen werden und es eigentlich logischer ist das alles was vom Rootdevice kommt auch bei FHEM im Rootdevice landet.

Ich werde noch mal eine Versuchsreihe machen bei welchen Kombinationen diese Nachrichten vom Rootdevice ausgelöst werden und bei welchen nicht. Sooo genau kann ich das jetzt auch nicht mehr sagen. Und das Thema ist alles andere als dringend...

Gruß,
Andreas.

[krikan]

also das "Basisproblem" ist das ZWave+ anscheinend zwingend fordert (was aber anscheinend einige Hersteller wieder ignorieren...) das bei Multichannel der Kanal 0 auf das Root-Device gemappt werden soll.

Hallo Andreas,
hast Du das aus den zwapi oder ist das Auskunft von zwave.me?
Gruß, Christian

[A.Harrenberg]

Hi,

das ist Auskunft von Zwave.me
Der Typ dort scheint recht fit zu sein.

Gruß,
Andreas.

[krikan]

Ok, kann es dann einordnen. (https://github.com/PoltoS ?)

[A.Harrenberg]

Hi Christian,

ja, das ist er.

Gruß,
Andreas.

[krikan]

Wenn ich dich richtig verstehe, bist fuer $1=0: endpointParent, sonst: endpointChild.

Habe mir das Thema iZm https://forum.fhem.de/index.php/topic,59026.msg521515.html#msg521515 noch einmal angesehen und bin der Meinung, dass 0 für endpointParent ist.

Diese Codestelle stimmt mMn nicht mit zwapi überein und ich verstehe den Grund nicht:

Code Auswählen Erweitern

$ep = ($1 ne "00" ? $1 : $2);

Nach zwapi:
$1 gibt immer den SourceEndpoint und $2 gibt immer den DestinationEndpoint an, wobei  $1= 0: endpointParent, $1>0: endpointChild bzw. $2= 0: endpointParent, $2>0: endpointChild

$2 ist beim Empfang durch den Controller unerheblich, weil der Controller keine eigenen Endpoints hat.

Da laut zwapi gilt

If a sending device does not implement Multi Channel End Points or if the Root Device of the Multi Channel device is originating a command, the Source End Point MUST be set to 0.

schließe ich für den Versand von MULTICHANNEL-Nachrichten durch den Controller, dass

Code Auswählen Erweitern

$cmdFmt = "0d01$ch$cmdId$cmdFmt";
durch

Code Auswählen Erweitern

$cmdFmt = "0d00$ch$cmdId$cmdFmt";
ersetzt werden sollte.

Ganz sauber ist das so auch noch nicht, da $1 und $2 noch besondere Bits beinhalten.

Problem: Folgen kann ich nicht alle überblicken. Insbesondere befürchte ich Seiteneffekte auf MULTICHANNEL_ASSOCIATION und enormen Aenderungsbedarf bei den notifies/DOIFs...

[rudolfkoenig]

Danke fuer die gruendliche Erklaerung.

Diese Codestelle stimmt mMn nicht mit zwapi überein und ich verstehe den Grund nicht:

Grund: ich wusste es nicht besser. Ich habe zwei Telegramme gehabt mit erwarteten Sinn, und musste daraus was basteln.

Sonst bin etwas verwirrt: die vorgeschlagene Aenderung sollte doch keine Aenderung auf Notifies haben, hoechstens auf die Reaktion der Empfaenger, aber selbst das sehe ich nicht (dem zu schaltenden Kanal sollte egal sein, ob das Befehl vom Parent oder Endpoint 1 kommt). Was mAn gefixt werden muss, ist die erste Codestelle, in $ep=$2, was Auswirkung auf notifies haben kann. Das koennen wir loesen, indem wir ein Attribut einfuehren, oder davor warnen. Bin fuer Letzteres.

[krikan]

Änderungsbedarf sehe ich derzeit theoretisch bei beiden Codestellen.
Korrekt: Die notify-Thematik sollte "nur" die 1. Codestelle ("$ep = ($1 ne "00" ? $1 : $2);") betreffen, deren Entstehung ich nicht verstand.

Ich würde gerne noch ein wenig lesen (dynamische Endpoints,..) und testen, bevor Codeänderungen eingebaut werden. Für mich ist das noch zu unklar. Es sei denn Du/Ihr seid schon sicher oder wir gehen Risiko der mehrfachen Änderung ein.

Das koennen wir loesen, indem wir ein Attribut einfuehren, oder davor warnen. Bin fuer Letzteres.

Ebenso.

Btw.
Bin bei dem Thema wegen sehr langer und kaputter Nachrichten auf CRC-16 und die Reihenfolge der Encapsulation "http://zwavepublic.com/sites/default/files/SDS12657-12%20-%20Z-Wave%20Command%20Class%20Specification%20A-M.pdf S.21ff.  aufmerksam geworden.

[rudolfkoenig]

Ich würde gerne noch ein wenig lesen...

Nur zu, melde Dich dann.

Und danke fuer den Hinweis auf die Tabelle.
Weisst Du, was da mit "Transport Service" gemeint ist?

[krikan]

Weisst Du, was da mit "Transport Service" gemeint ist?

Steht wohl für Transport Service Command Class (Übermittlung von Nachrichten größer als der ZWave-Frame)
http://zwavepublic.com/sites/default/files/SDS12652-13%20-%20Z-Wave%20Command%20Class%20Specification%20N-Z.pdf S. 330
Habe die Command Class noch nicht in Geräten wahrgenommen. Da pepper1 momentan nicht erreichbar ist, kann ich auch nicht nachsehen, ob es schon Geräte gibt. Bei der Alliance kann ich nicht nach CC suchen.

[krikan]

Also meiner Meinung nach (unter Berücksichtigung auch von Geräten mit dynamischen Endpoints) zu ändern:

Code Auswählen Erweitern

$cmdFmt = "0d01$ch$cmdId$cmdFmt";
ersetzen durch

Code Auswählen Erweitern

$cmdFmt = "0d00$ch$cmdId$cmdFmt";
$ch sollte im Bit 7 nie 1 sein, da damit nicht ein einzelner Endpoint 0-127, sondern über eine Bitmaske die gleichzeitige Abfrage mehrerer Endpoints 1-7 ohne Antwortpflicht des Gerätes angesprochen wird.

Beispiel:
Bei meinem einzigen Gerät mit dynamischen Endpoints wird derzeit für den Endpoint 3 die Nachricht mit $ch=83 verschickt (= gleichzeitige Abfrage Endpoints 1 und 2) und das Gerät antwortet teilweise zwapi-konform nicht und FHEM meldet timeout bzw. antwortet auf den Endpoints 1 und 2. Setze ich das richtig auf $ch=03 (=Abfrage Endpoint 3), dann antwortet wie erwartet der Endpoint 3.

Code Auswählen Erweitern

$ep = ($1 ne "00" ? $1 : $2);
ersetzen durch

Code Auswählen Erweitern

$ep=$1
$2 ist der Destination-Endpoint und der sollte für den Controller/FHEM immer uninteressant sein. Mir fällt zumindest kein gegenteiliger Fall ein.
Bit 7 in $ep darf nie als 1 übernommen werden, da die Zuordnung des Endpoints bei dynamischen Endpoints erschwert wird. Passt zu zwapi, wonach Bit 7 ein reservierter Wert ist, der ignoriert werden soll.

Bit 7 bei MULTI_CHANNEL-Nachrichten führt zum anderen Problem der "falschen" Anlage von dynamischen Endpoint-Devices für meinen Test-Aktor durch FHEM:
FHEM legt per autocreate automatisch den dynamischen Endpoint 3 als  "ZWave_.*.131" mit entsprechendem DEF an. Damit die Zuordnung der Nachrichten zu den Endpoints passt, sollte mMn das Bit7, das einen dynamischen Endpoint signalisiert, durch autocreate ignoriert werden und das Device als "ZWave_.*.3" mit entsprechendem DEF angelegt werden. Wenn das gemacht würde, ist nach meinem Gedankengang die Bit7-Problematik in der 1. Codeänderung $ch automatisch hinfällig.

Hoffe, dass ist verständlich.

Bei meinem Test-Gerät mit einem dyn. Endpoint reichen die vorgeschlagenen Änderungen in FHEM aus. Problematisch wird es bei Geräten, die mehrere dynamische Endpoints haben und die Nummer des Endpoints sich nach Entfernen und neuem Hinzufügen automatisch ändern kann. In diesen Fällen müssten wohl FHEM-Devices bei der Entfernen-Funknachricht automatisch gelöscht werden. Das müsste man derzeit über notify/DOIF lösen. Praktische Relevanz=?

[krikan]

@Rudi: Achtung, habe im letzten Post editiert, da ich mMn destination und source verdreht hatte.

[rudolfkoenig]

Habs geaendert, die Erste genau, wie du es vorgeschlagen hast, die Zweite ist:

Code Auswählen Erweitern

$ep = sprintf("%02x", hex($1) & 0x7f); # Forum #50176
damit Bit-7 ignoriert wird.

Kann leider nicht einchecken, sourceforge bockt.

[krikan]

Code Auswählen Erweitern

$ep = sprintf("%02x", hex($1) & 0x7f); # Forum #50176


Danke. Dann hätte ich Dir auch meinen Patch geben können; habe das genauso gemacht. Jedoch dachte ich die sprintf/hex-Variante ist viel zu umständlich und es gibt etwas viel kürzeres für die simple Bitoperation, das ich nur nicht finde.

Kannst/Hast Du auch in ZWave_mcCapability($$) $chid analog angepasst, damit autocreate die korrekte Endpoint-Nummer für DEF und Device-Name bekommt?

[rudolfkoenig]

Habs jetzt eingecheckt,  ZWave_mcCapability auch geaendert, danke fuer den Hinweis.

[krikan]

Danke zurück. Laeuft. 

[scooty]

Hallo zusammen,

ich hoffe, hier bin ich richtig, da hier wohl die letzte Änderung der 10_ZWave.pm besprochen wird.

Mit der neuesten Version von 10_Zwave.pm funktioniert mein ZWave.me WALLC-S Wandschalter nicht mehr.
Bei Tastendruck werden nur im Hauptdevice Events á la

Code Auswählen Erweitern

basicSet 255
bzw.

Code Auswählen Erweitern

basicSet 0
(oder entsprechende swmBegin../swmEnd) erzeugt.
Bei den endpointChildren erscheinen keine Events mehr.

Habe jetzt nicht wirklich die in diesem Thread beschriebenen Änderungen verstanden, aber mit der Vorversion

Code Auswählen Erweitern

10_ZWave.pm 12583 2016-11-15 14:46:43Z rudolfkoenig
werden die Events in den endpointChildren erzeugt.

Muss ich ggf. etwas umstellen (oder gerne noch weitere Infos liefern)?

Viele Grüße ,
Andreas

[krikan]

Hallo Andreas!
Denke Du bist richtig. 
Hast Du über MULTI_CHANNEL_ASSOCIATION assoziiert (das habe ich naemlich nicht analysiert)?
Kannst Du bitte die raw-Logs (verbose 5) der betroffenen Nachrichten mit Erlaeuterung der Tastendruecke zeigen?
Würde es mir dann anschauen. Danke.
Gruß, Christian

edit: Zur Sicherheit bitte auch Ausgaben von "list <device>"

[scooty]

Hallo Christian,

danke für die schnelle Reaktion.
Ja, meinem Verständnis nach ist der ZWave.me WALLC-Süber MULTI_CHANNEL_ASSOCIATION assoziiert (parent und child-Nodes sind angelegt).

Hier erst einmal das list des endpointParent-Devices:

Code Auswählen Erweitern

Internals:
   DEF        d79c8805 46
   IODev      ZW_Dongle
   LASTInputDev ZW_Dongle
   MSGCNT     8
   NAME       WZOG_ZB
   NR         418
   STATE      OK
   TYPE       ZWave
   ZW_Dongle_MSGCNT 8
   ZW_Dongle_RAWMSG 0004002e03800364
   ZW_Dongle_TIME 2016-11-19 09:11:54
   ZWaveSubDevice no
   endpointChildren WZOG_ZB_Links,WZOG_ZB_Rechts,WZOG_ZB_LinksDoppel,WZOG_ZB_RechtsDoppel
   homeId     d79c8805
   isWakeUp   1
   lastMsgSent 1479543116.37936
   nodeIdHex  2e
   Readings:
     2016-11-19 09:11:54   CMD             ZW_APPLICATION_UPDATE
     2016-01-02 10:34:18   assocGroup_1    Max 10 Nodes ZW_Dongle
     2016-01-02 10:34:18   assocGroup_2    Max 10 Nodes
     2016-01-02 10:34:19   assocGroup_3    Max 10 Nodes
     2016-01-02 10:34:19   assocGroup_4    Max 10 Nodes
     2016-01-02 10:34:19   assocGroup_5    Max 10 Nodes
     2016-01-02 10:34:18   assocGroups     5
     2016-11-19 08:42:56   basicSet        255
     2016-11-19 09:11:54   battery         100 %
     2016-11-19 08:32:15   configBlocksWakeupEvenWhenWakeup25 WakeupIsPossibleIfConfigured1
     2016-11-19 08:32:16   configButton1And3PairMode InPairWithDoubleClicks
     2016-11-19 08:32:16   configButton2And4PairMode InPairWithDoubleClicks
     2016-11-19 08:32:17   configCommandToControlGroupA SwitchOnOffAndDimSendBasicSetAnd1
     2016-11-19 08:32:17   configCommandToControlGroupB SwitchOnOffAndDimSendBasicSetAnd1
     2016-11-19 08:32:17   configCommandToControlGroupC SwitchOnOffAndDimSendBasicSetAnd1
     2016-11-19 08:32:17   configCommandToControlGroupD SwitchOnOffAndDimSendBasicSetAnd1
     2016-11-19 08:32:17   configInvertButtons NoDefault
     2016-01-02 09:56:39   configLEDConfirmationMode NoConfirmations
     2016-01-02 09:56:39   configModesForButton2And4 InPairWithDoubleClicks
     2016-11-19 08:32:17   configSendTheFollowingSwitchAll21 SwitchOffOnlyDefault
     2016-11-19 08:32:17   configSendUnsolicitedBatteryReportOn30 ToSameNodeAsWakeUpNotification1
     2016-01-02 10:04:10   configTypicalClickTimeout 0
     2016-01-02 10:44:42   mcaSupportedGroupings 5
     2015-11-18 21:41:26   mca_02          max:0a param:00000101
     2016-01-02 10:46:43   mca_03          max:0a param:00000102
     2016-01-02 10:47:06   mca_04          max:0a param:00000103
     2016-01-02 10:47:32   mca_05          max:0a param:00000104
     2016-01-02 10:06:04   model           Z-Wave.Me ZME_WALLC-S Secure Wall Controller
     2016-01-02 10:06:04   modelConfig     zwave.me/ZME_WALLC-S.xml
     2016-01-02 10:06:04   modelId         0115-0100-0101
     2016-08-18 12:30:07   neighborList    empty
     2016-11-19 08:17:08   reportedState   swmEnd
     2016-11-19 08:17:08   state           swmEnd
     2016-11-19 09:11:56   timeToAck       0.088
     2016-11-19 09:11:56   transmit        OK
     2016-11-19 09:11:54   wakeup          notification
     2016-11-19 08:36:52   wakeupReport    interval 86400 target 1
Attributes:
   IODev      ZW_Dongle
   classes    ZWAVEPLUS_INFO MULTI_CMD POWERLEVEL SECURITY VERSION MANUFACTURER_SPECIFIC CONFIGURATION ASSOCIATION SCENE_CONTROLLER_CONF MULTI_CHANNEL_ASSOCIATION BATTERY WAKE_UP DEVICE_RESET_LOCALLY ASSOCIATION_GRP_INFO CENTRAL_SCENE MARK BASIC CENTRAL_SCENE SWITCH_MULTILEVEL SWITCH_ALL SCENE_ACTIVATION MULTI_CHANNEL
   group      OG
   icon       taster_ch_v@green
   neighborListPos 755.6488364949042,1274.1900342896101
   room       WZOG,ZWave
   stateFormat transmit
   webCmd     :
list des endpointParent-Devices:

Code Auswählen Erweitern

Internals:
   DEF        d79c8805 11777
   IODev      ZW_Dongle
   LASTInputDev ZW_Dongle
   MSGCNT     19
   NAME       WZOG_ZB_Links
   NR         419
   STATE      0
   TYPE       ZWave
   ZW_Dongle_MSGCNT 19
   ZW_Dongle_RAWMSG 0004002e06600d00012605
   ZW_Dongle_TIME 2016-11-19 10:54:32
   ZWaveSubDevice yes
   endpointParent WZOG_ZB
   homeId     d79c8805
   isWakeUp
   nodeIdHex  2e01
   Readings:
     2016-11-19 10:54:16   basicSet        0
     2016-11-19 10:54:32   reportedState   swmEnd
     2016-11-19 10:54:32   state           swmEnd
Attributes:
   IODev      ZW_Dongle
   eventMap   basicSet..255:UpShort basicSet..0:DownShort swmBeginUp:UpLong swmBeginDown:DownLong swmEnd:StopLong
   group      OG
   room       WZOG,ZWave
   stateFormat basicSet
Nun ein verbose 5 Log (mit 10_ZWave.pm 12583 2016-11-15 14:46:43):
Tastenabfolge (na ja, so ungefähr):
Linker Taster einfach hoch / 5 sec warten /
Linker Taster einfach runter / 5 sec warten /
Linker Taster lang hoch (2 sec) / 5 sec warten /
Linker Taster lang runter (2 sec) / 5 sec warten

Code Auswählen Erweitern

2016.11.19 11:02:31.639 4: ZWDongle_Read ZW_Dongle: rcvd 0004002e07600d00012001ff (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.19 11:02:31.640 5: SW: 06
2016.11.19 11:02:31.642 5: ZW_Dongle dispatch 0004002e07600d00012001ff
2016.11.19 11:02:31.644 4: CMD:APPLICATION_COMMAND_HANDLER ID:2e ARG:07600d00012001ff CB:00
2016.11.19 11:02:39.536 4: ZWDongle_Read ZW_Dongle: rcvd 0004002e07600d0001200100 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.19 11:02:39.537 5: SW: 06
2016.11.19 11:02:39.539 5: ZW_Dongle dispatch 0004002e07600d0001200100
2016.11.19 11:02:39.540 4: CMD:APPLICATION_COMMAND_HANDLER ID:2e ARG:07600d0001200100 CB:00
2016.11.19 11:02:46.946 4: ZWDongle_Read ZW_Dongle: rcvd 0004002e08600d000126042000 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.19 11:02:46.947 5: SW: 06
2016.11.19 11:02:46.948 5: ZW_Dongle dispatch 0004002e08600d000126042000
2016.11.19 11:02:46.949 4: CMD:APPLICATION_COMMAND_HANDLER ID:2e ARG:08600d000126042000 CB:00
2016.11.19 11:02:49.104 4: ZWDongle_Read ZW_Dongle: rcvd 0004002e06600d00012605 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.19 11:02:49.105 5: SW: 06
2016.11.19 11:02:49.106 5: ZW_Dongle dispatch 0004002e06600d00012605
2016.11.19 11:02:49.107 4: CMD:APPLICATION_COMMAND_HANDLER ID:2e ARG:06600d00012605 CB:00
2016.11.19 11:02:56.162 4: ZWDongle_Read ZW_Dongle: rcvd 0004002e08600d000126046000 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.19 11:02:56.163 5: SW: 06
2016.11.19 11:02:56.164 5: ZW_Dongle dispatch 0004002e08600d000126046000
2016.11.19 11:02:56.165 4: CMD:APPLICATION_COMMAND_HANDLER ID:2e ARG:08600d000126046000 CB:00
2016.11.19 11:02:58.731 4: ZWDongle_Read ZW_Dongle: rcvd 0004002e06600d00012605 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.19 11:02:58.732 5: SW: 06
2016.11.19 11:02:58.734 5: ZW_Dongle dispatch 0004002e06600d00012605
2016.11.19 11:02:58.735 4: CMD:APPLICATION_COMMAND_HANDLER ID:2e ARG:06600d00012605 CB:00

Hoffe, alles relevante erwischt zu haben, falls nicht oder weitere Infos gewünscht sind, lass es mich bitte wissen.

Vielen Dank für Deine Unterstützung,
Andreas

[krikan]

Hallo Andreas!

Kannst Du bitte von einem anderen Taster noch ein raw-Telegramm posten. Hätte ich noch gerne zum Weiterdenken.

Grundsätzlich ist mir das Problem schon klar. Rudis ursprünglicher Code im alten 10_ZWave.pm:

Code Auswählen Erweitern

$ep = ($1 ne "00" ? $1 : $2);
sorgte in diesem Fall für die Zuordnung zum "korrekten" Endpointdevice. Jetzt erkenne ich den Grund des Codes. Der ist aber aufgrund meines Vorschlages herausgeflogen (ich wars  )
Aber ich begreife nicht, warum der Taster den Tastendruck nicht mit seinen Endpoint (01) als Quelle angibt, sondern mit seinem Hauptdevice (00) und als Ziel einen (nicht vorhandenen?) Endpoint (01) des Controllers. Lese noch einmal nach.
Müsste mir auch MULTI_CANNEL_ASSOCIATION mal  in zwapi durchlesen, testen und grübeln.
Das dauert alles noch ein wenig.

Gruß, Christian

[scooty]

Kannst Du bitte von einem anderen Taster noch ein raw-Telegramm posten.

Hallo Christian,

hoffe, ich habe Dich jetzt richtig verstanden.
Anbei das "verbose 5"-Log mit der gleichen Tastenabfolge wie oben für den rechten Taster des ZWave.me WALLC-S:

Code Auswählen Erweitern

2016.11.19 16:21:10.946 4: ZWDongle_Read ZW_Dongle: rcvd 000400280631050122005b (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.19 16:21:10.947 5: SW: 06
2016.11.19 16:21:10.949 5: ZW_Dongle dispatch 000400280631050122005b
2016.11.19 16:21:10.950 4: CMD:APPLICATION_COMMAND_HANDLER ID:28 ARG:0631050122005b CB:00
2016.11.19 16:21:15.125 4: ZWDongle_Read ZW_Dongle: rcvd 0004002e07600d00022001ff (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.19 16:21:15.125 5: SW: 06
2016.11.19 16:21:15.127 5: ZW_Dongle dispatch 0004002e07600d00022001ff
2016.11.19 16:21:15.128 4: CMD:APPLICATION_COMMAND_HANDLER ID:2e ARG:07600d00022001ff CB:00
2016.11.19 16:21:22.231 4: ZWDongle_Read ZW_Dongle: rcvd 0004002e07600d0002200100 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.19 16:21:22.232 5: SW: 06
2016.11.19 16:21:22.235 5: ZW_Dongle dispatch 0004002e07600d0002200100
2016.11.19 16:21:22.236 4: CMD:APPLICATION_COMMAND_HANDLER ID:2e ARG:07600d0002200100 CB:00
2016.11.19 16:21:29.886 4: ZWDongle_Read ZW_Dongle: rcvd 0004002e08600d000226042000 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.19 16:21:29.886 5: SW: 06
2016.11.19 16:21:29.888 5: ZW_Dongle dispatch 0004002e08600d000226042000
2016.11.19 16:21:29.889 4: CMD:APPLICATION_COMMAND_HANDLER ID:2e ARG:08600d000226042000 CB:00
2016.11.19 16:21:31.895 4: ZWDongle_Read ZW_Dongle: rcvd 0004002e06600d00022605 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.19 16:21:31.896 5: SW: 06
2016.11.19 16:21:31.898 5: ZW_Dongle dispatch 0004002e06600d00022605
2016.11.19 16:21:31.900 4: CMD:APPLICATION_COMMAND_HANDLER ID:2e ARG:06600d00022605 CB:00
2016.11.19 16:21:39.459 4: ZWDongle_Read ZW_Dongle: rcvd 0004002e08600d000226046000 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.19 16:21:39.460 5: SW: 06
2016.11.19 16:21:39.461 5: ZW_Dongle dispatch 0004002e08600d000226046000
2016.11.19 16:21:39.462 4: CMD:APPLICATION_COMMAND_HANDLER ID:2e ARG:08600d000226046000 CB:00
2016.11.19 16:21:41.357 4: ZWDongle_Read ZW_Dongle: rcvd 0004002e06600d00022605 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.11.19 16:21:41.358 5: SW: 06
2016.11.19 16:21:41.362 5: ZW_Dongle dispatch 0004002e06600d00022605
2016.11.19 16:21:41.364 4: CMD:APPLICATION_COMMAND_HANDLER ID:2e ARG:06600d00022605 CB:00


Viele Grüße,
Andreas

[krikan]

Danke Andreas, das meinte ich. Passt.

Rudi, anhaengend ein (ungetesteter) Mini-Patch, der "Deine" if-Bedingung bei $ep wieder einbaut:

Bei mcaAdd gibt sich der Controller mMn als Node mit einem Endpoint aus und assoziiert das mit der NodeId und nicht einem Endpoint des Geraetes. Darum verschickt das Geraet von root=00 eine Nachricht an Endpoint des Controllers > 0. Das war dann der Grund Deines schon richtigen Codes.

Was ich nicht herausgefunden habe: Wie assoziert man einen Endpoint mit einem Endpoint?

edit: Patch gelöscht, da in nachfolgendem Patch enthalten

[krikan]

Die Auswertung von "get <device> mca" hat wohl durch die Hex- auf Dezimalkonvertierung etwas "gelitten"und Interpretation ist für mich teilweise schwierig.

Bei langen Antwort-Telegrammen kommt eine Warnung:

Code Auswählen Erweitern

2016.11.19 15:44:17.019 4: CMD:APPLICATION_COMMAND_HANDLER ID:2a ARG:0a8e03030a000301000103 CB:00
2016.11.19 15:44:17.020 1: PERL WARNING: Hexadecimal number > 0xffffffff non-portable at (eval 5267) line 1.
2016.11.19 15:44:17.020 1: stacktrace:
2016.11.19 15:44:17.020 1:     main::__ANON__                      called by (eval 5267) (1)
2016.11.19 15:44:17.020 1:     (eval)                              called by ./FHEM/10_ZWave.pm (4446)
2016.11.19 15:44:17.021 1:     main::ZWave_Parse                   called by fhem.pl (3425)
2016.11.19 15:44:17.021 1:     main::Dispatch                      called by ./FHEM/00_ZWDongle.pm (891)
2016.11.19 15:44:17.021 1:     main::ZWDongle_Parse                called by ./FHEM/00_ZWDongle.pm (788)
2016.11.19 15:44:17.021 1:     main::ZWDongle_Read                 called by fhem.pl (3264)
2016.11.19 15:44:17.021 1:     main::CallFn                        called by fhem.pl (672)

[krikan]

Anliegender Patch behebt die Warnung und ergibt eine einfacher zu interpretierendes Reading/Event angelehnt an Ergebnis von "get <device> association".
Sicherlich noch verbesserungsfaehig.

[krikan]

Die Zuordnung der Nachrichten zu den FHEM-Devices mit der if-Variante loest bei mir ein (leichtes) Störgefühl aus, obwohl ich den Rückdrehpatch geliefert habe.

Rein aus Praktikabiliaetsgründen verdrehen wir die Angaben zum Absender/Empfaenger der Nachrichten. In den meisten Faellen wird es vermutlich nicht stören bzw. auffallen (A.Harrenberg war mMn der Erste, der darüber gestolpert ist), weil man es nur in den Roh-Nachrichten erkennt. Eigentlich müssten aber die tatsaechlichen Angaben zu Ziel und Quelle der Nachricht irgendwie auswertbar sein.

Mir fallen leider nur umstaendliche Konstrukte mit neuen Attributen oder unnoetigen Verlaengerungen der Events ein, so dass ich if-Variante für ertraeglich halte. Evtl. habt ihr noch andere Ideen.

[rudolfkoenig]

@krikan: Hab dein Patch eingecheckt.

Das Zurueckdrehen der EP-Aenderung gefaellt mir nicht wirklich, da dadurch das Problem an der anderen Stelle wieder offen ist.

Ich fasse mal zusammen, was wir wissen:
- Laut Doku (SDS12657-12, 4.84.10) ist $1 Source-EP und $2 Destination-EP. In der Doku ist nur V3 der CC beschrieben, V1 und V2 nicht. Hoffen wir mal, dass V3 kompatibel zu V1/V2 ist.
- Wir haben ein Geraet (WALLC-S), was  BASIC SET (2001) und SWITCH_MULTILEVEL REPORT (2604/2605) mit Quelle 00 und Target 02 meldet.
- Das alte (bzw. wieder eingesetzte) Code basiert auf raten, und macht es in diesem Fall richtig, indem bei $1=00 als Quelle $2 annimmt.

Wir wissen nicht, wie die MCA durchgefuehrt ist. Entweder ist es damit erklaerbar (target+source ist bereits da verdreht), oder ist der WALLC-S Firmware fehlerhaft, oder wir verstehen die Doku nicht. Ich hoffe, dass die erste Variante zutrifft:

@scooty: koenntest bitte die betroffenen Multi-Channel-Associations hier anhaengen?

[krikan]

- Laut Doku (SDS12657-12, 4.84.10) ist $1 Source-EP und $2 Destination-EP. In der Doku ist nur V3 der CC beschrieben, V1 und V2 nicht. Hoffen wir mal, dass V3 kompatibel zu V1/V2 ist.

V3 ist mit V2 kompatibel. V1 ist inkompatibel und unterstützen wir nur rudimentaer (->parse). V1 ist mir nur von Merten bekannt.

- Wir haben ein Geraet (WALLC-S), was  BASIC SET (2001) und SWITCH_MULTILEVEL REPORT (2604/2605) mit Quelle 00 und Target 02 meldet.

2 = Mein KFOB-S auch, aber der ist sehr verwandt mit WALLC-S

Wir wissen nicht, wie die MCA durchgefuehrt ist. Entweder ist es damit erklaerbar (target+source ist bereits da verdreht), oder ist der WALLC-S Firmware fehlerhaft, oder wir verstehen die Doku nicht.

Denke es koennen fast nur 2. und 3. Variante sein. Dass ich die gleiche fehlerhafte Asssoziation gesetzt habe ist eher unwahrscheinlich. Wie reagiert der zme RC2?

Mir ist unklar, wie man Endpoint zu Endpoint-Verbindungen herstellt, so dass Quelle>0 und Ziel>0. Den Fall muss es auch geben und ich bin mir nicht sicher, ob FHEM den Fall beachten muss.

[scooty]

Hallo zusammen,

erst einmal danke für euer Engagement.

@scooty: koenntest bitte die betroffenen Multi-Channel-Associations hier anhaengen?

Sehr gerne, bin gerade nur mit meinem Verständnis überfordert  , meinst Du ein list der parent und child Devices des WALLC-S?

Viele Grüße,
Andreas

[rudolfkoenig]

Ich meine "get WALLC mcaGroupings" / "get WALLC mca <groupid>" oder ab den morgigen update "get WALLC mcaAll" (letzteres dank krikan).

[krikan]

KFOB-S für Taste 2:

Code Auswählen Erweitern

2016-11-20 20:17:25   mca_3           Max 10 Nodes  Endpoints 0103
Tastendruck:

Code Auswählen Erweitern

2016.11.20 20:17:36.819 5: ZWDongle_0 dispatch 0004002a07600d00032001ff
Gleiches bei den anderen Tastern.

[krikan]

Fibaro FGMS-001:

Code Auswählen Erweitern

2016-11-20 23:08:10   mca_1           Max 5 Nodes  Endpoints 0102
2016-11-20 23:08:10   mca_2           Max 5 Nodes  Endpoints
2016-08-12 22:46:21   model           FIBARO System FGMS001 Motion Sensor
2016-08-12 22:46:21   modelConfig     fibaro/fgms.xml
2016-08-12 22:46:21   modelId         010f-0800-1001
Macht das:

Code Auswählen Erweitern

2016.11.20 23:19:43.201 5: ZWDongle_0 dispatch 0004000b07600d0102200100

[scooty]

Moin,

anbei die mca des WALLC-S:

Code Auswählen Erweitern

mcaSupportedGroupings 5
mca_1 Max 10 Nodes ZW_Dongle Endpoints
mca_2 Max 10 Nodes Endpoints 0101
mca_3 Max 10 Nodes Endpoints 0102
mca_4 Max 10 Nodes Endpoints 0103
mca_5 Max 10 Nodes Endpoints 0104
model Z-Wave.Me ZME_WALLC-S Secure Wall Controller
modelConfig zwave.me/ZME_WALLC-S.xml
modelId 0115-0100-0101

Viele Grüße,
Andreas

[rudolfkoenig]

Die mca Ausgabe schaut fuer mich in beiden Faellen kaputt aus. Ich erwarte eine Liste von Zwave-Geraeten, gefolgt von eine Liste von ZWave-Device:EP. Kann bitte jemand von euch die Roh-Daten bei der mca Abfrage auch posten?

Mir ist unklar, wie man Endpoint zu Endpoint-Verbindungen herstellt, so dass Quelle>0 und Ziel>0.

Ziel>0 kann man in mcaAdd spezifizieren.
Quelle>0 koennte durch Absetzen des mcaAdd direkt an das "Quelle>0 - Geraet" spezifiziert werden. Welche Klassen unterstuetzen die Kanaele?

Ich vermute, dass ich bisher auch die ZWave mcaAdd Doku (mit node1..nodeN marker node1/EP1...nodeN/EPN) falsch verstanden habe, darauf weist naemlich mein Beispiel fuer commandref.html hin. Ich vermute, folgendes waere richtig:

Code Auswählen Erweitern

    set remote mcaAdd 0 1 2<br>
    set remote mcaAdd 0 1 3<br>
    ...

[krikan]

FGMS-001:

Code Auswählen Erweitern

2016.11.20 23:08:10.208 4: ZWDongle_Read ZWDongle_0: rcvd 0004000b088e03010500000102 (request APPLICATION_COMMAND_HANDLER), sending ACK

Ich erwarte eine Liste von Zwave-Geraeten, gefolgt von eine Liste von ZWave-Device:EP. Kann bitte jemand von euch die Roh-Daten bei der mca Abfrage auch posten?

Verstehe ich nicht:
Zwave-Geraete nur, wenn sie mit dem Endpoint assoziert sind und das sind sie bei mir nicht.

Code Auswählen Erweitern


Endpoints 0103
Das muss man Lesen als: Ziel ist bei NodeId 01 (Controller) der Endpoint 03

Ich vermute, dass ich bisher auch die ZWave mcaAdd Doku (mit node1..nodeN marker node1/EP1...nodeN/EPN) falsch verstanden habe, darauf weist naemlich mein Beispiel fuer commandref.html hin.

Habe zwar mcaAdd nicht hinsichtlich Roh-Daten analysiert, aber die groupId fehlt doch im Verbesserungsvorschlag!?
Also: mcaAdd [groupId] [NodeId=bisher keine] [Trenner=00] [ZielNodeId] [ZielEndpoint]

[rudolfkoenig]

Danke fuer die Roh-Daten, habe das Parsen etwas umgebaut, ich verstehe die Auswertung jetzt besser.

Habe zwar mcaAdd nicht hinsichtlich Roh-Daten analysiert, aber die groupId fehlt doch im Verbesserungsvorschlag!?

Ja und nein: Ja, es fehlt, und nein, das war kein Verbesserungsvorschlag.

[krikan]

habe das Parsen etwas umgebaut, ich verstehe die Auswertung jetzt besser.

Danke für die Auflösung der Node:Endpoint-Angaben.
Jetzt ist aber meine hart erarbeitete Übereinstimmung der Readings mca_X und assocGroup_X wieder weg. 
CC Multi_Channel_Association ist afaik eine Art Erweiterung von CC Association (siehe 4.87.1 Compatibility considerations in SDS12657-12). mca_X sollte demnach grundlegend assocGroup_X entsprechen und nicht eine neue Auswertung ergeben. Mein "Schönheits"problem erkennt man am Bsp. FGS212 (entweder beides "Active" oder "Nodes"):

Code Auswählen Erweitern

     2016-11-19 22:23:43   assocGroup_1    Max 5 Nodes ZWDongle_0
     2016-11-19 22:23:44   assocGroup_1    Max 5 Nodes ZWDongle_0
     2016-11-19 22:23:44   assocGroup_2    Max 5 Nodes ZWDongle_0 
     2016-11-21 19:34:11   mca_1           Max 5 Active ZWDongle_0
     2016-11-21 19:34:11   mca_2           Max 5 Active ZWDongle_0 ZWDongle_0:2

Mich hat stört eigentlich auch der Unterschied:

Code Auswählen Erweitern

     2016-11-19 22:23:43   assocGroups     3
     2016-11-21 19:34:11   mcaSupportedGroupings 2

Liefere auch gerne Patch, wenn ich darf/soll (Nodes oder Active?)...

Ziel>0 kann man in mcaAdd spezifizieren.
Quelle>0 koennte durch Absetzen des mcaAdd direkt an das "Quelle>0 - Geraet" spezifiziert werden. Welche Klassen unterstuetzen die Kanaele?

Klassen der Kanaele hatte ich heute Mittag überlesen:
FGMS001 und KFOB-S unterstuetzen kein CC MULTI_CHANNEL mit der ich die Classes abfragen könnte, sondern nur CC MULTI_CHANNEL_ASSOCIATION.

[rudolfkoenig]

entweder beides "Active" oder "Nodes"

Wo dur Recht hast...Habe Nodes daraus gemacht.

Mich hat stört eigentlich auch der Unterschied:

Da bin ich zu blind: kannst Du es bitte explicit sagen, wie es sein soll?

[krikan]

Da bin ich zu blind: kannst Du es bitte explicit sagen, wie es sein soll?

Schlecht erklaert. Geht mir um den Befehl: Warum nicht auch mcaGroups?
Laut SDS ist Grouping Identifier nichts anderes als Association group.
Jaja, ich werde kleinlich und zum eigentlichen Problem faellt mir derzeit nichts mehr ein...

[rudolfkoenig]

Warum nicht auch mcaGroups?

Amen
Habs geaendert.

[krikan]

Bin testmaeßig durch meinen Hardwarefundus durch. Letztes Testobjekt für CC MULTI_CHANNEL_ASSOCIATION war ein

Code Auswählen Erweitern

FIBARO System FGWPE Wall Plug
modelId  010f-0600-1000
Bei dem kann ich Endpoints des Controllers assoziieren (mcaAdd 1 0 1 1,...) und bekomme auch mit mca_X die Angabe des korrekten Setzen. Jedoch habe ich dem Geraet heute und gestern keine einzige Nachricht für einen Endpoint entlocken können. Defekt, Unvermögen oder zwapi-Mißverstaendnis??
Fazit: 4 Testgeraete und 3 verschiedene Test-Ergebnisse, wobei 2 Ergebnisse mMn nicht mit zwapi in Einklang stehen. Brauche neue Testhardware...