2-Kanal UP Aktor gesucht

[DerBodo]

Hallo zusammen,

ich habe ein kleines Problem bei welchem mir sicherlich geholfen werden kann.
Vor einiger Zeit habe ich einen einfachen Schalter für das Küchenlicht mit einem Philio-PAN04 ersetzt, sowie statt dem Schalter einen Tastereinsatz eingebaut.

Die Schaltung der Ursprünglichen Lichtquelle funktioniert auch ohne Probleme. Den 2ten Kanal möchte ich nutzen um eine entfernte Lampe zu schalten.
Wenn ich nun den Dummy Kanal (2ter Kanal) über das Webfrontend schalte funktioniert dies auch ohne Probleme.
Wenn ich nun allerdings den 2ten Taster drücke geht die Lampe nicht an. Das Problem ist hierbei, dass der Status in FHEM erst geändert wird wenn ich den Status des Kanals abfrage.
Somit triggert das notify erst wenn ich den Kanal abfrage.

Gibt es einen Aktor (z.B. FGS-222 oder ähnlich) der den eigenen Status beider Kanäle direkt Richtung nach Vor-Ort Betätigung FHEM schickt ?
Es sollte ein flacher UP Aktor sein, da hinter dem Taster nicht allzuviel Platz ist.
Schalter/Tastereinsätze fallen wegen der fehlenden Kompatibilität zum Schalterprogramm (Siemens Delta) leider raus.

Vielen Dank !

Bodo

[krikan]

Verstehe Dein Problem leider noch nicht:
Hast Du für den 2.Kanal wirklich einen dummy?
Der PAN04, zumindest als ZWavePlus-Variante, reportet doch die Schaltvorgänge an die entsprechende Assoziationsgruppe pro Kanal. Bist Du sicher, dass man manuell abfragen muss?
Wenn Deiner der PAN04-1B ist, so einen habe ich hier noch als uneingebautes Testgeräte liegen und könnte das Problem bei Gelegenheit gegentesten.

[DerBodo]

Dummy war in dem Sinne gemeint, dass kein eigener Verbraucher an diesem Kanal hängt.
Ich habe den Schalter ganz normal eingebunden und dann die MCEndpoints anlegen lassen.

In der Küche ist ein PAN04 im Schlafzimmer habe ich einen PAN04-1B.
Beide setzen den Status des Parent Devices auf on/off beim Schaltvorgang, allerdings nicht den des ChildDevices.

Anbei ein List des PAN04-1B

Code Auswählen Erweitern


Internals:
   DEF        HOMEID 6
   IODev      ZWDongle_0
   LASTInputDev ZWDongle_0
   MSGCNT     235
   NAME       OG_Schlafzimmer_Licht_Schalter
   NR         395
   STATE      off
   TYPE       ZWave
   ZWDongle_0_MSGCNT 235
   ZWDongle_0_RAWMSG 000400060e3202213400000000000000000000
   ZWDongle_0_TIME 2015-07-28 20:04:27
   homeId     XXXXX
   id         06
   lastMsgTimestamp 1438106667.09241
   CHANGETIME:
   Helper:
     Dblog:
       Energy:
         Mydblog:
           TIME       1438106071.34256
           VALUE       0.01 kWh previous: 0.01 delta_time: 3600 s
       Mcendpoints:
         Mydblog:
           TIME       1438106653.9069
           VALUE      total 3, dynamic, identical
       Power:
         Mydblog:
           TIME       1438106667.10527
           VALUE       0 W
       Reportedstate:
         Mydblog:
           TIME       1438106494.73862
           VALUE      off
       State:
         Mydblog:
           TIME       1438106494.73862
           VALUE      off
   Readings:
     2015-04-28 19:00:06   CMD             ZW_APPLICATION_UPDATE
     2015-07-10 22:04:25   UNPARSED        NODE_NAMING 0777555577555575
     2015-04-28 19:32:53   assocGroup_01   Max 01 Nodes 01
     2015-04-28 23:41:04   configEdgeOrPulseModeOrEdgeTogleMode ToggleMode
     2015-07-28 19:54:31   energy           0.01 kWh previous: 0.01 delta_time: 3600 s
     2015-04-28 19:34:58   mcCapability_01 UNKNOWN_10 UNKNOWN_01 SWITCH_BINARY BASIC METER
     2015-04-28 19:34:46   mcCapability_02 UNKNOWN_10 UNKNOWN_01 SWITCH_BINARY BASIC METER
     2015-04-28 19:34:53   mcCapability_83 UNKNOWN_10 UNKNOWN_01 SWITCH_BINARY BASIC METER
     2015-07-28 20:04:13   mcEndpoints     total 3, dynamic, identical
     2015-04-28 23:39:00   model           Philio Technology Corporation PAN04-1B Double Relay Switch 2x1.5kW with Power Measurement
     2015-04-28 23:39:00   modelConfig     philio/pan04.xml
     2015-04-28 23:39:00   modelId         013c-0001-0012
     2015-07-28 20:04:27   power            0 W
     2015-07-28 20:01:34   reportedState   off
     2015-07-28 20:01:34   state           off
     2015-07-28 20:04:13   transmit        OK
     2015-05-05 20:41:59   zwavePlusInfo   version:01 role:AlwaysOnSlave node:Z-Wave+Node installerIcon:0700 userIcon:0700
