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

[DerBodo]

Hallo Christian,

ich war so dreist und habe Denny einfach mal via PN gefragt ob er das für uns machen könnte

@ Denny, danke dass du das nach deinem Urlaub für uns machst !

Grüße

Bodo

[nightstorm99]

Hallo Zusammen,

Regenwetter da hat man Zeit für solche Sachen!

Hier erstmal die List Einträge von dem FGS222:

Code Auswählen Erweitern

Internals:
   DEF        ee7bb30d 12
   IODev      ZWDongle_1
   NAME       bw.steckdose.kreis_1
   NR         279
   STATE      off
   TYPE       ZWave
   homeId     ee7bb30d
   id         0c
   Readings:
     2015-07-27 16:39:20   configEnableDisableALLONOFF ALLONActiveALLOFFActive
     2015-07-20 15:17:44   configInputsButtonSwitchConfiguration BiStableInputSwitch
     2015-08-03 20:46:12   model           FIBARO System FGS222 Double Relay Switch 2x1.5kW
     2015-08-03 20:46:12   modelConfig     fibaro/fgs222.xml
     2015-08-03 20:46:12   modelId         010f-0202-1002
     2015-07-27 16:20:56   powerlvl        current 0 remain 0
     2015-07-27 16:40:35   powerlvlTest    node 12 status 2 frameAck 0
     2015-08-03 08:53:11   reportedState   off
     2015-08-16 03:15:06   state           off
     2015-08-01 22:32:42   swa             on off
     2015-08-16 04:00:05   transmit        OK
     2015-07-28 21:15:14   version         Lib 3 Prot 3.52 App 2.2
Attributes:
   IODev      ZWDongle_1
   classes    MANUFACTURER_SPECIFIC VERSION CONFIGURATION ASSOCIATION MULTI_CHANNEL_ASSOCIATION MULTI_CHANNEL SWITCH_BINARY SWITCH_ALL FIRMWARE_UPDATE_MD POWERLEVEL MARK SWITCH_BINARY MULTI_CHANNEL
   group      Steckdosen
   icon       sani_sprinkling
   on         bewaesserung_ventil_all
   room       Bewässerung
   userattr   on on_map structexclude
   verbose    5
   webCmd     on:off

Hier der 2. :

Code Auswählen Erweitern

Internals:
   DEF        ee7bb30d 3074
   IODev      ZWDongle_1
   NAME       bw.steckdose.kreis_2
   NR         281
   STATE      off
   TYPE       ZWave
   homeId     ee7bb30d
   id         0c02
   Readings:
     2015-07-29 06:59:12   reportedState   off
     2015-08-16 04:00:05   state           off
Attributes:
   IODev      ZWDongle_1
   classes    SWITCH_BINARY
   group      Steckdosen
   icon       sani_sprinkling
   on         bewaesserung_ventil_all
   room       Bewässerung
   userattr   on on_map structexclude
   verbose    5

Hier mal ein paar Logs bei anschalten dazu:

Code Auswählen Erweitern

2015.08.18 10:52:07 5: Cmd: >set bw.steckdose.kreis_1 on<
2015.08.18 10:52:07 2: ZWave set bw.steckdose.kreis_1 on
2015.08.18 10:52:07 5: ZWDongle_Write 00 130c032501FF250c
2015.08.18 10:52:07 5: SW: 010a00130c032501FF250c1b
2015.08.18 10:52:07 5: Triggering bw.steckdose.kreis_1 (1 changes)
2015.08.18 10:52:07 5: Notify loop for bw.steckdose.kreis_1 on
2015.08.18 10:52:07 5: ACK received, removing 010a00130c032501FF250c1b from sendstack
2015.08.18 10:52:07 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 011301
2015.08.18 10:52:07 5: SW: 06
2015.08.18 10:52:07 5: ZWDongle_1 dispatch 011301
2015.08.18 10:52:08 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 00130c00006d
2015.08.18 10:52:08 5: SW: 06
2015.08.18 10:52:08 5: ZWDongle_1 dispatch 00130c00006d
2015.08.18 10:52:08 4: ZWDongle_1 CMD:ZW_SEND_DATA ID:00 ARG:006d
2015.08.18 10:52:08 4: ZWDongle_1 transmit OK for 0c
2015.08.18 10:52:10 5: Cmd: >set bw.steckdose.kreis_2 on<
2015.08.18 10:52:10 2: ZWave set bw.steckdose.kreis_2 on
2015.08.18 10:52:10 5: ZWDongle_Write 00 130c07600d01022501FF250c
2015.08.18 10:52:10 5: SW: 010e00130c07600d01022501FF250c75
2015.08.18 10:52:10 5: Triggering bw.steckdose.kreis_2 (1 changes)
2015.08.18 10:52:10 5: Notify loop for bw.steckdose.kreis_2 on
2015.08.18 10:52:10 5: ACK received, removing 010e00130c07600d01022501FF250c75 from sendstack
2015.08.18 10:52:10 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 011301
2015.08.18 10:52:10 5: SW: 06
2015.08.18 10:52:10 5: ZWDongle_1 dispatch 011301
2015.08.18 10:52:10 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 00130c000007
2015.08.18 10:52:10 5: SW: 06
2015.08.18 10:52:10 5: ZWDongle_1 dispatch 00130c000007
2015.08.18 10:52:10 4: ZWDongle_1 CMD:ZW_SEND_DATA ID:00 ARG:0007
2015.08.18 10:52:10 4: ZWDongle_1 transmit OK for 0c


