Wechselschaltung mit Fibaro FGS223/FGS222

[rubinho]

So, da ja noch kein Silvester ist und ich heute sonst nix zutun habe, bin ich schnell in den Keller, hab mir ein Stück Kabel abgemacht und mir eine Brücke gebastelt.
Mit der hab ich dann den Schalter am FGS direkt emuliert 
Leider konnt ich nur den Kanal 2 testen, da auf Kanal 1 meine Jungs am Fernsehen waren (24"er mit Raspberry 30W Verbrauch.. wen es Interessiert )
Aber das sollte prinzipiell keinen Unterschied machen. Im Ereignislog habe ich wie vermutet die State-Änderungen mitbekommen (so wie es soll).

Hier noch der LOG Auszug....
Ansonsten guten Rutsch ins neue Jahr.

Code Auswählen Erweitern

2016.12.31 17:31:24 4: ZWDongle_Read ZWave1: rcvd 0004000c07600d0201250300 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.31 17:31:24 5: SW: 06
2016.12.31 17:31:24 5: ZWave1: dispatch 0004000c07600d0201250300
2016.12.31 17:31:24 4: CMD:APPLICATION_COMMAND_HANDLER ID:0c ARG:07600d0201250300 CB:00
2016.12.31 17:31:24 5: Triggering ZWave_SWITCH_12.02 (2 changes)
2016.12.31 17:31:24 5: Starting notify loop for ZWave_SWITCH_12.02, 2 event(s), first is off

2016.12.31 17:31:24 4: ZWDongle_Read ZWave1: rcvd 0004000c0c600d02013202213200000000 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.31 17:31:24 5: SW: 06
2016.12.31 17:31:24 5: ZWave1: dispatch 0004000c0c600d02013202213200000000
2016.12.31 17:31:24 4: CMD:APPLICATION_COMMAND_HANDLER ID:0c ARG:0c600d02013202213200000000 CB:00
2016.12.31 17:31:24 5: Triggering ZWave_SWITCH_12.02 (1 changes)
2016.12.31 17:31:24 5: Starting notify loop for ZWave_SWITCH_12.02, 1 event(s), first is power:  0 W

2016.12.31 17:31:25 4: ZWDongle_Read ZWave1: rcvd 0004000c07600d02012503ff (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.31 17:31:25 5: SW: 06
2016.12.31 17:31:25 5: ZWave1: dispatch 0004000c07600d02012503ff
2016.12.31 17:31:25 4: CMD:APPLICATION_COMMAND_HANDLER ID:0c ARG:07600d02012503ff CB:00
2016.12.31 17:31:25 5: Triggering ZWave_SWITCH_12.02 (2 changes)
2016.12.31 17:31:25 5: Starting notify loop for ZWave_SWITCH_12.02, 2 event(s), first is on

2016.12.31 17:31:28 4: ZWDongle_Read ZWave1: rcvd 0004000c07600d0201250300 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.31 17:31:28 5: SW: 06
2016.12.31 17:31:28 5: ZWave1: dispatch 0004000c07600d0201250300
2016.12.31 17:31:28 4: CMD:APPLICATION_COMMAND_HANDLER ID:0c ARG:07600d0201250300 CB:00
2016.12.31 17:31:28 5: Triggering ZWave_SWITCH_12.02 (2 changes)
2016.12.31 17:31:28 5: Starting notify loop for ZWave_SWITCH_12.02, 2 event(s), first is off

2016.12.31 17:31:28 4: ZWDongle_Read ZWave1: rcvd 0004000c0c600d02013202213200000000 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.31 17:31:28 5: SW: 06
2016.12.31 17:31:28 5: ZWave1: dispatch 0004000c0c600d02013202213200000000
2016.12.31 17:31:28 4: CMD:APPLICATION_COMMAND_HANDLER ID:0c ARG:0c600d02013202213200000000 CB:00
2016.12.31 17:31:28 5: Triggering ZWave_SWITCH_12.02 (1 changes)
2016.12.31 17:31:28 5: Starting notify loop for ZWave_SWITCH_12.02, 1 event(s), first is power:  0 W

2016.12.31 17:31:29 4: ZWDongle_Read ZWave1: rcvd 0004000c07600d02012503ff (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.31 17:31:29 5: SW: 06
2016.12.31 17:31:29 5: ZWave1: dispatch 0004000c07600d02012503ff
2016.12.31 17:31:29 4: CMD:APPLICATION_COMMAND_HANDLER ID:0c ARG:07600d02012503ff CB:00
2016.12.31 17:31:29 5: Triggering ZWave_SWITCH_12.02 (2 changes)
2016.12.31 17:31:29 5: Starting notify loop for ZWave_SWITCH_12.02, 2 event(s), first is on

2016.12.31 17:31:31 4: ZWDongle_Read ZWave1: rcvd 0004000c07600d0201250300 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.31 17:31:31 5: SW: 06
2016.12.31 17:31:31 5: ZWave1: dispatch 0004000c07600d0201250300
2016.12.31 17:31:31 4: CMD:APPLICATION_COMMAND_HANDLER ID:0c ARG:07600d0201250300 CB:00
2016.12.31 17:31:31 5: Triggering ZWave_SWITCH_12.02 (2 changes)
2016.12.31 17:31:31 5: Starting notify loop for ZWave_SWITCH_12.02, 2 event(s), first is off

2016.12.31 17:31:32 4: ZWDongle_Read ZWave1: rcvd 0004000c0c600d02013202213200000000 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.31 17:31:32 5: SW: 06
2016.12.31 17:31:32 5: ZWave1: dispatch 0004000c0c600d02013202213200000000
2016.12.31 17:31:32 4: CMD:APPLICATION_COMMAND_HANDLER ID:0c ARG:0c600d02013202213200000000 CB:00
2016.12.31 17:31:32 5: Triggering ZWave_SWITCH_12.02 (1 changes)
2016.12.31 17:31:32 5: Starting notify loop for ZWave_SWITCH_12.02, 1 event(s), first is power:  0 W

2016.12.31 17:31:33 4: ZWDongle_Read ZWave1: rcvd 0004000c07600d02012503ff (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.31 17:31:33 5: SW: 06
2016.12.31 17:31:33 5: ZWave1: dispatch 0004000c07600d02012503ff
2016.12.31 17:31:33 4: CMD:APPLICATION_COMMAND_HANDLER ID:0c ARG:07600d02012503ff CB:00
2016.12.31 17:31:33 5: Triggering ZWave_SWITCH_12.02 (2 changes)
2016.12.31 17:31:33 5: Starting notify loop for ZWave_SWITCH_12.02, 2 event(s), first is on

2016.12.31 17:31:35 4: ZWDongle_Read ZWave1: rcvd 0004000c0c600d02013202213200080000 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.12.31 17:31:35 5: SW: 06
2016.12.31 17:31:35 5: ZWave1: dispatch 0004000c0c600d02013202213200080000
2016.12.31 17:31:35 4: CMD:APPLICATION_COMMAND_HANDLER ID:0c ARG:0c600d02013202213200080000 CB:00
2016.12.31 17:31:35 5: Triggering ZWave_SWITCH_12.02 (1 changes)
2016.12.31 17:31:35 5: Starting notify loop for ZWave_SWITCH_12.02, 1 event(s), first is power:  0.8 W


[krikan]

Danke für Deine Tests und ein gutes neues Jahr!

Nach Deinen Tests und Logs behaupte ich, dass Du wohl den Durchbruch bei den automatischen, kanalweisen Meldungen des FGS223 in FHEM geschafft hast. 

Damit die Kanaele des FGS223 separat Schaltvorgaenge und Stromverbauch automatisch melden, muss also nach Inklusion ausgeführt werden:

Code Auswählen Erweitern

set <MainDevice> associationDel 1 <ControllerNodeId>
set <MainDevice> mcaAdd 1 0 <ControllerNodeId> 1

@Rudi: soll das in 10_ZWave.pm über init als device-spezifisch eingebaut werden?

Openzwave ist, wie ich heute morgen festgestellt habe, zum gleichen Ergebnis gekommen: https://groups.google.com/d/msg/openzwave/5g0-0LLN2rA/aVc9wPLWDQAJ

Was ich beim FGS223 noch nicht verstehe:
-Ist das durch den Standard gedeckt oder ein Firmwarebug?
-Wohin werden Nachrichten gemeldet, die für das root/main-Device bestimmt sind (Gesamtverbrauch, DEVICE_RESET_LOCALLY,..)?

Gruß, Christian

[rudolfkoenig]

@Rudi: soll das in 10_ZWave.pm über init als device-spezifisch eingebaut werden?

Ich habe nichts dagegen, wenn es den Anwendern hilft. Da ich aber nicht alle Details in Kopf habe, haette ich lieber einen Patch.

[krikan]

Patch kann ich in Kürze liefern. Ob es hilft, werden wir dann sehen. Bin da unsicher; darum die Frage.

[A.Harrenberg]

Hi,

What can possibly go wrong...

Vielleicht den Patch doch mal ein wenig testen lassen, falls sich bei den Associations dadurch was grundlegend verändert gibt es sonst sicherlich 'ne Menge Probleme bei entsprechenden Notify. Ich kann aber erst wieder Ende Januar testen, es sollten sich aber ein paar Freiwillige finden lassen.

Frohes neues Jahr,
Andreas.

[krikan]

Frohes neues Jahr,

Danke, auch so! 

What can possibly go wrong...

Nichts. Ich schwanke nur immer zwischen "Vereinfachung" und "nicht so viel Automatik". Bspw. durch die Automatik des Assoziieren bei der Inklusion ertappe ich mich selbst dabei, dass ich das Thema Assoziation manchmal vergesse.

Probleme können durch einen eventuellen gerätespezifischen Patch höchstens bei Neu-Inklusionen des FGS223 entstehen; und auch das nur sehr untergeordnet. Darum halte ich es eigentlich für ungefährlich.

Gruß, Christian

[A.Harrenberg]

Hi,

ach so, das soll ein Gerätespezifischer Patch werden... Na dann ,-)

Das Thema Assoziationen müsste ich mir beim Z-Uno auch noch mal ansehen. Das Ding macht ja teilweise auch merkwürdige Sachen, je nachdem wie man die Assoziationen setzt.

Gruß,
Andreas

[rubinho]

Moin,

ich hab hier zwar nix zu melden, jedoch halte ich diesen gerätespezifischen Patch auch für sinnvoll.
Wer will schon einen 2 Kanal Aktor mit halber Funktion betreiben ?!

Ansonsten glaube ich nämlich, dass jeder Zweite, der das Teil in Fhem einbinden will, euch hier im Forum mit Fragen löchert.
Und das glaube ich, will keiner

Hat jetzt eigentlich jemand verstanden, was sich Fibaro dabei gedacht hat ?
Mir ist die Logik noch nicht so klar. Durch das mcaAdd 1 0 1 (1) wird doch laut diversen Informationen der Endpoint 1 angesprochen, was ja laut dem Verhalten des FGS nicht sein kann.
Bevor ich das (durch Zufall) herrausgefunden hatte, hatte ich zuerst noch ein mcaAdd 1 0 1 (3) ausprobiert und da hat sich nur der Endpoint 1 gemeldet (Aber bereits korrekterweise am Subchannel 1 in Fhem).
Irgendwie ist die Fibaro Dokumentation gerade was die Assoziationen angeht sehr dürftig.

Gruß
Rubinho

[jeep]

Irgendwie ist die Fibaro Dokumentation gerade was die Assoziationen angeht sehr dürftig.

Hi,

das kann  ich so nicht stehen lassen.
Ich habe devices von Fibaro, Popp, Aeotec, Zwave.me, zipato und Fibaro hat von allen die beste Dokumentation. Ließ Dir bitte die Seite 13 (ist eine ganze DIN A4 Seite über Assoziationen des FGS-2x3 ) der Dokumentation durch. Ich finde mehr braucht man nicht.
Ich hatte noch nie Probleme mit einer Assoziation mit FHEM und Fibaro.

Grüße, Josef

[rubinho]

Hallo jeep

Ich will dir ungern widersprechen, vielleicht bin ich auch zu blöd (Will ich garnicht ausschließen), aber was die Problematik in diesem Thread angeht (Multichannel, Endpoints ...), wird in der Doku nicht mal annähernd besprochen.
Diese Multichannel Addressierung mit ist doch kein Fhem Konstrukt sondern ein Z-Wave Standard, oder steh ich jetzt auf dem Schlauch.

Gruß
Rubinho

[jeep]

Hallo jeep

Ich will dir ungern widersprechen, vielleicht bin ich auch zu blöd (Will ich garnicht ausschließen), aber was die Problematik in diesem Thread angeht (Multichannel, Endpoints ...), wird in der Doku nicht mal annähernd besprochen.
Diese Multichannel Addressierung mit ist doch kein Fhem Konstrukt sondern ein Z-Wave Standard, oder steh ich jetzt auf dem Schlauch.

Gruß
Rubinho

Hi,

da habe ich scheinbar was losgetreten und ich nehme gerne den shitstorm auf mich , aber dass was Du suchst wirst Du in keiner einzigen ZWave-Geräte Dokumentation finden.
Also ich würde sagen mit 1 Fuß auf dem Schlauch. Natürlich ist Multichannel Addresierung, kein FHEM Konstrukt,  eher ein FHEM Problem, aber wie Du siehst, die Jungs arbeiten kontinuierlich daran und sind wahnsinnig schnell mit Updates.   

Mir ging es nur um die Klarstellung der Dokumentation und um nichts anderes.

Grüße, Josef

[krikan]

Hat jetzt eigentlich jemand verstanden, was sich Fibaro dabei gedacht hat ?

Wenn mir das jemand erklären könnte wäre ich sehr dankbar.
Den Standard kann man in http://zwavepublic.com/sites/default/files/SDS12657-12%20-%20Z-Wave%20Command%20Class%20Specification%20A-M.pdf unter "Multi Channel Association Command Class" nachlesen. Habe das gefühlte 1000x getan und jedes Mal, wenn ich meine es verstanden zu haben, kommt irgendein Gerät mit für mich seltsamen Verhalten (hier: FGS223)

Mir ist die Logik noch nicht so klar. Durch das mcaAdd 1 0 1 (1) wird doch laut diversen Informationen der Endpoint 1 angesprochen, was ja laut dem Verhalten des FGS nicht sein kann

1 = Assoziationsgruppe 1 des FGS ("lifeline")
0 = Trenner
1 = ControllerNodeId
1 = Endpoint 1 des Controllers

Natürlich ist Multichannel Addresierung, kein FHEM Konstrukt,  eher ein FHEM Problem,

Bin mir eben unsicher, ob das ein FHEM Problem oder ein Fibaro Problem ist.

Grundfragen für mich bleiben:

Was ich beim FGS223 noch nicht verstehe:
-Ist das durch den Standard gedeckt oder ein Firmwarebug?
-Wohin werden Nachrichten gemeldet, die für das root/main-Device bestimmt sind (Gesamtverbrauch, DEVICE_RESET_LOCALLY,..)?

Gruß, Christian

PS: Was über eine Assoziationgruppe an Commands verschickt wird, kann man mit "get <device> associationGroupCmdList <groupId>" bei ZWavePlus-Geräten herausfinden. Aber mWn nicht, ob es mit MultiChannelNachrichten kommt.

[rubinho]

Hi,

da habe ich scheinbar was losgetreten und ich nehme gerne den shitstorm auf mich , aber dass was Du suchst wirst Du in keiner einzigen ZWave-Geräte Dokumentation finden.

Von mir gibts kein Shitstorm, warum auch. Hast ja nix schlimmes geschrieben. Und das andere Hersteller diese Daten auch nicht in ihrer Doku stehen haben, bezweifel ich überhaupt nicht. Ich wollte damit Fibaro nicht an den Pranger stellen, sondern nur mitteilen, dass unsere benötigten Infos nicht in der Doku stehen. Mag sein, dass meine Aussage zu allgemein gehalten war, was die Doku angeht.


@Krikan
Mir ist die grundsätzliche Logik der Assoziationsgrouppen klar (Denke ich  ).
Wo es bei mir hängt, ist die Zuweisung des Endpoint 1 in der Multichannel Assoziationsgruppe 1.
Da hast du ja, glaub ich, das Gleiche Verständnisproblem.

Ich hätte jetzt erwartet, dass nur die Events des Endpoint 1 in Richtung Fhem gesendet werden, aber das passiert nur, wenn ich den Wert 3 (mcaAdd 1 0 1 3) angebe und in diesem Fall wurden nur die Events von Endpoint 1 übermittelt.
Es wäre jetzt hilfreich wenn man wüsste welche Zahl (Ich meine die Endpointziffer) was bedeutet.
1 = Alle Endpoints ?
3 = Endpoint 1 ?
? = Endpoint 2

Gruß
Rubinho

[krikan]

Ich hätte jetzt erwartet, dass nur die Events des Endpoint 1 in Richtung Fhem gesendet werden, aber das passiert nur, wenn ich den Wert 3 (mcaAdd 1 0 1 3) angebe und in diesem Fall wurden nur die Events von Endpoint 1 übermittelt.
Es wäre jetzt hilfreich wenn man wüsste welche Zahl (Ich meine die Endpointziffer) was bedeutet.
1 = Alle Endpoints ?
3 = Endpoint 1 ?
? = Endpoint 2

Bin mir nicht sicher, ob wir nicht aneinander vorbeischreiben. Eigentlich müsste ich die raw-Messages bei den jeweiligen Assoziationen sehen, um zu erkennen, was genau gemeldet wird. Momentan ist die Oberflaechenanzeige von FHEM bei MultiChannel-Nachrichten "anwenderorientiert" und hilft im Detail nicht, um konkrete Aussagen treffen zu können.

[rubinho]

Bin mir nicht sicher, ob wir nicht aneinander vorbeischreiben.

Das Gefühl hab ich auch so langsam 

Da ich nicht so tief in der Z-Wave Materie stecke wie manch Anderer hier und ich anscheinend zu unnötigen Verwirrungen betreige, werde ich nun kein Störfeuer mehr verursachen  (Nicht böse gemeint)

Wenn ich noch bei irgendwas helfen/testen kann, einfach bescheid geben.