Attributes:
   IODev      ZWDongle_0
   classes    ZWAVEPLUS_INFO VERSION MANUFACTURER_SPECIFIC DEVICE_RESET_LOCALLY ASSOCIATION ASSOCIATION_GRP_INFO POWERLEVEL SWITCH_BINARY BASIC SWITCH_ALL ALARM SCENE_ACTIVATION SCENE_ACTUATOR_CONF PROTECTION FIRMWARE_UPDATE_MD MULTI_CHANNEL METER CONFIGURATION
   room       ZWave


[krikan]

Hast Du für das Child-Device (Endpoint) die passende Assoziation mit dem Controller gesetzt?

[DerBodo]

Das könnte es schon sein.

Ein List vom Child Device sagt folgendes:

Code Auswählen Erweitern


Internals:
   DEF        HOMEID 1537
   IODev      ZWDongle_0
   LASTInputDev ZWDongle_0
   MSGCNT     2
   NAME       OG_Schlafzimmer_Licht_Links
   NR         397
   STATE      off
   TYPE       ZWave
   ZWDongle_0_MSGCNT 2
   ZWDongle_0_RAWMSG 0004100607600d0101250300
   ZWDongle_0_TIME 2015-07-26 11:54:35
   homeId     XXXX
   id         0601
   CHANGETIME:
   Helper:
     Dblog:
       Reportedstate:
         Mydblog:
           TIME       1438106071.58105
           VALUE      off
       State:
         Mydblog:
           TIME       1438106458.13704
           VALUE      off
   Readings:
     2015-05-04 18:14:07   modelId         013c-0001-0003
     2015-07-28 19:54:31   reportedState   off
     2015-07-28 20:00:58   state           off
Attributes:
   IODev      ZWDongle_0
   classes    UNKNOWN_01 UNKNOWN_10 UNKNOWN_01 SWITCH_BINARY BASIC METER
   room       ZWave


Allerdings bietet mir zumindest das SET Dropdown nur folgende Optionen:

Code Auswählen Erweitern


basicValue
meterReset
off
on
blink
toggle
on-for-timer
on-till
off-for-timer
intervals
off-till


Ein entsprechendes set command wie im WIKI beschrieben wird mir dann mit "unknown Argument" quittiert.

[krikan]

Da ich selbst noch kein 2-kanaliges Device getestet habe, nach Überfliegen der Doku nur folgenden Hinweis:
Es gibt 3 Endpoints mit verschiedenen Funktionen, hast Du alle angelegt und ausprobiert?

Kommandos hast Du nur so wie Attribut "classes" Command Classes mit den zugehörigen Befehlen enthält. Dort sind nicht mehr CC und komischerweise auch noch 3 unkown.

Befürchte ich kann Dir nur detailliert weiterhelfen, wenn ich das am Testgerät ausprobiere. Das schaffe ich aber vermutlich nicht vor dem Wochenende.