Beim ausschalten:

Code Auswählen Erweitern

2015.08.18 10:55:01 5: Cmd: >set bw.steckdose.kreis_1 off<
2015.08.18 10:55:01 2: ZWave set bw.steckdose.kreis_1 off
2015.08.18 10:55:01 5: ZWDongle_Write 00 130c03250100250c
2015.08.18 10:55:01 5: SW: 010a00130c03250100250ce4
2015.08.18 10:55:01 5: Triggering bw.steckdose.kreis_1 (1 changes)
2015.08.18 10:55:01 5: Notify loop for bw.steckdose.kreis_1 off
2015.08.18 10:55:01 5: ACK received, removing 010a00130c03250100250ce4 from sendstack
2015.08.18 10:55:01 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 011301
2015.08.18 10:55:01 5: SW: 06
2015.08.18 10:55:01 5: ZWDongle_1 dispatch 011301
2015.08.18 10:55:01 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 00130c000006
2015.08.18 10:55:01 5: SW: 06
2015.08.18 10:55:01 5: ZWDongle_1 dispatch 00130c000006
2015.08.18 10:55:01 4: ZWDongle_1 CMD:ZW_SEND_DATA ID:00 ARG:0006
2015.08.18 10:55:01 4: ZWDongle_1 transmit OK for 0c
2015.08.18 10:55:02 5: Cmd: >set bw.steckdose.kreis_2 off<
2015.08.18 10:55:02 2: ZWave set bw.steckdose.kreis_2 off
2015.08.18 10:55:02 5: ZWDongle_Write 00 130c07600d0102250100250c
2015.08.18 10:55:02 5: SW: 010e00130c07600d0102250100250c8a
2015.08.18 10:55:02 5: Triggering bw.steckdose.kreis_2 (1 changes)
2015.08.18 10:55:02 5: Notify loop for bw.steckdose.kreis_2 off
2015.08.18 10:55:02 5: ACK received, removing 010e00130c07600d0102250100250c8a from sendstack
2015.08.18 10:55:02 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 011301
2015.08.18 10:55:02 5: SW: 06
2015.08.18 10:55:02 5: ZWDongle_1 dispatch 011301
2015.08.18 10:55:02 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 00130c000006
2015.08.18 10:55:02 5: SW: 06
2015.08.18 10:55:02 5: ZWDongle_1 dispatch 00130c000006
2015.08.18 10:55:02 4: ZWDongle_1 CMD:ZW_SEND_DATA ID:00 ARG:0006
2015.08.18 10:55:02 4: ZWDongle_1 transmit OK for 0c

Ist das so okay?

Gruß Denny

[krikan]

Hallo Denny,

erst einmal vielen Dank für das Log und Deinen Einsatz.

Leider sind in Deinem Log überhaupt keine Rückmeldungen des Aktors auf Deine Schaltbefehle zu erkennen (oder übersehe ich etwas!?). Es sieht so aus, als würde überhaupt kein Zustand reportet. Kommen die Reports erst später im log oder gar nicht? Letzteres vermute ich fast. Das spiegelt sich auch in den Readings Deiner List wieder, die alle einen älteren Zeitstempel haben.

Welche Assoziation hast Du gesetzt?
Der Aktor hat die Class MULTI_CHANNEL_ASSOCIATION. Hast Du damit etwas konfiguriert? Das könnte ggfs. Bodos Problem auch lösen.

Gruß, Christian

[nightstorm99]

Hallo Christian,

nein mit Class MULTI_CHANNEL_ASSOCIATION habe ich nix gemacht, auch sonst nix mit ASSOCIATION.
Was soll ich noch einstellen? Dann mache ich die LOG Ausgabe noch einmal.
Ich habe auch keinen direkten Schalter am Gerät dran, mache alles über Funk!

Was mir noch einfällt, er hat bei mir nur ein Node mit .1 angelegt.
Wenn ich das richtig verstehe müssten es aber 2 sein und der Hauptaktor über den man beide steuern kann, oder?


Gruß Denny

[krikan]

Frage bitte mal ab, ob der Controller nicht in der 3. Assoziationsgruppe des FGS222 aufgenommen ist. Wenn bw.steckdose.kreis_1 das automatisch von Fhem angelegte Hauptdevice:

Code Auswählen Erweitern

get bw.steckdose.kreis_1 association 3
Wenn Controller tatsächlich nicht in 3. Assoziationsgruppe des FGS222 aufgenommen ist, was ich annehme. Bitte Controller in die 3. Assoziationsgruppe des FGS222 aufnehmen. Wenn bw.steckdose.kreis_1 das automatisch von Fhem angelegte Hauptdevice und Controller-NodeId = 1:

Code Auswählen Erweitern

