Dimmer für mehrere Zigbee Leuchten

Begonnen von Spartacus, 06 Mai 2022, 12:11:07

Vorheriges Thema - Nächstes Thema

Spartacus

Hallo zusammen,

ich habe 4 baugleiche Deckenleuchten, die jeweils über einen eigenen Zigbee Controller angesteuert werden (geht technisch leider nicht anders). Die Gruppe befindet sich in einem Raum. Wie kann ich diese Leuchten am Besten in eine Gruppe packen und so behandeln, als wäre es eine Einzelleuchte. Ich möchte z.B. Lichtfarbe und Helligkeit gleichermaßen ansteuern.  Mit LightScene kann ich die Leuchten zwar gruppieren, aber nicht gemeinsam über meinen DOIF-Dimmer ansteuern. Wie könnte das passende fhem Szenario dazu aussehen?

Spartacus
Fhem-System: 1 x raspberry PI Typ B, 1 x enOcean PI Typ B | Enocean: PTM210, FMS61NP, FAM14, 2 x FSR14-4x, FTS14-EM | LaCrosse: 2 x TX29D über Jeelink V3 | 1-Wire: 2 x DS18B20 über DS9490R

Beta-User

a) Warum im Automatisierungs-Board und nicht in ZigBee?
b) Welche Einbindung? (!?!, bitte "was beim Posten beachten" beachten)

Falls deconz: Einfach alle 4 in eine Gruppe packen und dann die Gruppe in FHEM (bzw. ggf. auch mit einem zu der Gruppe hinzugefügten Taster) steuern. Bedarf für DOIF oä. sehe ich dann nicht.
Geht bestimmt auch so ähnlich (Gruppenfunktion in der Hardware) mit zigbee2mqtt...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rudolfkoenig

Auf der FHEM-Seite gibt das Modul structure, um mehrere Elemente gleich zu behandeln.

Spartacus

Hallo,

vielen Dank für die Anregungen. Ich werde mir beide Lösungen mal anschauen.
Spartacus
Fhem-System: 1 x raspberry PI Typ B, 1 x enOcean PI Typ B | Enocean: PTM210, FMS61NP, FAM14, 2 x FSR14-4x, FTS14-EM | LaCrosse: 2 x TX29D über Jeelink V3 | 1-Wire: 2 x DS18B20 über DS9490R

Beta-User

Zitat von: rudolfkoenig am 06 Mai 2022, 12:19:48
Auf der FHEM-Seite gibt das Modul structure, um mehrere Elemente gleich zu behandeln.
Vielleicht noch eine Anmerkung hierzu, da ich
zum einen nicht weiß, inwieweit du (@Rudi) ggf. die Gruppenfunktion in deconz (bzw. vermutlich ähnlich: in einer HUE-Bridge) kennst,
und zum anderen wohl nicht deutlich genug geschrieben hatte, wie das dann auf der FHEM-Seite ausschaut:
Die "Bridge-Gruppe" ergibt in FHEM dann ein eigenes HUEDevice, das man prinzipiell (bei entsprechender Konfiguration) wie eine einzelne "normale Leuchte" steuern kann, also insgesamt heller oder dunkler machen (selbst wenn die einzelnen Leuchten einen unterschiedlichen Ausgangswert hatten und auf einen uneinheitlichen Zielwert gehen!) oder auch auf eine einheitliche Farbe/Farbtemperatur - das ganze (idR.) mit nur einem Funkbefehl, den die Bridge dann effektiv versendet...

Daher glaube ich, dass das (für den hiesigen Anwendungfall!) die Lösung ist, die sowohl am einfachsten einzurichten ist, wie effektiv am "effizientesten" und flexibelsten.

Sonst ist structure auch ein tolles Modul (bei dem die "speichere die Szene als Reading"-Funktion leider nicht besonders gut bekannt zu sein scheint).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rudolfkoenig

ZitatDaher glaube ich, dass das (für den hiesigen Anwendungfall!) die Lösung ist, die sowohl am einfachsten einzurichten ist, wie effektiv am "effizientesten" und flexibelsten.
Das will ich nicht bezweifeln, ich wollte nur fuer die, dieses Thema finden, aber kein deconz haben (oder es nicht anpassen koennen bzw. wollen), eine Alternative geben.

Spartacus

#6
Hallo zusammen,

ja ich glaube, dass das mit dem gruppieren im deconz die Lösung ist. Darauf bin ich wirklich nicht gekommen.