Vielleicht kann Dir noch jemand anderes helfen; denke aber, neuen Aktor brauchst Du nicht.

[DerBodo]

Alle 3 Entbeinst sind angelegt.
Diese folgen insgesamt der folgenden Logik:

Device ID = 6
Endpoint 1 ID = 0601
Endpoint 2 ID = 0602
Endpoint 3 ID = 0683

Endpoint 1 und 3 schalten Kanal 1, Endpoint 2 schaltet den Kanal 2.
Das Masterdevice wird immer auf on gesetzt wenn einer der beiden Kanäle auf on geht.

Dies kann man ja über das configByte einstellen.

Vielen Dank schon mal, dass du dir die Mühe machst das ganze bei dir nachzustellen.

[DerBodo]

Im Manual für den Pan04-1B habe ich un folgendes gefunden:

Code Auswählen Erweitern

Association Groups:

1 Status-Update für Relais 1 and 2 and all Metering reports (max. nodes in group: 1)
2 Status-Update für Relais 1 and Metering reports (max. nodes in group: 1)
3 Status-Update für Relais 2 and Metering reports (max. nodes in group: 1)

Daraufhin habe ich gemäß bekanntem Schema:

set <devicename> associationAdd <Group> <Controllerid>

Die 2 weiteren Gruppen tauchen auch im Device auf.

In der Anleitung für den PAN04 habe ich folgenden Part entdeckt:

Code Auswählen Erweitern


2-1 Auto report to Grouping 1 ~3(Maximum Node 1)
2-1-1 On/Off Event Report
      When "on" or "off " state has been changed by pressing S1 S2 or on/off button, it will send Binary Switch Report to the nodes of Group1~3.   