set bw.steckdose.kreis_1 3 1
Dadurch sollten beim Controller auch Rückmeldungen über Zustand des Devices eingehen und dann würde mich das Log interessieren.

Wenn ich das richtig verstehe müssten es aber 2 sein und der Hauptaktor über den man beide steuern kann, oder?

Das ist mMn nicht zwingend und vom Gerät abhängig. Vermute der FGS hat nur zwei. Kannst Du mit folgendem Befehl abfragen:

Code Auswählen Erweitern

get bw.steckdose.kreis_1 mcEndpoints

Gruß, Christian

[nightstorm99]

Hallo Christian,

also der FGS222 war schon in der Assoziationsgruppe 3 drin.
Vorher und nachher (nochmaliges associationAdd) steht das selbe drin:

Code Auswählen Erweitern

assocGroup_03:Max 01 Nodes 01

Bei mcEndpoints kommt folgendes:

Code Auswählen Erweitern

mcEndpoints:total 2, identical

Wenn ich mein "global" auf Verbose 5 setze, sehe ich immer alle Geräte im Log und es ist schwer dieses zu filtern.
Geht es irgendwie, das ich nur das Zwave Gerät auf Verbose 5 sehe. Ich hab Verbose 5 im Gerät angeschaltet, aber geht irgendwie nicht einzeln oder?

Könnte es Probleme geben, weil der FGS222 hinter meinen Repeater hängt?
Gruß Denny

[krikan]

Hallo Denny,

also der FGS222 war schon in der Assoziationsgruppe 3 drin.

dann müsste nach meinem Verständnis auch etwas gemeldet werden; sehe aber nichts. Bin gerade ziemlich ratlos...

Bei mcEndpoints kommt folgendes:

Code Auswählen Erweitern

mcEndpoints:total 2, identical

Also 2 Endpoints und 2x mcAdd
Ich möchte Dir jetzt nicht raten, die anzulegen: Habe mich bisher nicht intensiv mit Multichannel auseinandergesetzt, kenne den Aktor nicht und möchte keine funktionsfähige Installation nur wegen meiner Zwave-Neugier kaputt machen.

Wenn ich mein "global" auf Verbose 5 setze, sehe ich immer alle Geräte im Log und es ist schwer dieses zu filtern.
Geht es irgendwie, das ich nur das Zwave Gerät auf Verbose 5 sehe. Ich hab Verbose 5 im Gerät angeschaltet, aber geht irgendwie nicht einzeln oder?

Lasse bei "global" verbose auf einem niedrigen Wert (bspw. 3) und setze es nur beim ZWDongle-Device hoch, dann flutet nur Zwave das Log. Bei den einzelnen ZWave-Devices bringt es leider nichts; hätte ich aber auch gerne.

Könnte es Probleme geben, weil der FGS222 hinter meinen Repeater hängt?

Vorstellen kann ich es mir nicht; mangels Repeater aber auch nicht verneinen.

Du kannst mir auch gerne ein (langes) ungefiltertes log per PM von Schaltvorgängen schicken, dann schaue ich dort einfach mal rein, bevor Du irgendetwas an Fhem bzw. Device-Konfiguration änderst.

Danke noch mal, Christian

[nightstorm99]

Also ändern möchte ich jetzt auch nichts, da es ja geht!
mcAdd habe ich bei dem Gerät nicht gemacht.

Habe jetzt mal einen Schalter noch angebaut und manuell geschaltet.
Rückmeldungen werden aber an FHEM gesendet und übernommen.
Hier mal der Log dazu. Nicht wundern, es ist noch ein bw.steckdose.kreis_3 mit drin, das ist ein Dimmer.

Code Auswählen Erweitern