Hintergrund ist, dass die 4 Occhio Mitos (wir erinnern uns  8)) jetzt an der Decke kleben und mit je einem iluminize Zigbee Controller laufen. Der DOIF Dimmer ist nötig um den Busch-Jäger Wandsender auszuwerten und bspw. zu dimmen. Ein direktes Einlernen in den Wandsender möchte ich vermeiden, da auch Rollladen und enocean Devices über den Zigbee Wandsender gesteuert werden. Das klappt alles klappt soweit auch ganz gut und zuverlässig mit einer Leuchte.

Der Hinweis auf das Gruppendevice im deconz war die richtige Idee. Das werde ich mal so implementieren...

ich danke euch,
Spartacus.

P.S: Ich habe das mal flux getestet. Das funzt ganz gut, allerdings liefert das Gruppendevice keine Statusänderungen ab. Vielleicht kann jemand den Beitrag in den HUE-Channel verschieben um das Issue mit dem Staus zu lösen
Fhem-System: 1 x raspberry PI Typ B, 1 x enOcean PI Typ B | Enocean: PTM210, FMS61NP, FAM14, 2 x FSR14-4x, FTS14-EM | LaCrosse: 2 x TX29D über Jeelink V3 | 1-Wire: 2 x DS18B20 über DS9490R

Beta-User

Zitat von: Spartacus am 06 Mai 2022, 14:47:32
Der DOIF Dimmer ist nötig um den Busch-Jäger Wandsender auszuwerten und bspw. zu dimmen.
"Nötig" sicher nicht, aber das ist eine andere Diskussion...

Ist der Busch-Jäger das dusselige Ding mit 8 Tasten, das auch unter "Jung"-Label zu bekommen ist oder ein FOH-Derivat? Wenn letzteres, sollte es gehen, z.B. nur eine Taste (oder ein Paar daraus) in die Gruppe zu nehmen und damit zu dimmen und/oder an/aus zu realisieren, und den Rest anderweitig mit einem Eventhandler auszuwerten (so mache ich das z.B. mit meinen "Opple"-Tastern via notify in Richtung auf Rollläden, MPD, 433MHz-Dunstabzug, ...).

Ansonsten (wenn es dieser 8-fach Kontroller ist): Beileid, was ein mistiges Ding....
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Spartacus

Hallo,
ja, wieso? Das Dingen läuft doch super! Das ist 8-fach mit Netzteil. Also batterielos. Habe 5 stk davon. Alle sauber im conbee angemeldet und reagieren tadellos.

Was gibt es für Alternativen fürs Schalterprogramm?
Spartacus
Fhem-System: 1 x raspberry PI Typ B, 1 x enOcean PI Typ B | Enocean: PTM210, FMS61NP, FAM14, 2 x FSR14-4x, FTS14-EM | LaCrosse: 2 x TX29D über Jeelink V3 | 1-Wire: 2 x DS18B20 über DS9490R

Beta-User

Zitat von: Spartacus am 06 Mai 2022, 15:07:35
Hallo,
ja, wieso? Das Dingen läuft doch super! Das ist 8-fach mit Netzteil. Also batterielos. Habe 5 stk davon. Alle sauber im conbee angemeldet und reagieren tadellos.
Na ja, ich habe den als "Jung" - der ist mit Batterie und sehr "hungrig" (mit der neueren firmware, die dann auch mit ZigBee 3.0 "kann", vorher war es eine pure Katastrophe mit dem Ding. Weiß nicht mehr ganz genau, was das Problem war, aber er war effektiv mit der alten firmware schlicht unbrauchbar).

Das "Problem": Sobald man den in eine Gruppe gepackt hat, ist er praktisch nur noch als Szenen-Kontroller für genau eine Gruppe zu gebrauchen (unter der dann aber wieder Teilgruppen möglich sind). Das geht zwar schon irgendwie, aber in der Handhabung fühlt sich das trotzdem komisch an, ich hatte mir was anderes erhofft, nämlich einen flexiblen Einsatz jeder einzelnen Taste (nach dem gedanklichen Vorbild eines 6-fach-CUL_HM-Tasters).

Zitat
Was gibt es für Alternativen fürs Schalterprogramm?
Effektiv: Fasst keine. Eventuell "friends of hue" (FOH), den gibt es in (recht teuren) Derivaten auch für diverse Schalterprogramme (leider nicht für Jung CD).

Ansonsten ist mein "Liebling" der Opple - der aber den Nachteil hat, dass die Ansteuerung von Leuchtmitteln immer die Zentrale braucht, das ist kein "echter" Gruppenschalter, den man hardwaremäßig in eine Gruppe packt ("binding"). Kostet aber effektiv auch nur einen Bruchteil von dem Jung!
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files