fibaro fgs-223

[justme1968]

ich wollte ein paar serien schalter fhem fähig machen und da die zweikanalign zwave aktoren kleiner und günstiger als die homematic aktoren sind habe ich mir zum ersten testen mal einen zme_usb1 und einen fibaro fgs223 gekauft und gerade in betrieb genommen.

wie im wiki beschrieben werden drei devices für den aktor angelegt: ZWave_SWITCH_BINARY_2, ZWave_SWITCH_BINARY_2.1 und ZWave_SWITCH_BINARY_2.2

anders als beim beschriebenen fgs-222 wird aber das manuelle schalten niemals im haupt device sondern im endpoint 1 (bzw 2) gemeldet. liegt vermutlich an der firmware und ist eigentlich erst mal besser. auch die verbrauchswerte landen jeweils im richtigen kanal.

allerdings fallen mir ein paar ungereimtheiten auf:

- beim schalten über fhem über das haupt device reagiert das device für kanal 1 synchron mit. umgekehrt ist das leider nicht der fall. beim schalten von kanal 1 in fhem ändert sich am haupt device nichts.

- wenn man (egal ob über fhem oder am schalter) die lampen nur kurz einschaltet oder beide kanäle kurz nacheinander schaltet ist der status in fhem nicht immer aktuell.

die beiden punkte oben führen dazu das der status in fhem beliebig vom tatsächlichen status abweichen kann. was das ganze ziemlich nutzlos macht.

liegt das am fgs-223 bzw. der firmware und gibt es eine besser wahl als aktor? oder ist das prinzipiell so? oder muss irgendwo noch etwas an einer konfiguration geschaut werden?

es scheint aktoren zu geben bei denen das schalten im haupt device beide kanäle schaltet. ist das aktor/firmware abhängig? wäre es sinnvoll das in fhem zu emulierten um es einheitlich zu haben?

- das haupt device hat energy und power readings. die aber immer 0 sind. auch wenn das device an ist und im kanal device die korrekten werte stehen.

- die kanal devices haben get meter kommandos aber keine get powerlevel. letzteres gibt es nur im haupt device. dort wird dann aber nur 0 zurück gemeldet da es die werte nur im kanal gibt.

auch hier die frage: ist das immer so oder nur bei diesem device? oder muss irgendwo noch etwas angepasst werden?

- in fhemweb sind dim kommando vorhanden das keinerlei auswirkung hat.

- es gibt eine ganze reihe config optionen die fhem nicht kennt. im handbuch ist alles beschrieben. wer braucht wo welche information um diese zu ergänzen? vor allem die option ob taster, schalter oder tastschalter angeschlossen sind wäre nützlich.

- getConfigAll liest auch nur die paar bekannten optionen.

irgendwie ist der erste eindruck ziemlich zwei gespalten: den usb stick in betrieb nehmen und das ding in fhem anlernen geht völlig problemlos. der erste eindruck im betrieb zumindest dieses aktors ist eher bescheiden...

[A.Harrenberg]

Hi,

ich kommentieren mal nur ein paar von den Punkten...

- beim schalten über fhem über das haupt device reagiert das device für kanal 1 synchron mit. umgekehrt ist das leider nicht der fall. beim schalten von kanal 1 in fhem ändert sich am haupt device nichts.

das müsste sich evtl. mit einer mca anpassen lassen, vielleicht kann Krikan was dazu sagen.

- wenn man (egal ob über fhem oder am schalter) die lampen nur kurz einschaltet oder beide kanäle kurz nacheinander schaltet ist der status in fhem nicht immer aktuell.

Das sollte nicht sein, da müssten im Protokoll ein paar CAN oder NO_ACK auftauchen. Ist denn die Funkstrecke "gut"?

- das haupt device hat energy und power readings. die aber immer 0 sind. auch wenn das device an ist und im kanal device die korrekten werte stehen.

Liegt auch an der Art der Rückmeldung, hier könnte ein mca helfen, dann wären da aber auch nur die Werte von einem Kanal und nicht z.B. die Summe aus beiden

- die kanal devices haben get meter kommandos aber keine get powerlevel. letzteres gibt es nur im haupt device. dort wird dann aber nur 0 zurück gemeldet da es die werte nur im kanal gibt.

Achtung, POWERLEVEL hat nichts mit der Leistungsmessung zu tun, sondern ist eine Möglichkeit die Sendeleistung zu verringern um z.B. Reichweitentests zu machen. Die Klasse/Befehle am besten ignorieren wenn man nicht genau weiß was man tut. POWERLEVEL gibt es deshalb auch nur im Hauptdevice.

