Fibaro fgs-223 wird irgendwie seltsam eingebunden

[Cyber1000]

Hallo,

Ich hab zwar schon ein wenig herumgesucht, der fgs-223 dürfte sich auch öfters seltsam Verhalten (z.B. hier https://forum.fhem.de/index.php/topic,76432.0.html) aber bei mir sieht das wieder ein wenig anders aus.

Vorgangsweise:

• Ich hab mich vor einiger Zeit schon mit fhem gespielt, aber noch nicht richtig Zeit, die "einfachen" Schalter/Stecker funkionierten aber und so hab ich eine fhem.cfg aufbewahrt
• Raspi mit fhem 5.8 komplett neu aufgesetzt
• Den fgs-223 entfernt, damit ich ihn neu einbinden kann
• fgs-223 neu einbinden
• und ich hatte wieder genau die gleichen Namen (3 Geräte) und das Verhalten

Namen sind ZWave_Node_4.1 (das Hauptgerät), ZWave_SWITCH_BINARY_4 (S1), ZWave_10_4.02 (S2). Also in anderen Threads waren das teilweise andere Namensschemen, hat wer eine Idee wieso bei mir jedes dieser 3 Geräte (die ja eigentlich nur einen einzigen fgs-223 darstellen) ein anderes Namensschema hat?

• Mein Hauptgerät hat das Symbol, das den Status von Q1 anzeigt, außerdem wird hier der Verbrauch von Q1 angezeigt, ich kann aber nicht schalten.
• Mein S1 kann geschalten werden, hat aber keinen Verbrauch in der Anzeige. Wenn ich hier schalte, wird mir der gleiche Zustand im Hauptgerät angezeigt.
• Mein S2 hat Verbrauch und kann geschalten werden

Also ich würde mir eher erwarten, dass das Hauptgerät gar keinen Verbrauch/Status anzeigt, obwohl das jetzt eigentlich egal wäre. Aber bei meinem S1 würde ich mir auf jeden Fall die Energiereadings erwarten, so wie sie auch direkt in S2 stehen. Sollte das so sein, kommt mir irgendwie eigenartig vor?
Wie bekomme ich die Energiereadings in S1, ist das Script für fgs-223 falsch?

Also wie gesagt komplett neues fhem 5.8 (dieser patch dürfte da schon drin sein: https://forum.fhem.de/index.php/topic,64367.0.html), allerdings mit übertragener fhem.cfg.

Löschen der Switches und Neu anlegen hab ich sicher schon 3 mal gemacht, kommt immer wieder das gleiche ...

Danke!

Zum Abschluss noch ein log der Inklusion:

Code Auswählen Erweitern

2017.10.26 21:52:23 2: autocreate: define ZWave_SWITCH_BINARY_4 ZWave c732d821 4 5e8672255a5985735670328e60227571987a5bef26
2017.10.26 21:52:23 2: autocreate: define FileLog_ZWave_SWITCH_BINARY_4 FileLog ./log/ZWave_SWITCH_BINARY_4-%Y.log ZWave_SWITCH_BINARY_4
2017.10.26 21:52:23 3: ZWave get ZWave_SWITCH_BINARY_4 versionClass ALARM
2017.10.26 21:52:23 3: ZWave get ZWave_SWITCH_BINARY_4 versionClass APPLICATION_STATUS
2017.10.26 21:52:23 3: ZWave get ZWave_SWITCH_BINARY_4 versionClass ASSOCIATION
2017.10.26 21:52:23 3: ZWave get ZWave_SWITCH_BINARY_4 versionClass ASSOCIATION_GRP_INFO
2017.10.26 21:52:23 3: ZWave get ZWave_SWITCH_BINARY_4 versionClass CENTRAL_SCENE
2017.10.26 21:52:23 3: ZWave get ZWave_SWITCH_BINARY_4 versionClass CONFIGURATION
2017.10.26 21:52:23 3: ZWave get ZWave_SWITCH_BINARY_4 versionClass CRC_16_ENCAP
2017.10.26 21:52:23 3: ZWave get ZWave_SWITCH_BINARY_4 versionClass DEVICE_RESET_LOCALLY
2017.10.26 21:52:23 3: ZWave get ZWave_SWITCH_BINARY_4 versionClass FIRMWARE_UPDATE_MD
2017.10.26 21:52:23 3: ZWave get ZWave_SWITCH_BINARY_4 versionClass MANUFACTURER_SPECIFIC
2017.10.26 21:52:23 3: ZWave get ZWave_SWITCH_BINARY_4 versionClass METER
2017.10.26 21:52:23 3: ZWave get ZWave_SWITCH_BINARY_4 versionClass MULTI_CHANNEL
2017.10.26 21:52:23 3: ZWave get ZWave_SWITCH_BINARY_4 versionClass MULTI_CHANNEL_ASSOCIATION
2017.10.26 21:52:23 3: ZWave get ZWave_SWITCH_BINARY_4 versionClass POWERLEVEL
2017.10.26 21:52:23 3: ZWave get ZWave_SWITCH_BINARY_4 versionClass PROTECTION
2017.10.26 21:52:23 3: ZWave get ZWave_SWITCH_BINARY_4 versionClass SECURITY
2017.10.26 21:52:23 3: ZWave get ZWave_SWITCH_BINARY_4 versionClass SWITCH_BINARY
2017.10.26 21:52:23 3: ZWave get ZWave_SWITCH_BINARY_4 versionClass SWITCH_MULTILEVEL
2017.10.26 21:52:23 3: ZWave get ZWave_SWITCH_BINARY_4 versionClass VERSION
2017.10.26 21:52:23 3: ZWave get ZWave_SWITCH_BINARY_4 versionClass ZWAVEPLUS_INFO
2017.10.26 21:52:23 1: ZWAVE INIT: get ZWave_SWITCH_BINARY_4 versionClassAll: working the background, check the vclasses attribute
2017.10.26 21:52:23 3: ZWave set ZWave_SWITCH_BINARY_4 associationAdd 1 1
2017.10.26 21:52:23 3: ZWave get ZWave_SWITCH_BINARY_4 model
2017.10.26 21:52:23 3: ZWave get ZWave_SWITCH_BINARY_4 mcEndpoints
2017.10.26 21:52:23 3: UNDEFINED ZWave_Node_4.1 ZWave c732d821 1025, please define it. Triggered by 0004100407600d01012503ff.
2017.10.26 21:52:23 2: autocreate: define ZWave_Node_4.1 ZWave c732d821 1025
2017.10.26 21:52:23 2: autocreate: define FileLog_ZWave_Node_4.1 FileLog ./log/ZWave_Node_4.1-%Y.log ZWave_Node_4.1
2017.10.26 21:52:23 2: ZWDongle_ProcessSendStack: no ACK, resending message 0105004a0502b7
2017.10.26 21:52:23 2: ZWDongle_ProcessSendStack: no ACK, resending message 0105004a0502b7
2017.10.26 21:52:28 2: ZWave: No ACK from ZWave_SWITCH_BINARY_4 after 5s for sentackget:1304038613702506
2017.10.26 21:52:30 3: ZWave got config for fibaro/fgs223.xml from ./FHEM/lib/openzwave_deviceconfig.xml.gz
2017.10.26 21:52:30 3: ZWave set ZWave_SWITCH_BINARY_4 associationDel 1 1
2017.10.26 21:52:30 3: ZWave set ZWave_SWITCH_BINARY_4 mcaAdd 1 0 1 1
2017.10.26 21:52:30 3: ZWave get ZWave_SWITCH_BINARY_4 mcCapability 1
2017.10.26 21:52:30 3: ZWave get ZWave_SWITCH_BINARY_4 mcCapability 2
2017.10.26 21:52:30 2: autocreate: define ZWave_10_4.02 ZWave c732d821 1026 5e862585598e32ef26
2017.10.26 21:52:30 2: autocreate: define FileLog_ZWave_10_4.02 FileLog ./log/ZWave_10_4.02-%Y.log ZWave_10_4.02

[krikan]

FHEM wird kontinuierlich weiterentwickelt und das FHEM 5.8 Installationspaket ist ohne Aktualierung über update "veraltet".
Bitte "update" und danach "shutdown restart" ausführen.

Wenn Du dann die Geraete-Anlage noch einmal ausführst, solltest Du eine konsistente Device-Bennung erhalten.
Zu den Energy-Readings würde ich gerne weiterschreiben, wenn es danach bei Dir nicht auch automatisch funktioniert. Ich habe hier eine Konfiguration, die Energy nur in den Endpoint-Devices liefert und nicht im Hauptdevice.

[Cyber1000]

Danke für die schnelle Antwort, da muß ich mich wohl noch ein wenig einlesen, ging davon aus, dass die latest stable reichen müsste.
Ich bin vor ein paar Tagen von der manuellen Installation auf https://debian.fhem.de/ ausgegangen, hab jetzt die 3 Geräte und auch die Logs durch delete device in der Weboberfläche wieder entfernt, ein "update" und nach der Zeile "finished update" ein "shutdown restart" gemacht. Danach den fgs-223 wieder eingebunden.

Es hat sich diesmal etwas geändert und es ist auch eine Spur besser, aber noch nicht ganz:

• Die Namen sind wieder die gleichen, obwohl sie aus der fhem.cfg heraussen waren. Werden die Namen vielleicht noch irgendwo anders gemerkt? Andererseits die Namen würd ich sowieso umbenenen, ZWave_SWITCH_BINARY_4 ist auch nicht besonders eingänglich
• Die Energiereadings sind jetzt wie gehofft auf den Enpoint devices
• Jetzt hat Hauptschalter den toggle zum Schalten für S1 und ich kann das Endpoint-Device für S1 nicht mehr direkt schalten. Wenn ich am Hauptgerät schalte, wird aber das Licht von S1 eingeschalten und ich seh auch den Status im Endpoint Device. Das war vor dem Update genau umgekehrt
• Das Endpoint Gerät für S2 kann ich direkt schalten und es hat wie gesagt auch die Energiereadings

Also wie gesagt, die Namen sind jetzt nicht so wichtig, auch wenns interessant wäre, was da los ist. Die power-readings sind schon mal an der richtigen Stelle, die Schalter würd ich mir an den Endpoint Geräten erwarten (und nicht nur am hauptgerät und an S2), dann bräuchte ich nur die beiden Endpoint Geräte in meiner Raumliste anzeigen und das Hauptgerät könnte versteckt bleiben.

Sieht in meiner Weboberfläche so aus: siehe Bild
Der mittlere Eintrag ist das Hauptgerät.

Hier noch mein aktuelles Inklusionslog

Code Auswählen Erweitern

2017.10.27 10:51:13 2: autocreate: define ZWave_SWITCH_BINARY_4 ZWave c732d821 4 5e8672255a5985735670328e60227571987a5bef26
2017.10.27 10:51:13 2: autocreate: define FileLog_ZWave_SWITCH_BINARY_4 FileLog ./log/ZWave_SWITCH_BINARY_4-%Y.log ZWave_SWITCH_BINARY_4
2017.10.27 10:51:14 3: ZWave get ZWave_SWITCH_BINARY_4 versionClass ALARM
2017.10.27 10:51:14 3: ZWave get ZWave_SWITCH_BINARY_4 versionClass APPLICATION_STATUS
2017.10.27 10:51:14 3: ZWave get ZWave_SWITCH_BINARY_4 versionClass ASSOCIATION
2017.10.27 10:51:14 3: ZWave get ZWave_SWITCH_BINARY_4 versionClass ASSOCIATION_GRP_INFO
2017.10.27 10:51:14 3: ZWave get ZWave_SWITCH_BINARY_4 versionClass CENTRAL_SCENE
2017.10.27 10:51:14 3: ZWave get ZWave_SWITCH_BINARY_4 versionClass CONFIGURATION
2017.10.27 10:51:14 3: ZWave get ZWave_SWITCH_BINARY_4 versionClass CRC_16_ENCAP
2017.10.27 10:51:14 3: ZWave get ZWave_SWITCH_BINARY_4 versionClass DEVICE_RESET_LOCALLY
2017.10.27 10:51:14 3: ZWave get ZWave_SWITCH_BINARY_4 versionClass FIRMWARE_UPDATE_MD
2017.10.27 10:51:14 3: ZWave get ZWave_SWITCH_BINARY_4 versionClass MANUFACTURER_SPECIFIC
2017.10.27 10:51:14 3: ZWave get ZWave_SWITCH_BINARY_4 versionClass METER
2017.10.27 10:51:14 3: ZWave get ZWave_SWITCH_BINARY_4 versionClass MULTI_CHANNEL
2017.10.27 10:51:14 3: ZWave get ZWave_SWITCH_BINARY_4 versionClass MULTI_CHANNEL_ASSOCIATION
2017.10.27 10:51:14 3: ZWave get ZWave_SWITCH_BINARY_4 versionClass POWERLEVEL
2017.10.27 10:51:14 3: ZWave get ZWave_SWITCH_BINARY_4 versionClass PROTECTION
2017.10.27 10:51:14 3: ZWave get ZWave_SWITCH_BINARY_4 versionClass SECURITY
2017.10.27 10:51:14 3: ZWave get ZWave_SWITCH_BINARY_4 versionClass SWITCH_BINARY
2017.10.27 10:51:14 3: ZWave get ZWave_SWITCH_BINARY_4 versionClass SWITCH_MULTILEVEL
2017.10.27 10:51:14 3: ZWave get ZWave_SWITCH_BINARY_4 versionClass VERSION
2017.10.27 10:51:14 3: ZWave get ZWave_SWITCH_BINARY_4 versionClass ZWAVEPLUS_INFO
2017.10.27 10:51:14 1: ZWAVE INIT: get ZWave_SWITCH_BINARY_4 versionClassAll: working in the background, check the vclasses attribute
2017.10.27 10:51:14 3: ZWave set ZWave_SWITCH_BINARY_4 associationAdd 1 1
2017.10.27 10:51:14 3: ZWave get ZWave_SWITCH_BINARY_4 model
2017.10.27 10:51:14 3: ZWave get ZWave_SWITCH_BINARY_4 mcEndpoints
2017.10.27 10:51:14 3: UNDEFINED ZWave_Node_4.1 ZWave c732d821 1025, please define it. Triggered by 0004100407600d01012503ff.
2017.10.27 10:51:14 2: autocreate: define ZWave_Node_4.1 ZWave c732d821 1025
2017.10.27 10:51:14 2: autocreate: define FileLog_ZWave_Node_4.1 FileLog ./log/ZWave_Node_4.1-%Y.log ZWave_Node_4.1
2017.10.27 10:51:14 2: ZWDongle_ProcessSendStack: no ACK, resending message 0105004a0502b7
2017.10.27 10:51:19 2: ZWave: No ACK from ZWave_SWITCH_BINARY_4 after 5s for sentackget:1304038613222502
2017.10.27 10:51:24 3: ZWave got config for fibaro/fgs223.xml from ./FHEM/lib/openzwave_deviceconfig.xml.gz
2017.10.27 10:51:24 3: ZWave set ZWave_SWITCH_BINARY_4 associationDel 1 1
2017.10.27 10:51:24 3: ZWave set ZWave_SWITCH_BINARY_4 mcaAdd 1 0 1 1
2017.10.27 10:51:24 3: ZWave get ZWave_SWITCH_BINARY_4 mcCapability 1
2017.10.27 10:51:24 3: ZWave get ZWave_SWITCH_BINARY_4 mcCapability 2
2017.10.27 10:51:25 2: autocreate: define ZWave_SWITCH_BINARY_4.02 ZWave c732d821 1026 5e862585598e32ef26
2017.10.27 10:51:25 2: autocreate: define FileLog_ZWave_SWITCH_BINARY_4.02 FileLog ./log/ZWave_SWITCH_BINARY_4.02-%Y.log ZWave_SWITCH_BINARY_4.02

[krikan]

Latest stable von fhem.de genügt nicht; ist zumeist einen Tag später überholt.
Bei der Installation über das debian.fhem.de - Package installiert man afaik immer ein nightly. Das sollte immer aktuell sein.

Da sich das Namensschema bei Dir nicht geändert hat, vermute ich fast, dass Du bereits das nightly hattest. Kann mir aber die seltsame Benennung bei Dir nicht erklären. Habe gerade bei mir mit einem FGS-223 getestet und es kommen die korrekten Devicenamen:

Code Auswählen Erweitern

ZWave_SWITCH_BINARY_39
ZWave_SWITCH_BINARY_39.01
ZWave_SWITCH_BINARY_39.02
Eventuell kommt es aufgrund von Kommunikationsstörungen (ZWDongle_ProcessSendStack: no ACK, resending message..) zu dem Problem. Könnte man ggfs. im verbose 5-log erkennen.

Zur Kontrolle der korrekten Device-Anlage bräuchte ich von allen Devices bitte die Ausgabe von list, wie hier beschrieben: https://wiki.fhem.de/wiki/Z-Wave#Welche_Infos_sollten_Anfragen_im_ZWave-Forum_enthalten.3F

Wie sich Hauptdevice und Endpoint-Device 01 zueinander verhalten ist aktor, assoziations- und konfigurationsabhängig. Kommt aus der Historie von ZWave. Damit musst Du ein wenig spielen und das für Dich gewünschte Verhalten einrichten. Der ZWave-Standard lässt den Herstellern beim Verhältnis Haupt- zu Endpointdevice relativ große Freiheiten.

Bei mir probiere ich aktuell folgende Assoziation aus:

Code Auswählen Erweitern

set <device> mcaAdd 1 0 1 0
und habe zuvor die standardmäßige Assoziation gelöscht

Code Auswählen Erweitern

set <device> mcaDel 1 0 1 1
(Bitte kontrolliere immer, ob die Assoziationen korrekt gesetzt wurden.)

Kannst ja einmal testen, ob Dir das besser gefällt.

[Cyber1000]

Bei der Installation über das debian.fhem.de - Package installiert man afaik immer ein nightly. Das sollte immer aktuell sein.

Ja da hatte ich wohl doch ein nightly da ich ja über debian.fhem.de gegangen bin, zumindest ein nightly das etwa eine Woche alt war.

Eventuell kommt es aufgrund von Kommunikationsstörungen (ZWDongle_ProcessSendStack: no ACK, resending message..) zu dem Problem. Könnte man ggfs. im verbose 5-log erkennen.

Ja der fgs-223 hat ein paar m Entfernung zur Zentrale, ist allerdings in der neighborList und es sind auch andere z-wave Geräte rundherum. Aber ich werd mal verbose 5 probieren.

Wie sich Hauptdevice und Endpoint-Device 01 zueinander verhalten ist aktor, assoziations- und konfigurationsabhängig.

Aber müsste das nicht fhem schon "richtig" machen, ich denke bei einem fgs-223 ist für die meisten das richtige Verhalten: Energiereadings und Schaltfunktion sind in den jeweiligen Endpoints.

von allen Devices bitte die Ausgabe von list

Seh ich mir heute oder morgen an

set <device> mcaAdd 1 0 1 0

Bitte um kurze Erläuterung (oder gute Links), im fhem-wiki find ich zu mca und Multi-Channel überhaupt nichts, wenn ich nach "mca" Suche. Und ich bin noch ziemlich am Anfang mit der ganzen Sache

Beim Herumsuchen hab ich jetzt folgendes gefunden und nach Löschen meiner 2 Endpoint Devices auf mein Hauptdevice angewendet:

Code Auswählen Erweitern

set <device> mcCreateAll

Danach hatte ich auf einmal zwei Endpoint devices mit richtigem Namen - ZWave_SWITCH_BINARY_4.01 und ZWave_SWITCH_BINARY_4.02. Beide lassen sich schalten und beide haben die richtigen Energiereadings. (also so wie ich mir das vorgestellt habe, das Hauptdevice hat zwar weiterhin einen Schalter, der auch S1 mitschaltet, aber das Hauptdevice würd ich nicht benutzen)

Trotzdem will ich das weiter analysieren, irgendwie ist das seltsam und wer weiß was sonst noch für Probleme auftreten in Zukunft dadurch.

Danke schonmal für die schnellen Antworten!

[krikan]

Ja da hatte ich wohl doch ein nightly da ich ja über debian.fhem.de gegangen bin, zumindest ein nightly das etwa eine Woche alt war.

Zur Klarstellung: stable/nightly ist für FHEM eigentlich ein falscher Begriff. Die Installationspakete auf fhem.de sind nur Ausgangspunkte für den Updateprozess (siehe NOTE auf  https://fhem.de/#Download).

Ja der fgs-223 hat ein paar m Entfernung zur Zentrale, ist allerdings in der neighborList und es sind auch andere z-wave Geräte rundherum. Aber ich werd mal verbose 5 probieren.

neighborList, Entfernung, Geräteanzahl sind nur Hinweise. Funk ist relativ anfällig für Störeinflüsse.
Bevor Du zu viel Arbeit in verbose 5 Log steckst: Mich interessiert das nur, wenn es Dir noch hilft oder ein reproduzierbares Problem in FHEM vorliegt. Letzteres erkenne ich noch(?) nicht.

Aber müsste das nicht fhem schon "richtig" machen, ich denke bei einem fgs-223 ist für die meisten das richtige Verhalten: Energiereadings und Schaltfunktion sind in den jeweiligen Endpoints.

Behaupte FHEM macht das richtig, wenn es keine Störungen bei der Einbindung -wie bei Dir- gibt. Denn bei Dir funktioniert es grundsätzlich auch:

Danach hatte ich auf einmal zwei Endpoint devices mit richtigem Namen - ZWave_SWITCH_BINARY_4.01 und ZWave_SWITCH_BINARY_4.02. Beide lassen sich schalten und beide haben die richtigen Energiereadings. (also so wie ich mir das vorgestellt habe, das Hauptdevice hat zwar weiterhin einen Schalter, der auch S1 mitschaltet, aber das Hauptdevice würd ich nicht benutzen)

Im Prinzip setzt FHEM bei der Inklusion des FGS223 den mcCreateAll Befehl automatisch ab. Dort hakt es bei Deinen beiden Versuchen immer. Genaueres könnte ich eventuell eben am log und list erkennen.

Bitte um kurze Erläuterung (oder gute Links), im fhem-wiki find ich zu mca und Multi-Channel überhaupt nichts, wenn ich nach "mca" Suche.

Multi Channel Association traue ich mich nicht zu erklären und hadere selbst noch mit einigen Dingen, wenn ich Standard und Umsetzung bei Geräten sehe.
Aus erster Hand: http://zwavepublic.com/sites/default/files/command_class_specs_2017A/SDS13782-4%20Z-Wave%20Management%20Command%20Class%20Specification.pdf Pdf-Seite 113 ff.
Und natürlich den kurzen commandref-Eintrag zum Befehlsaufbau.

Du kannst auch gefahrlos mit den beiden mcaAdd-Varianten spielen und Dir die Auswirkungen im Event-Monitor bei Schaltvorgängen anschauen.

[Cyber1000]

Hi,

Hat jetzt leider doch ein wenig länger gedauert, dass ich mir das nochmal ansehn konnte.
Ich hab heute an anderer Stelle ebenfalls einen fgs-223 eingebaut und der hat nach der Inklusion sofort wie für mich erwartet funktioniert:

• Namen ZWave_SWITCH_BINARY_11, ZWave_SWITCH_BINARY_11.01, ZWave_SWITCH_BINARY_11.02
• Schalten und Energiereadings liegen direkt bei den Subreadings (ok das Hauptgerät schaltet auch das erste Gerät, aber das ist prinzipiell egal)

Ok, das neue  fgs-223 liegt im Raum direkt neben meiner Zentrale, also möglich wär das schon das mit der Störung. Hab jetzt beim "fehlerhaften" fgs-223 nochmal die Antenne ein wenig anders ausgerichtet (ok ein wenig verzweifelte Versuche muss ich zugeben), aber nach wie vor hab ich hier die falsche Benennung und das andere Verhalten.

Hier einmal der list Befehl:
- für Namen ZWave_SWITCH_BINARY_04:

Code Auswählen Erweitern

Internals:
   CFGFN
   DEF        c732d821 4
   Dongle_ZWAVE_MSGCNT 46
   Dongle_ZWAVE_RAWMSG 00040004057006140102
   Dongle_ZWAVE_TIME 2017-11-10 21:50:02
   IODev      Dongle_ZWAVE
   LASTInputDev Dongle_ZWAVE
   MSGCNT     46
   NAME       ZWave_SWITCH_BINARY_4
   NR         186
   STATE      off
   TYPE       ZWave
   ZWaveSubDevice no
   cmdsPending 0
   endpointChildren ZWave_Node_4.1,ZWave_SWITCH_BINARY_4.02
   homeId     c732d821
   isWakeUp
   lastMsgSent 1510347038.38291
   nodeIdHex  04
   READINGS:
     2017-11-10 21:49:31   assocGroup_1    Max 1 Nodes
     2017-11-10 21:49:31   assocGroup_2    Max 5 Nodes
     2017-11-10 21:49:31   assocGroup_3    Max 5 Nodes
     2017-11-10 21:49:31   assocGroup_4    Max 5 Nodes
     2017-11-10 21:49:31   assocGroup_5    Max 5 Nodes
     2017-11-10 21:49:30   assocGroups     5
     2017-11-10 21:49:55   configAssociationsInZWaveNetwork27 15
     2017-11-10 21:49:55   configFirstChannelEnergyReports 100
     2017-11-10 21:49:55   configFirstChannelMinimalTimeBetween51 10
     2017-11-10 21:49:56   configFirstChannelOperatingMode StandardOperation
     2017-11-10 21:49:56   configFirstChannelPowerReports 20
     2017-11-10 21:49:56   configFirstChannelPulseTimeForFlashing13 5
     2017-11-10 21:49:56   configFirstChannelReactionToSwitchFor11 CancelModeAndSetTargetState
     2017-11-10 21:49:57   configFirstChannelTimeParameterFor12 50
     2017-11-10 21:49:57   configFlashingAlarmDuration 600
     2017-11-10 21:49:57   configFlashingModeReport Disabled
     2017-11-10 21:49:57   configMeasuringEnergyConsumedByThe60 functionInactive
     2017-11-10 21:49:57   configPeriodicEnergyReports 3600
     2017-11-10 21:49:58   configPeriodicPowerReports 3600
     2017-11-10 21:49:58   configReactionToCOCO2SmokeAlarm Flash
     2017-11-10 21:49:58   configReactionToFloodAlarm TurnOFF
     2017-11-10 21:49:58   configReactionToGeneralAlarm Flash
     2017-11-10 21:49:58   configReactionToHeatAlarm TurnOn
     2017-11-10 21:49:59   configS1AssociationsSentTo2ndAnd3rd30 0
     2017-11-10 21:49:59   configS1SwitchDoubleClickValueSent33 99
     2017-11-10 21:49:59   configS1SwitchOFFValueSentTo2ndAnd3rd32 0
     2017-11-10 21:49:59   configS1SwitchONValueSentTo2ndAnd3rd31 255
     2017-11-10 21:49:59   configS1SwitchScenesSent 0
     2017-11-10 21:50:00   configS2AssociationsSentTo4thAnd5th35 0
     2017-11-10 21:50:00   configS2SwitchDoubleClickValueSent38 99
     2017-11-10 21:50:00   configS2SwitchOFFValueSentTo4thAnd5th37 0
     2017-11-10 21:50:00   configS2SwitchONValueSentTo4thAnd5th36 255
     2017-11-10 21:50:00   configS2SwitchScenesSent 0
     2017-11-10 21:50:01   configSavingStateBeforePowerFailure StateSavedAtPowerFailureAll1
     2017-11-10 21:50:01   configSecondChannelEnergyReports 100
     2017-11-10 21:50:01   configSecondChannelMinimalTimeBetween55 10
     2017-11-10 21:50:01   configSecondChannelOperatingMode StandardOperation
     2017-11-10 21:50:01   configSecondChannelPowerReports 20
     2017-11-10 21:50:02   configSecondChannelPulseTimeFor18 5
     2017-11-10 21:50:02   configSecondChannelReactionToSwitchFor16 CancelModeAndSetTargetState
     2017-11-10 21:50:02   configSecondChannelTimeParameterFor17 50
     2017-11-10 21:50:02   configSwitchType ToggleSwitchDeviceChangesStatus2
     2017-11-10 21:38:31   mcCapability_01 ZWAVEPLUS_INFO VERSION SWITCH_BINARY ASSOCIATION ASSOCIATION_GRP_INFO MULTI_CHANNEL_ASSOCIATION METER MARK SWITCH_MULTILEVEL
     2017-11-10 21:38:32   mcCapability_02 ZWAVEPLUS_INFO VERSION SWITCH_BINARY ASSOCIATION ASSOCIATION_GRP_INFO MULTI_CHANNEL_ASSOCIATION METER MARK SWITCH_MULTILEVEL
     2017-11-10 21:38:31   mcEndpoints     total 2, identical
     2017-11-10 21:38:31   model           FIBARO System FGS223 Double Relay
     2017-11-10 21:38:31   modelConfig     fibaro/fgs223.xml
     2017-11-10 21:38:31   modelId         010f-0203-1000
     2017-11-10 21:47:43   state           off
     2017-11-10 21:50:38   timeToAck       0.122
     2017-11-10 21:50:38   transmit        OK
Attributes:
   IODev      Dongle_ZWAVE
   classes    ZWAVEPLUS_INFO VERSION MANUFACTURER_SPECIFIC SWITCH_BINARY DEVICE_RESET_LOCALLY ASSOCIATION_GRP_INFO ASSOCIATION POWERLEVEL CRC_16_ENCAP CONFIGURATION METER MULTI_CHANNEL_ASSOCIATION MULTI_CHANNEL APPLICATION_STATUS PROTECTION ALARM SECURITY FIRMWARE_UPDATE_MD CENTRAL_SCENE MARK SWITCH_MULTILEVEL
   room       ZWave
   vclasses   ALARM:5 APPLICATION_STATUS:1 ASSOCIATION:2 ASSOCIATION_GRP_INFO:1 CENTRAL_SCENE:2 CONFIGURATION:1 CRC_16_ENCAP:1 DEVICE_RESET_LOCALLY:1 FIRMWARE_UPDATE_MD:3 MANUFACTURER_SPECIFIC:2 METER:3 MULTI_CHANNEL:4 MULTI_CHANNEL_ASSOCIATION:3 POWERLEVEL:1 PROTECTION:2 SECURITY:1 SWITCH_BINARY:1 SWITCH_MULTILEVEL:3 VERSION:2 ZWAVEPLUS_INFO:2

- Für ZWave_Node_4.1 (Hier hatte ich schon das Problem bei den ganzen get-Befehlen - associationAll, ... - "Unknown argument associationAll, choose one of")

Code Auswählen Erweitern

Internals:
   CFGFN
   DEF        c732d821 1025
   Dongle_ZWAVE_MSGCNT 7
   Dongle_ZWAVE_RAWMSG 000400040c600d01003202213200000000
   Dongle_ZWAVE_TIME 2017-11-10 21:47:44
   IODev      Dongle_ZWAVE
   LASTInputDev Dongle_ZWAVE
   MSGCNT     7
   NAME       ZWave_Node_4.1
   NR         188
   STATE      off
   TYPE       ZWave
   ZWaveSubDevice yes
   endpointParent ZWave_SWITCH_BINARY_4
   homeId     c732d821
   isWakeUp
   nodeIdHex  0401
   READINGS:
     2017-11-10 21:47:44   power            0 W
     2017-11-10 21:47:44   reportedState   off
     2017-11-10 21:47:44   state           off
Attributes:
   IODev      Dongle_ZWAVE
   room       ZWave


- Für ZWave_SWITCH_BINARY_4.02 (Hier kam das obengennante Problem nur bei configAll)

Code Auswählen Erweitern

Internals:
   CFGFN
   DEF        c732d821 1026
   Dongle_ZWAVE_MSGCNT 14
   Dongle_ZWAVE_RAWMSG 0004000409600d02008e03030500
   Dongle_ZWAVE_TIME 2017-11-10 21:58:31
   IODev      Dongle_ZWAVE
   LASTInputDev Dongle_ZWAVE
   MSGCNT     14
   NAME       ZWave_SWITCH_BINARY_4.02
   NR         190
   STATE      off
   TYPE       ZWave
   ZWaveSubDevice yes
   endpointParent ZWave_SWITCH_BINARY_4
   homeId     c732d821
   isWakeUp
   nodeIdHex  0402
   READINGS:
     2017-11-10 21:57:42   assocGroup_1    Max 0 Nodes
     2017-11-10 21:57:42   assocGroup_2    Max 5 Nodes
     2017-11-10 21:57:42   assocGroup_3    Max 5 Nodes
     2017-11-10 21:57:41   assocGroups     3
     2017-11-10 21:58:31   mcaGroups       3
     2017-11-10 21:58:31   mca_1           Max 0
     2017-11-10 21:58:31   mca_2           Max 5
     2017-11-10 21:58:31   mca_3           Max 5
     2017-11-10 21:39:57   power            0 W
     2017-11-10 21:39:56   reportedState   off
     2017-11-10 21:39:56   state           off
Attributes:
   IODev      Dongle_ZWAVE
   classes    ZWAVEPLUS_INFO VERSION SWITCH_BINARY ASSOCIATION ASSOCIATION_GRP_INFO MULTI_CHANNEL_ASSOCIATION METER MARK SWITCH_MULTILEVEL
   room       ZWave
   vclasses   ASSOCIATION:2 ASSOCIATION_GRP_INFO:1 METER:3 MULTI_CHANNEL_ASSOCIATION:3 SWITCH_BINARY:1 SWITCH_MULTILEVEL:3 VERSION:2 ZWAVEPLUS_INFO:2

Fällt dir hier irgendwas auf, was seltsam aussieht?

Es ist halt irgendwie auch eigenartig, dass ein ZWave_Node_4.1 angelegt wird, vielleicht hängt es eben mit dem "ZWDongle_ProcessSendStack: no ACK" zusammen:

Code Auswählen Erweitern

2017.11.10 21:29:15 3: UNDEFINED ZWave_Node_4.1 ZWave c732d821 1025, please define it. Triggered by 000400040c600d01003202213200000000.
2017.11.10 21:29:15 2: autocreate: define ZWave_Node_4.1 ZWave c732d821 1025
2017.11.10 21:29:15 2: autocreate: define FileLog_ZWave_Node_4.1 FileLog ./log/ZWave_Node_4.1-%Y.log ZWave_Node_4.1
2017.11.10 21:29:15 2: ZWDongle_ProcessSendStack: no ACK, resending message 0109001304026007253c9d

Das mit den mca muss ich mir nochmal ansehen, aber danke schon mal für die vielen Infos!

[Cyber1000]

Ok ich glaub langsam beginn ich das ganze zu verstehen
Warum der fgs-223 immer die selbe Konfiguration bekommen hat? Ich hab den offensichtlich schon irgendwann früher (mit einer älteren fhem-Version, die noch nicht korrekt mit fgs-223 umgehen konnte) eingebunden und mein razberry hatte dann die falschen Assoziations. Da nützte es auch nichts die 3 Teile (Haupt und Nebengeräte) aus der fhem.cfg zu löschen. Beim neu inkludieren waren im razberry offensichtlich immer noch die alten Verbindungen drin und kamen genauso wieder zurück in die fhem.cfg.

Ich hab jetzt mit removeNode das Gerät exkludiert (dieser Schritt hat mir vorher gefehlt), dann die falschen Einträge aus der fhem.cfg gelöscht (wie schon früher) und dann mit addNode wieder inkludiert. Diesmal hat er alle Haupt und Endnodes komplett richtig angelegt!
Offensichtlich wurden da noch alte Konfigurationen direkt aus dem zwave-controller (razberry) gezogen.

Ich hoffe ich rede nicht kompletten Mist hier, bin wie gesagt noch ziemlich am Anfang  , klingt das plausibel was ich hier schreibe?
Vielleicht kann mir hier das jemand bestätigen (oder ggf. besser erklären, für andere die hierher kommen) oder widersprechen, wasauchimmer, dann kann ich den Thread schließen ...

[Cyber1000]

Ich schließ jetzt mal das Thema, weil es eigentlich einleuchtend ist, ein Gerät nur aus der fhem.cfg zu entfernen und wiederanzulegen bringt nichts, man muss es auch aus dem Gateway entfernen, damit es komplett neu angelegt wird.
Mein Problem kam daher, dass ich das Gerät mit einer alten fhem-Version angelegt habe, erst nachdem das Gerät auch wieder vom zwave-gateway weg war und fhem in der neuesten Version gelang die richtige Inklusion.