2015.08.18 16:24:47 3: ZWave reading config for unknown
2015.08.18 16:25:12 3: ZWave reading config for fibaro/fgs222.xml
2015.08.18 16:25:12 3: ZWave reading config for fibaro/fgd211.xml
2015.08.18 16:25:20 2: ZWave set bw.steckdose.kreis_1 on
2015.08.18 16:25:20 5: ZWDongle_Write 00 130c032501FF250c
2015.08.18 16:25:20 5: SW: 010a00130c032501FF250c1b
2015.08.18 16:25:20 5: ACK received, removing 010a00130c032501FF250c1b from sendstack
2015.08.18 16:25:20 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 011301
2015.08.18 16:25:20 5: SW: 06
2015.08.18 16:25:20 5: ZWDongle_1 dispatch 011301
2015.08.18 16:25:20 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 00130c000006
2015.08.18 16:25:20 5: SW: 06
2015.08.18 16:25:20 5: ZWDongle_1 dispatch 00130c000006
2015.08.18 16:25:20 4: ZWDongle_1 CMD:ZW_SEND_DATA ID:00 ARG:0006
2015.08.18 16:25:20 4: ZWDongle_1 transmit OK for 0c
2015.08.18 16:25:34 2: ZWave set bw.steckdose.kreis_2 on
2015.08.18 16:25:34 5: ZWDongle_Write 00 130c07600d01022501FF250c
2015.08.18 16:25:34 5: SW: 010e00130c07600d01022501FF250c75
2015.08.18 16:25:34 5: ACK received, removing 010e00130c07600d01022501FF250c75 from sendstack
2015.08.18 16:25:34 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 011301
2015.08.18 16:25:34 5: SW: 06
2015.08.18 16:25:34 5: ZWDongle_1 dispatch 011301
2015.08.18 16:25:34 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 00130c000006
2015.08.18 16:25:34 5: SW: 06
2015.08.18 16:25:34 5: ZWDongle_1 dispatch 00130c000006
2015.08.18 16:25:34 4: ZWDongle_1 CMD:ZW_SEND_DATA ID:00 ARG:0006
2015.08.18 16:25:34 4: ZWDongle_1 transmit OK for 0c
2015.08.18 16:25:42 2: ZWave set bw.steckdose.kreis_3 on
2015.08.18 16:25:42 5: ZWDongle_Write 00 130e032601FF250e
2015.08.18 16:25:42 5: SW: 010a00130e032601FF250e18
2015.08.18 16:25:42 5: ACK received, removing 010a00130e032601FF250e18 from sendstack
2015.08.18 16:25:42 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 011301
2015.08.18 16:25:42 5: SW: 06
2015.08.18 16:25:42 5: ZWDongle_1 dispatch 011301
2015.08.18 16:25:42 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 00130e00000a
2015.08.18 16:25:42 5: SW: 06
2015.08.18 16:25:42 5: ZWDongle_1 dispatch 00130e00000a
2015.08.18 16:25:42 4: ZWDongle_1 CMD:ZW_SEND_DATA ID:00 ARG:000a
2015.08.18 16:25:42 4: ZWDongle_1 transmit OK for 0e
2015.08.18 16:25:44 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 000400040a32022144000000070000
2015.08.18 16:25:44 5: SW: 06
2015.08.18 16:25:44 5: ZWDongle_1 dispatch 000400040a32022144000000070000
2015.08.18 16:25:44 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:0a32022144000000070000
2015.08.18 16:25:47 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 0004000406310504220007
2015.08.18 16:25:47 5: SW: 06
2015.08.18 16:25:47 5: ZWDongle_1 dispatch 0004000406310504220007
2015.08.18 16:25:47 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:06310504220007
2015.08.18 16:26:22 2: ZWave set bw.steckdose.kreis_3 off
2015.08.18 16:26:22 5: ZWDongle_Write 00 130e03260100250e
2015.08.18 16:26:22 5: SW: 010a00130e03260100250ee7
2015.08.18 16:26:22 5: ACK received, removing 010a00130e03260100250ee7 from sendstack
2015.08.18 16:26:22 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 011301
2015.08.18 16:26:22 5: SW: 06
2015.08.18 16:26:22 5: ZWDongle_1 dispatch 011301
2015.08.18 16:26:23 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 00130e000078
2015.08.18 16:26:23 5: SW: 06
2015.08.18 16:26:23 5: ZWDongle_1 dispatch 00130e000078
2015.08.18 16:26:23 4: ZWDongle_1 CMD:ZW_SEND_DATA ID:00 ARG:0078
2015.08.18 16:26:23 4: ZWDongle_1 transmit OK for 0e
2015.08.18 16:26:34 2: ZWave set bw.steckdose.kreis_2 off
2015.08.18 16:26:34 5: ZWDongle_Write 00 130c07600d0102250100250c
2015.08.18 16:26:34 5: SW: 010e00130c07600d0102250100250c8a
2015.08.18 16:26:37 2: ZWave_ProcessSendStack: no ACK, resending message
2015.08.18 16:26:37 5: SW: 010e00130c07600d0102250100250c8a
2015.08.18 16:26:37 5: ACK received, removing 010e00130c07600d0102250100250c8a from sendstack
2015.08.18 16:26:37 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 011301
2015.08.18 16:26:37 5: SW: 06
2015.08.18 16:26:37 5: ZWDongle_1 dispatch 011301
2015.08.18 16:26:37 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 011301
2015.08.18 16:26:37 5: SW: 06
2015.08.18 16:26:37 5: ZWDongle_1 dispatch 011301
2015.08.18 16:26:37 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 011301
2015.08.18 16:26:37 5: SW: 06
2015.08.18 16:26:37 5: ZWDongle_1 dispatch 011301
2015.08.18 16:26:37 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 011301
2015.08.18 16:26:37 5: SW: 06
2015.08.18 16:26:37 5: ZWDongle_1 dispatch 011301
2015.08.18 16:26:37 4: ZWDongle_Read ZWDongle_1: CAN received
2015.08.18 16:26:37 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 00130c000006
2015.08.18 16:26:37 5: SW: 06
2015.08.18 16:26:37 5: ZWDongle_1 dispatch 00130c000006
2015.08.18 16:26:37 4: ZWDongle_1 CMD:ZW_SEND_DATA ID:00 ARG:0006
2015.08.18 16:26:37 4: ZWDongle_1 transmit OK for 0c
2015.08.18 16:26:42 2: ZWave set bw.steckdose.kreis_1 off
2015.08.18 16:26:42 5: ZWDongle_Write 00 130c03250100250c
2015.08.18 16:26:42 5: SW: 010a00130c03250100250ce4
2015.08.18 16:26:42 5: ACK received, removing 010a00130c03250100250ce4 from sendstack
2015.08.18 16:26:42 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 011301
2015.08.18 16:26:42 5: SW: 06
2015.08.18 16:26:42 5: ZWDongle_1 dispatch 011301
2015.08.18 16:26:42 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 00130c000006
2015.08.18 16:26:42 5: SW: 06
2015.08.18 16:26:42 5: ZWDongle_1 dispatch 00130c000006
2015.08.18 16:26:42 4: ZWDongle_1 CMD:ZW_SEND_DATA ID:00 ARG:0006
2015.08.18 16:26:42 4: ZWDongle_1 transmit OK for 0c
2015.08.18 16:26:44 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 000400040a32022144000000070000
2015.08.18 16:26:44 5: SW: 06
2015.08.18 16:26:44 5: ZWDongle_1 dispatch 000400040a32022144000000070000
2015.08.18 16:26:44 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:0a32022144000000070000
2015.08.18 16:26:47 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 0004000406310504220007
2015.08.18 16:26:47 5: SW: 06
2015.08.18 16:26:47 5: ZWDongle_1 dispatch 0004000406310504220007
2015.08.18 16:26:47 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:06310504220007
2015.08.18 16:27:44 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 000400040a32022144000000070000
2015.08.18 16:27:44 5: SW: 06
2015.08.18 16:27:44 5: ZWDongle_1 dispatch 000400040a32022144000000070000
2015.08.18 16:27:44 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:0a32022144000000070000
2015.08.18 16:27:47 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 0004000406310504220007
2015.08.18 16:27:47 5: SW: 06
2015.08.18 16:27:47 5: ZWDongle_1 dispatch 0004000406310504220007
2015.08.18 16:27:47 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:06310504220007
2015.08.18 16:28:20 3: ZWave reading config for fibaro/fgrm222.xml
2015.08.18 16:28:44 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 000400040a32022144000000070000
2015.08.18 16:28:44 5: SW: 06
2015.08.18 16:28:44 5: ZWDongle_1 dispatch 000400040a32022144000000070000
2015.08.18 16:28:44 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:0a32022144000000070000
2015.08.18 16:28:47 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 0004000406310504220007
2015.08.18 16:28:47 5: SW: 06
2015.08.18 16:28:47 5: ZWDongle_1 dispatch 0004000406310504220007
2015.08.18 16:28:47 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:06310504220007
2015.08.18 16:29:39 2: ZWave set bw.steckdose.kreis_3 on
2015.08.18 16:29:39 5: ZWDongle_Write 00 130e032601FF250e
2015.08.18 16:29:39 5: SW: 010a00130e032601FF250e18
2015.08.18 16:29:39 5: ACK received, removing 010a00130e032601FF250e18 from sendstack
2015.08.18 16:29:39 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 011301
2015.08.18 16:29:39 5: SW: 06
2015.08.18 16:29:39 5: ZWDongle_1 dispatch 011301
2015.08.18 16:29:39 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 00130e000006
2015.08.18 16:29:39 5: SW: 06
2015.08.18 16:29:39 5: ZWDongle_1 dispatch 00130e000006
2015.08.18 16:29:39 4: ZWDongle_1 CMD:ZW_SEND_DATA ID:00 ARG:0006
2015.08.18 16:29:39 4: ZWDongle_1 transmit OK for 0e
2015.08.18 16:29:46 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 000400040a32022144000000070000
2015.08.18 16:29:46 5: SW: 06
2015.08.18 16:29:46 5: ZWDongle_1 dispatch 000400040a32022144000000070000
2015.08.18 16:29:46 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:0a32022144000000070000
2015.08.18 16:29:46 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 000400040a32022144000000070000
2015.08.18 16:29:46 5: SW: 06
2015.08.18 16:29:46 5: ZWDongle_1 dispatch 000400040a32022144000000070000
2015.08.18 16:29:46 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:0a32022144000000070000
2015.08.18 16:29:46 2: ZWave set bw.steckdose.kreis_3 off
2015.08.18 16:29:46 5: ZWDongle_Write 00 130e03260100250e
2015.08.18 16:29:46 5: SW: 010a00130e03260100250ee7
2015.08.18 16:29:46 5: ACK received, removing 010a00130e03260100250ee7 from sendstack
2015.08.18 16:29:46 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 011301
2015.08.18 16:29:46 5: SW: 06
2015.08.18 16:29:46 5: ZWDongle_1 dispatch 011301
2015.08.18 16:29:46 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 00130e000006
2015.08.18 16:29:46 5: SW: 06
2015.08.18 16:29:46 5: ZWDongle_1 dispatch 00130e000006
2015.08.18 16:29:46 4: ZWDongle_1 CMD:ZW_SEND_DATA ID:00 ARG:0006
2015.08.18 16:29:46 4: ZWDongle_1 transmit OK for 0e
2015.08.18 16:29:47 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 0004000406310504220007
2015.08.18 16:29:47 5: SW: 06
2015.08.18 16:29:47 5: ZWDongle_1 dispatch 0004000406310504220007
2015.08.18 16:29:47 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:06310504220007
2015.08.18 16:30:31 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 0004000c032503ff
2015.08.18 16:30:31 5: SW: 06
2015.08.18 16:30:31 5: ZWDongle_1 dispatch 0004000c032503ff
2015.08.18 16:30:31 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:0c ARG:032503ff
2015.08.18 16:30:31 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 0004000c03250300
2015.08.18 16:30:31 5: SW: 06
2015.08.18 16:30:31 5: ZWDongle_1 dispatch 0004000c03250300
2015.08.18 16:30:31 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:0c ARG:03250300
2015.08.18 16:30:40 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 0004000c032503ff
2015.08.18 16:30:40 5: SW: 06
2015.08.18 16:30:40 5: ZWDongle_1 dispatch 0004000c032503ff
2015.08.18 16:30:40 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:0c ARG:032503ff
2015.08.18 16:30:44 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 0004000c07600d02022503ff
2015.08.18 16:30:44 5: SW: 06
2015.08.18 16:30:44 5: ZWDongle_1 dispatch 0004000c07600d02022503ff
2015.08.18 16:30:44 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:0c ARG:07600d02022503ff
2015.08.18 16:30:44 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 000400040a32022144000000070000
2015.08.18 16:30:44 5: SW: 06
2015.08.18 16:30:44 5: ZWDongle_1 dispatch 000400040a32022144000000070000
2015.08.18 16:30:44 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:0a32022144000000070000
2015.08.18 16:30:49 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 0004000406310504220007
2015.08.18 16:30:49 5: SW: 06
2015.08.18 16:30:49 5: ZWDongle_1 dispatch 0004000406310504220007
2015.08.18 16:30:49 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:06310504220007
2015.08.18 16:30:49 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 0004000406310504220007
2015.08.18 16:30:49 5: SW: 06
2015.08.18 16:30:49 5: ZWDongle_1 dispatch 0004000406310504220007
2015.08.18 16:30:49 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:06310504220007
2015.08.18 16:30:49 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 0004000406310504220007
2015.08.18 16:30:49 5: SW: 06
2015.08.18 16:30:49 5: ZWDongle_1 dispatch 0004000406310504220007
2015.08.18 16:30:49 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:06310504220007
2015.08.18 16:30:49 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 0004000c03250300
2015.08.18 16:30:49 5: SW: 06
2015.08.18 16:30:49 5: ZWDongle_1 dispatch 0004000c03250300
2015.08.18 16:30:49 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:0c ARG:03250300
2015.08.18 16:30:52 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 0004000c07600d0202250300
2015.08.18 16:30:52 5: SW: 06
2015.08.18 16:30:52 5: ZWDongle_1 dispatch 0004000c07600d0202250300
2015.08.18 16:30:52 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:0c ARG:07600d0202250300
2015.08.18 16:31:44 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 000400040a32022144000000070000
2015.08.18 16:31:44 5: SW: 06
2015.08.18 16:31:44 5: ZWDongle_1 dispatch 000400040a32022144000000070000
2015.08.18 16:31:44 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:0a32022144000000070000
2015.08.18 16:31:47 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 0004000406310504220007
2015.08.18 16:31:47 5: SW: 06
2015.08.18 16:31:47 5: ZWDongle_1 dispatch 0004000406310504220007
2015.08.18 16:31:47 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:06310504220007