- es gibt eine ganze reihe config optionen die fhem nicht kennt. im handbuch ist alles beschrieben. wer braucht wo welche information um diese zu ergänzen? vor allem die option ob taster, schalter oder tastschalter angeschlossen sind wäre nützlich.

Die Beschreibung der config-Optionen kommt aus dem eingebundenen XML, bei Änderungswünschen an Krikan wenden...
Ist denn model-ID mit was sinnvollem gefüllt, d.h. hat FHEM überhaupt was aus der XML eingebunden? (Hast Du ein Bild von dem Device in FHEM?)

- getConfigAll liest auch nur die paar bekannten optionen.

Liest sich so als ob das mit dem Einlesen des Modells nicht geklappt hat oder das Ding eine neue, unbekannte ID hat. Du kannst einfach noch mal "get <device> model" aufrufen und schauen was dann erscheint...

Gruß,
Andreas.

[krikan]

anders als beim beschriebenen fgs-222 wird aber das manuelle schalten niemals im haupt device sondern im endpoint 1 (bzw 2) gemeldet. liegt vermutlich an der firmware und ist eigentlich erst mal besser. auch die verbrauchswerte landen jeweils im richtigen kanal.

FGS-222 und FGS-223 sind insbesondere in diesem Bereich gänzlich unterschiedlich.

- beim schalten über fhem über das haupt device reagiert das device für kanal 1 synchron mit. umgekehrt ist das leider nicht der fall. beim schalten von kanal 1 in fhem ändert sich am haupt device nichts.

Das liegt an den an den Rückmeldungen des Aktors bzw. wie der Controller automatisch von FHEM assoziiert wird. Kenne aber keine bessere Möglichkeit.
Hauptdevice ist für Ansteuerung und Visualiserung des 1. Kanals nicht "ideal". Nimm einfach die Endpoint-Devices.

- wenn man (egal ob über fhem oder am schalter) die lampen nur kurz einschaltet oder beide kanäle kurz nacheinander schaltet ist der status in fhem nicht immer aktuell.

Dürfte so nicht sein. Tippe auf Funkkollisionen oder Telegrammverluste; schau mal bitte ins Log, ob Probleme gemeldet werden. (NO_ACK und Co.)

liegt das am fgs-223 bzw. der firmware und gibt es eine besser wahl als aktor? oder ist das prinzipiell so? oder muss irgendwo noch etwas an einer konfiguration geschaut werden?

Kenne das nicht als prinzipielles Problem. Konfiguration kann ich nicht ausschließen; evtl. gibt es andere bessere Assoziierungsvarianten.

es scheint aktoren zu geben bei denen das schalten im haupt device beide kanäle schaltet. ist das aktor/firmware abhängig?

Ja. Philio PAN04 schaltet bspw. beide Kanäle gleichzeitig. Aber der hat den Nachteil, dass man für den Status der einzelnen der einzelnen Kanäle eine Abfrage absetzen muss.

wäre es sinnvoll das in fhem zu emulierten um es einheitlich zu haben?

Sicherlich, aber da das von Aktor, Firmware, Assoziierung, Konfiguration,... abhängig ist, sehe ich momentan den Ansatzpunk nicht. -> Rudi

- das haupt device hat energy und power readings. die aber immer 0 sind. auch wenn das device an ist und im kanal device die korrekten werte stehen.

- die kanal devices haben get meter kommandos aber keine get powerlevel. letzteres gibt es nur im haupt device. dort wird dann aber nur 0 zurück gemeldet da es die werte nur im kanal gibt.

auch hier die frage: ist das immer so oder nur bei diesem device? oder muss irgendwo noch etwas angepasst werden?

Abhängig von Aktor, Firmware, Assoziierung, Konfiguration,...

- in fhemweb sind dim kommando vorhanden das keinerlei auswirkung hat.