Binary Switch Report
ON:
[Command Class Switch Binary, Switch Binary Report,
Value
=(255)0xFF]
OFF:
[Command Class Switch Binary, Switch Binary Report,
Value
=0(0x00


Allerdings ist nirgends vermerkt welches configByte das ist.

[krikan]

Habe zwischendurch mal kurz angeschlossen und experimentiert:
Für jeden Endpoint Fhem-Device angelegt
Assoziationen Controller mit jeder Gruppe 1-3 angelegt

Beim Schalten landen alle reportedState beim Ursprungsdevice. Irgendetwas ist da komisch. Brauche fürs genauere Nachschauen aber noch ein wenig Zeit.

[krikan]

Zwischenstand:

ZWave_SWITCH_BINARY_3     -> Ursprungsdevice
ZWave_UNKNOWN_10_3.01   -> Endpoint 1
ZWave_UNKNOWN_10_3.02   -> Endpoint 2
ZWave_UNKNOWN_10_3.83   -> Endpoint 3

Der Aktor antwortet auf ein Schalt-Befehl mit CC Multi_Channel nicht -wie mir bisher bekannt- mit einem CC Multi_Channel-Telegramm aus dem sich der geschaltete Kanal ergibt. Vielmehr sind das die "normalen" Antworttelegramme eines einkanaligen Aktors, die keine  Kanalbestimmung enthalten und darum immer im Ursprungsdevice landen. In den Config-Einstellungen finde ich keine Möglichkeit das zu ändern.

Fragt man hingegen den Status eines Endpoint-Device mit get-Befehl ab, kommt die Antwort als CC Multi_Channel mit der korrekten Endpoint-Angabe.

"Workaround", um den Status korrekt in den Endpoint-Devices zu sehen:

• Assoziation des Controllers im Originaldevice nur mit Group 1
• notify mit Abfrage der Status der beiden Endpoint-Devices 1 und 2 bei einer Statusänderung des Urspungsdevices.

Vermutlich kann man die Einbindung in Fhem deutlich verbessern, wenn man weiter analysiert, da diverse Merkwürdigkeiten im Log zu erkennen sind:

Code Auswählen Erweitern

2015.07.30 20:53:02 2: ZWave set ZWave_UNKNOWN_10_3.01 off
2015.07.30 20:53:02 5: ZWDongle_Write 00 130307600d01012501000503
2015.07.30 20:53:02 5: SW: 010e00130307600d01012501000503a9
2015.07.30 20:53:02 5: ACK received, removing 010e00130307600d01012501000503a9 from sendstack
2015.07.30 20:53:02 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 011301
2015.07.30 20:53:02 5: SW: 06
2015.07.30 20:53:02 5: ZWDongle_1 dispatch 011301
2015.07.30 20:53:03 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 001303000002
2015.07.30 20:53:03 5: SW: 06
2015.07.30 20:53:03 5: ZWDongle_1 dispatch 001303000002
2015.07.30 20:53:03 4: ZWDongle_1 CMD:ZW_SEND_DATA ID:00 ARG:0002
2015.07.30 20:53:03 4: ZWDongle_1 transmit OK for 03
2015.07.30 20:53:05 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 0004000303250300
2015.07.30 20:53:05 5: SW: 06
2015.07.30 20:53:05 5: ZWDongle_1 dispatch 0004000303250300
2015.07.30 20:53:05 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:03 ARG:03250300
2015.07.30 20:53:05 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 000400030e3202213400000000000000000000
2015.07.30 20:53:05 5: SW: 06
2015.07.30 20:53:05 5: ZWDongle_1 dispatch 000400030e3202213400000000000000000000
2015.07.30 20:53:05 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:03 ARG:0e3202213400000000000000000000

Die Antwort auf ZW_SEND_DATA ist deutlich länger, als die mir bisher bekannten Varianten. Bedeutung?

Zudem sind die angelegten Endpoints wegen UNKNOW (auch im Attribut classes) etwas ungewöhnlich:

Code Auswählen Erweitern

2015.07.29 19:35:55 2: ZWave get ZWave_SWITCH_BINARY_3 mcCapability
2015.07.29 19:35:55 5: ZWDongle_Write 00 1303036009010503
2015.07.29 19:35:55 5: SW: 010a00130303600901050388
2015.07.29 19:35:55 4: ZWDongle_ReadAnswer arg:mcCapability regexp:^00040003..60
2015.07.29 19:35:55 5: ACK received, removing 010a00130303600901050388 from sendstack
2015.07.29 19:35:55 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 011301
2015.07.29 19:35:55 5: SW: 06
2015.07.29 19:35:55 5: ZWDongle_1 dispatch 011301
2015.07.29 19:35:55 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 001303000002
2015.07.29 19:35:55 5: SW: 06
2015.07.29 19:35:55 5: ZWDongle_1 dispatch 001303000002
2015.07.29 19:35:55 4: ZWDongle_1 CMD:ZW_SEND_DATA ID:00 ARG:0002
2015.07.29 19:35:55 4: ZWDongle_1 transmit OK for 03
2015.07.29 19:35:55 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 0004000308600a011001252032
2015.07.29 19:35:55 5: SW: 06
2015.07.29 19:35:55 4: ZWDongle_ReadAnswer for mcCapability: 0004000308600a011001252032
2015.07.29 19:35:55 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:03 ARG:08600a011001252032
2015.07.29 19:35:55 2: autocreate: define ZWave_UNKNOWN_10_3.01 ZWave c98d0500 769 011001252032
2015.07.29 19:35:55 2: autocreate: define FileLog_ZWave_UNKNOWN_10_3.01 FileLog ./log/ZWave_UNKNOWN_10_3.01-%Y.log ZWave_UNKNOWN_10_3.01

list:

Code Auswählen Erweitern

Internals:
   DEF        c98d0500 769
   IODev      ZWDongle_1
   NAME       ZWave_UNKNOWN_10_3.01
   NR         31
   STATE      off
   TYPE       ZWave
   homeId     c98d0500
   id         0301
   Readings:
     2015-07-30 18:47:55   basicReport     00
     2015-07-30 18:48:06   reportedState   off
     2015-07-30 20:53:02   state           off
Attributes:
   IODev      ZWDongle_1
   classes    UNKNOWN_01 UNKNOWN_10 UNKNOWN_01 SWITCH_BINARY BASIC METER
   room       ZWave
Der Aktor nutzt CC Multi_Channel V3 -> Was sind die Neuerungen von V3 ?

Vielleicht erkennt jemand mehr...

[DerBodo]

Danke fürs forschen.
Mit dem Notify hatte ich es auch schon mal ne ganze Zeit am laufen.
Dann werde ich es wohl wieder so machen müssen.

[krikan]

Zu "UNKNOWN_01 UNKNOWN_10 UNKNOWN_01" im Attribut classes:

Fhem macht bei Auswertung von get-mcCapability keine Unterscheidung der Class nach V1 und V2. Normalerweise sind Classes abwärtskompatibel, nur im Fall der Class MULTI_CHANNEL nicht. Die hieß als V1 auch noch MULTI_INSTANCE.

Bei V2 sind die ersten drei Argumente nach 0a:
Pos.1 = Endpoint
Pos.2 = Generic Device Class
Pos.3 = Specific Device Class

Bei V1 waren diese Positionen bereits die unterstützten Command Classes des Endpoints. Fhem wertet derzeit als V1 aus und nimmt Werte als "UNKOWN_xy" classes an. Auswirkungen auf das eigentliche Problem kann ich nicht feststellen. Es fehlt derzeit zwar die aus der Generic/Specific Class abgeleitete Class SWITCH_ALL in den Endpoints, das ist aber hier nicht wichtig.

Wozu ich weiterhin nichts finde:
Was bedeuten die langen Callback-Antworten von ZW_SEND_DATA:

Code Auswählen Erweitern

2015.07.30 20:53:03 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 001303000002
Haben die eine Auswirkung? Oder liegt es an fehlenden infos zu CC Multi-Channel V3?

[krikan]

Nach weiteren Experinmenten und Recherche folgende Meinung:
Der Aktor verhält sich zwapi-konform, indem er die CC Multichannel-Reports nur nach expliziter Anforderung durch einen get-Befehl verschickt. Unangeforderte CC-Mulitcannel-Reports sollen von den Geräten nicht verschickt werden. Andere ZWave-Programme verschicken laut log daher bei set-Befehlen der CC Multichannel direkt den entsprechenden get-befehl der CC-Multichannel mit. Laut CC AssociatonGroupInfo ist AssoGroup 1 die "lifeline". "lifeline" ist die einzige Group, die mit Gateway standardmäßig assoziert werden soll. Das ist erfolgt und jede Änderung muss explizit mit get-Befehl CC Multichannel abgefragt werden. Also ist der oben genannte "workaround" der Standard. Einfluß der ZW_SEND_DATA Antworten und/oder CC Multichannel V3 sehe ich derzeit nicht mehr.

---

Mich würde ein log mit verbose 5 für den Fibaro 2-Kanal-Aktor (FGS-221/FGS-222) interessieren. Könnte bitte jemand das für Schaltvorgänge der einzelnen Kanäle zur Verfügung stellen?
Hintergrund: Sendet Fibaro wirklich automatisch Reports der CC Multichannel bei Schaltvorgängen? Vielleicht kann das jemand auch so beantworten; Logs wären mir lieber 

[nightstorm99]

Hallo krikan,

Mich würde ein log mit verbose 5 für den Fibaro 2-Kanal-Aktor (FGS-221/FGS-222) interessieren. Könnte bitte jemand das für Schaltvorgänge der einzelnen Kanäle zur Verfügung stellen?
Hintergrund: Sendet Fibaro wirklich automatisch Reports der CC Multichannel bei Schaltvorgängen? Vielleicht kann das jemand auch so beantworten; Logs wären mir lieber 

Wenn ich aus dem Urlaub zurück bin (15.8.), dann erstelle ich mal die Logs!
Ich hätte folgende Fibaro zum testen FGD211, FGS222 und FGRM222.
Welche würden dich am meisten interessieren?

Gruß
Denny

[krikan]

Hallo Denny,

das wäre Klasse. Mich (und vermutlich Bodo) interessiert "nur" der 2- Kanal-Aktor FGS222 wegen CC Multichannel, die anderen von Dir genannten Aktoren besitzen die CC nicht.
Was ich beim FGS222 bräuchte: Logs mit verbose 5 für Schaltvorgänge auf beiden Kanälen. Daraus kann man dann hoffentlich ein paar Schlüsse ziehen.

Danke und Gruß,
Christian