Ich hoffe das hilft weiter?

Gruß
Denny

[krikan]

mcAdd habe ich bei dem Gerät nicht gemacht.

Müsste auch "mcCapability" heißen..

Den Rest schaue ich mir später an, ob es Erkenntnisse bringt, keine Ahnung. Danke Dir.

[nightstorm99]

Hab jetzt mal ein:

Code Auswählen Erweitern

get bw.steckdose.kreis_1 mcCapability 1
get bw.steckdose.kreis_1 mcCapability 2
gemacht und er hat mir jetzt noch ein Device angelegt.

list ZWave_UNKNOWN_10_12.01:

Code Auswählen Erweitern

Internals:
   CFGFN
   DEF        ee7bb30d 3073
   IODev      ZWDongle_1
   NAME       ZWave_UNKNOWN_10_12.01
   NR         560
   STATE      off
   TYPE       ZWave
   homeId     ee7bb30d
   id         0c01
   lastMsgTimestamp 1439909030
   Readings:
     2015-08-18 16:50:34   reportedState   off
     2015-08-18 16:50:34   state           off
Attributes:
   IODev      ZWDongle_1
   classes    UNKNOWN_01 UNKNOWN_10 UNKNOWN_01 SWITCH_BINARY
   room       ZWave

Mal sehen was das nun noch ist?!?!?! 