Entsteht durch eine Vereinfachung von FHEM (https://forum.fhem.de/index.php/topic,72418.0.html)
Kannst Du bei dem speziellen Aktor gefahrlos ändern, indem Du aus dem Attribut classes SWITCH_MULTILEVEL löscht.

- es gibt eine ganze reihe config optionen die fhem nicht kennt. im handbuch ist alles beschrieben. wer braucht wo welche information um diese zu ergänzen? vor allem die option ob taster, schalter oder tastschalter angeschlossen sind wäre nützlich.

Welche genau?
Die Wahlfunktktion Taster, Schalter ist bei mir als configSwitchType vorhanden.

- getConfigAll liest auch nur die paar bekannten optionen.

Korrekt. Geht nicht anders.

Ansonsten eben mit configByte, configWord, configLong direkt setzen/abfragen.

irgendwie ist der erste eindruck ziemlich zwei gespalten: den usb stick in betrieb nehmen und das ding in fhem anlernen geht völlig problemlos. der erste eindruck im betrieb zumindest dieses aktors ist eher bescheiden...

Was musstest Du auch mit einem 2kanaligen und auch noch dem Aktor anfangen... 

[justme1968]

bin noch am probieren deshalb erst mal nur eine kurze antwort:

wenn ich aus fhem schalte gibt es tatsächlich mehrere nack wenn es mehr als ein kommando ist. usb stick und aktor sind nur etwa 4 meter und eine holz wand auseinander. ich hätte gedacht das geht besser. gibt es einen stick mit besserer sende/empfangs leistung?

der satz 'kein mettal in der nähe des aktors' ist zwar wie immer richtig und nachvollziehbar aber auch nicht realistisch wenn das ding hinter einem schalter mit metall frontplatte sitzt und 10 kabel drum rum laufen ...

ich schaue mal ob es besser geht wenn ich das ding wieder aus baue  . der aktuelle zustand ist erst mal recht unbefriedigend. ich hatte mir mehr versprochen. mal sehen ob es noch was wird.



bild ist da, xml file steht auch in den internals. get model funktioniert ebenfalls. es gibt aber kein configSwitchType. nur config_20 wenn ich ein get configByte auf die 20 mache.
edit: grad gesehen das auf dem produktiv system die xml files nicht aktuell waren. 


ansonsten erst mal danke...

[krikan]

ich hätte gedacht das geht besser. gibt es einen stick mit besserer sende/empfangs leistung?

Mir ist nichts bekannt.
Stabil wird das erst bei mehreren netzbetriebenen Geraeten. Dann ist das aber zumindest hier problemlos.
HM hat nach meiner Erfahrung eine größere Reichweite als ZWave (oder auch EnO). ZWave wird erst durch ein größeres Netz stabil.
Kurzfristig kannst Du vielleicht etwas mit der Antennenstummelausrichtung des Aktor erreichen. Langfristig ist das aber nichts.

grad gesehen das auf dem produktiv system die xml files nicht aktuell waren.

Beruhigt mich. 

[rudolfkoenig]

wenn man (egal ob über fhem oder am schalter) die lampen nur kurz einschaltet oder beide kanäle kurz nacheinander schaltet ist der status in fhem nicht immer aktuell.

Wenn man die Lampen ueber FHEM schaltet, dann kann ich mir das nicht erklaeren. Wenn man die Lampen am Schalter schaltet, dann gibt es vom Funk-Kollision bis Bug in FHEM viele Moeglichkeiten. Bisher wurde das Problem aber noch nicht gemeldet (d.h. sollte nicht allgemeiner Natur sein), oder ich habe das nicht so verstanden.

wäre es sinnvoll das in fhem zu emulierten um es einheitlich zu haben?

Bin z.Zt. dagegen:
- Es gibt neben Schalten noch viele andere Klassen (200+)
- Ein Geraet beschreibt bei der Inklusion, welche Klassen (vulgo Befehle/Meldungen) das Hauptgeraet und welche die Kanaele unterstuetzen.
- Nach deinem Vorschlag muesste man alle Klassen des ersten Kanals im Hauptgeraet aufnehmen, und Befehle dafuer zum ersten Kanal umleiten. Rueckmeldungen analog.
- Falls bei einem Geraet ein Befehl am Hauptaktor was anderes bewirkt, als im ersten Kanal, dann hat man was verbaut.

Eigentlich gehoeren Schaltbefehle nicht ins Hauptgeraet, allerdings koennen manche Sensoren keine Kanaele direkt adressieren (oder es ist zu kompliziert das zu konfiguireren), die Aktor-Hersteller wollen aber Kompatibilitaet mit diesen Sensoren. Das wird mehr oder weniger gut umgesetzt, und deswegen die Verwirrung.

Bin aber offen, falls ich was uebersehe oder falsch verstehe.

gibt es einen stick mit besserer sende/empfangs leistung?

Sicher doch: ein CUL. Ich brauche endlich ein Versuchskaninchen einen ernsthaften Tester.