[krikan]

Mal sehen was das nun noch ist?!?!?! 

Du wolltest Doch nicht und sag nicht ich hätte Dich gezwungen

OK, dann habe ich auch mal reingeschaut:
Hast Du bei Deinem obigen Log ab ca. 16:30 manuell geschaltet? Da sehe ich Meldungen über Zustand.
Hast Du vorher nur per Fhem geschaltet? Da sehe ich auf Anhieb "nichts" außer TRANSMIT_OK

ZWave-Geräte nur an Logs zu erforschen ist blöd!

[nightstorm99]

Ja genau, erst habe ich über FHEM geschaltet und die letzten Einträge müssten
über den Schalter am FGS222 gekommen sein.

[krikan]

Komisch: Bei manuellem Schalten gibt es einen Statusreport (auch als Multichannel) und bei Schalten über Fhem nichts!?
Denke darüber später noch einmal nach; vielleicht gibt es von anderen auch Ideen.

[krikan]

Komme auch beim nochmaligen Drüberschauen zu keinem anderem Ergebnis als oben. Der Aktor gibt laut Log keinen Statusreport bei Schalten über Fhem zurück; nur manuelles Schalten führt zu Statusänderung. Begründung dafür habe ich bei korrekter Assoziation und Konfiguration leider nicht. Zu Bodos Wunsch mag ich keine definitive Aussage treffen, dass der Fibaro besser ist. Es fällt nur auf, dass auf einen Tastendruck einmal ein Basic-Report und einmal ein MultiChannel-Report durch den Aktor kommt. Eventuell kann man daher anders als beim Philio direkt die Zuordnung korrekt vornehmen. Aber das ist eben nicht gesichert, dazu sind mir inm Log zu viele Merkwürdigkeiten (fehlende Reports).

@Denny:  Wenn das für Dich so passt, dann würde ich -außer Du hast Forschungsdrang- nichts daran ändern.

[nightstorm99]

Wenn das für Dich so passt, dann würde ich -außer Du hast Forschungsdrang- nichts daran ändern.

Naja meine Bewässerung war jetzt nur im Testbetrieb und da es im Moment aus allen Rohren regnet, brauche ich sie nicht.

Wenn ich dir noch irgendwie helfen kann, dann sag Bescheid!

Vielleicht habe ich auch bei der Konfiguration etwas falsch gemacht? Nochmal alles auf Anfang??

Wenn es morgen mal nicht regnet, schaue ich erstmal, was das neue Node (ZWave_UNKNOWN_10_12.01 ) macht!
Was sind das eigentlich für unbekannte Klassen bei dem Node?

Danke und Gruß
Denny

[krikan]

Vielleicht habe ich auch bei der Konfiguration etwas falsch gemacht? Nochmal alles auf Anfang??

Leider keine wirkliche Ahnung, sonst würde ich es Dir schreiben. Vielleicht muss man etwas mit MULTI_CHANNEL_ASSOCIATION sowie den Endpoints spielen. Aber Beides sind Themen mit denen ich mich bisher kaum praktisch beschäftigt habe.

Was sind das eigentlich für unbekannte Klassen bei dem Node?

Sollte dem hier entsprechen:
http://forum.fhem.de/index.php/topic,39525.msg318007.html#msg318007
Kannst Du ignorieren, dürfte eigentlich keine negativen Effekte haben.

[krikan]

@nightstorm99: Dei UNKOWN_xy Classes kannst Du eigentlich auch direkt aus dem Attribut Classes löschen

@Rudi: Hältst Du es für sinnvoll die UNKOWN_xy aus dem Attribut classes aufgrund der fehlenden Prüfung der Version von MULTI_CHANNEL/MULTI_INSTANCE automatisch durch Fhem zu löschen oder soll ich das besser im Wiki als Besonderheit aufnehmen? (Problem hatte ich hier im Thread http://forum.fhem.de/index.php/topic,39525.msg318007.html#msg318007 detaillierter beschrieben)

[rudolfkoenig]

Bin unentschlossen, ob wir lieber Anfaenger verwirren oder Erfahreneren Hinweise wegnehmen sollten, ich tendiere zum Letzteren, da die Hinweise sehr mager sind.

Wg. dem Link: verstehe ich es richtig, dass wir vor mcCapability die Version abfragen muessten, um die Antwort richtig zu deuten?

[krikan]

Bin unentschlossen, ob wir lieber Anfaenger verwirren oder Erfahreneren Hinweise wegnehmen sollten, ich tendiere zum Letzteren, da die Hinweise sehr mager sind.

Persönlich hätte ich lieber die UNKNOWN_xy. Ich befürchte auch, dass automatisches Entfernen bei Version 3 oder neueren zu Problemen führt.

Wg. dem Link: verstehe ich es richtig, dass wir vor mcCapability die Version abfragen muessten, um die Antwort richtig zu deuten?

Ja. Anhand der Nachrichtenlänge, die häufig der Anhaltspunkt ist, ist das mMn nicht zu unterscheiden. Es bleibt als nur Version.

Das geht auch wieder in diese Richtung: http://forum.fhem.de/index.php/topic,39810.0.html.
Ich wünsche mir häufig, dass das Device-list automatisch eine komplette Übersicht der Class-Versionen, Assoziationen und Configs enthält, wenn hier im Forum um Hilfe gebeten wird. Das würde manches vereinfachen und auch zu (meiner) ZWave-Wissensentwicklung beitragen.

Dann sind wir aber fast bei dem Thema "Interview" des Gerätes, was alle anderen ZWave-Programme machen. Ich sehe Fhem aber momentan im Vorteil, weil kein langandauerndes und fehleranfälliges Interview gemacht wird (hatte schon mal andere Meinung).

[rudolfkoenig]

Ich wünsche mir häufig, dass das Device-list automatisch eine komplette Übersicht der Class-Versionen, Assoziationen und Configs enthält, wenn hier im Forum um Hilfe gebeten wird.

Habe den ersten Schritt dafuer gemacht: "set DEVICE versionClassRequest" setzt das Attribut vclasses, siehe im Anhang die Werte fuer mein KFOB.

Weiterhin wird ab sofort set/get mit allen Parametern geloggt.

Bedeutender ist die wakeupNoMoreInformation Aenderung: wenn das Modul meint sowas schicken zu wollen, dann wird in 0.1s Intervallen geprueft, ob lastMsgTimestamp laenger als eine Sekunde zurueckliegt, und erst dann die wakeupNoMoreInformation Nachricht geschickt.
Damit kann ich vom KFOB alle Versionen problemlos abholen.
lastMsgTimestamp ist von Sekundengenauigkeit auf gettimeofday umgestellt (0.01msec auf meinem Rechner)

[krikan]

@Rudi:
Danke

Bzgl. MULTI_CHANNEL/MULTI_INSTANCE war ich gerade dabei Dir zu schreiben, dass meine Analyse vermutlich fehlerhaft war. Also das Thema bitte noch mal ruhen lassen. Danke

[krikan]

@Rudi
Die Funktion 0a für get-mcCapability gibt es in MULTI_INSTANCE/MULTI_CHANNEL V1 nicht. Die wurde erst mit V2 eingeführt. Meine Aussagen von http://forum.fhem.de/index.php/topic,39525.msg318007.html#msg318007 bezüglich V1 und mangelender Unterscheidbarkeit der Versionen sind also falsch.

Folge:
Die Auswertung des Rückgabewertes in sub ZWave_mcCapability($$) in 10_ZWave.pm ist mMn nicht optimal, da der von mir im Link dargestellte Aufbau für V2 korrekt sein sollte. In der sub werden bei Aufruf für ein existierendes Endpoint-Device die Werte für Generic/Specific als UNKOWN_xy zurückgegeben (=2 UNKOWN). Existiert das Endpoint-Device nicht, dann wird über DoTrigger $caps weitergereicht und das Endpoint-Device mit den Werten für Endpoint und Generic/Specific als UNKOWN_xy (3 UNKOWN) angelegt wird. Die UNKOWN_xy sollten eigentlich nie angelegt werden.
Mit ZWave_mcCapability($$) habe ich aber Verständnisprobleme, so dass ich befürchte, etwas nicht zu erkennen:

Code Auswählen Erweitern

my $lcaps = substr($caps, 2);
wird mMn zwar angelegt, aber nie genutzt. Warum? Überbleibsel?
Bei der Auswertung durch sub wird zudem das dynamic/identical Bit im hex-Wert für Endpoint nicht berücksichtigt/eliminert. Im Fazit nicht notwendig, nur stimmt dann die Endpoint-Nummer nicht mit der Doku überein.

[rudolfkoenig]

Die Doku zu MULTI_CHANNEL Capability Report sagt, dass es EndPoint,GenericClass,SpecificClass,Class1,Class2,usw. beinhaltet. Generic scheint immer 10 zu sein, Specific 1, damit ist aber wohl kein CommandClass gemeint.

Habe mit "get mcCapability" solange rumgespielt, bis ich zufrieden war, die ersten 2 Bytes werden jetzt nicht mehr als Klasse interpretiert.

[krikan]

GenericClass,SpecificClass kann man aus https://github.com/OpenZWave/open-zwave/blob/master/config/device_classes.xml entnehmen:
GenericClass = 10 = Binary Switch
SpecificClass = 01 = Binary Power Switch
OZW schließt aus den Generic/Specific auf Command Classes, die die Geräte haben müssen; sieht man auch in der verlinkten Datei. Da man die CommandClasses aus dem NIF lesen kann, ist mir der Sinn dieses Vorgehens unklar. Probleme wegen fehlender Command Classes in Fhem im Vergleich zu OZW sind mir bisher nicht aufgefallen.

Ist es notwendig, dass bei wakeupNoMoreInformation die CallbackIds fehlen und bei transmitOptions immer 05 statt 25 bzw. Attribut noExplorerFrames genutzt wird und bei "set DEVICE versionClassRequest" die CallbackIds fehlen? War bei wakeupNoMoreInformation vermutlich vorher auch schon so, ist mir nur nicht aufgefallen/durchgegangen .

[rudolfkoenig]

Na notwendig nicht, ich habe halt beim Umbau nicht darauf geachtet, das gleich mit umzustellen. Habe es jetzt fuer wakeupNoMoreInformation und ZWave_clockAdjust nachgeholt.

[krikan]

Danke! Sorry, schlechte Wortwahl; EF war auch noch meine Nicht-Beachtung und hast Du ja noch was gefunden.