[gelöst mit cmdalias] HUEDevice - ZigBee Leuchte hinter ZigBee Aktor

Begonnen von Beta-User, 16 Februar 2022, 22:58:09

Vorheriges Thema - Nächstes Thema

Beta-User

Hallo zusammen,

gesucht wird eine möglichst einfache Lösung für folgende Einbausituation:
Es gibt ein ungeschickt verlegtes Kabel, an dem drei ZigBee-Leuchtmittel hängen. Es gibt/gab einen "echten" Schalter davor, den habe ich jüngst gegen einen "hinter den Schalter"-Aktor getauscht bzw. damit "upgegraded".

Ziel ist es, die drei Leuchtmittel partiell unabhängig zu schalten, also zwei logische Gruppen daraus zu bilden, eine mit einem Leuchtmittel und eine mit den beiden anderen.
Das klappt bedingt durch die gemeinsame Einschaltsituation nur bedingt, ausschalten ist auch kein Ding, wenn beide "Gruppen" aus sind, geht der Hauptaktor "hinter dem Schalter" auch aus.

Die Kurform von den beiden "Gruppen":
defmod Licht_Spuele HUEDevice 11  IODev=phoscon

defmod Wandleuchten HUEDevice group 9  IODev=phoscon

(HUEDevice 11 ist nicht Mitglied in group 9)

Das Problem: Ein "set Licht_Spuele on" wirft kein als Einschaltbefehl identifizierbares Event, es gibt nur ein zusätzliches "lastseen".
Daher fehlt mir jetzt grade eine Idee, wie das so auf möglichst direktem Weg einzurichten ginge, dass Steuerungsbefehle via Sprachsteuerung oder fhemApp auch tatsächlich umgesetzt werden.

(Nein, den Schalter ganz stillzulegen ist keine Option, und eigentlich will ich auch nicht einfach aus allen drei bzw. 4 Aktoren eine Gesamtgruppe bilden oder den Aktor beiden "Gruppen" zuordnen (dann geht nämlich auch immer die 2. Gruppe aus)...)

Vielleicht kann mir ja jemand einen Trick verraten...?
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

justme1968

ich verstehe den ansatz mit dem extra aktor noch nicht. wenn die leuchtmittel an sich schon zigbee können ist jeder weitere echte schalter davor kontraproduktiv. egal ob echter schalter oder irgendein aktor.

ich sehe folgende möglichkeiten:

- die lampen auf dauerstrom :) und einen schalter verwenden der zigbee spricht. keinen aktor.
   also etwas aus der friends of hue serie, den hue dimmer switch, den hue oder einen anderen tastsensor.

   so bekommst du auch problemlos einen schalter mit 2 oder 3 wippen an die vorhandene stelle
   entweder    und kannst die lampen auf wunsch auch wirklich getrennt per hand schalten.

- die lampen auf dauerstrom und den aktor zwar einbauen aber so das er nicht die lampen sondern
  nur 'sich selber' schaltet. aus fhem oder per regel in der bridge dann bei schalten des aktors die passenden
  lampen nachziehen.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Beta-User

Danke erst mal für deine Antwort!

Zitat von: justme1968 am 18 Februar 2022, 13:38:22
ich verstehe den ansatz mit dem extra aktor noch nicht. wenn die leuchtmittel an sich schon zigbee können ist jeder weitere echte schalter davor kontraproduktiv. egal ob echter schalter oder irgendein aktor.
Diese Diskussion kenne ich, und mein vorheriger Anlauf war auch der, die Leuchten dauerzubestromen. Deswegen sitzt drüber auch ein (schweineteures) Jung-ZigBee-Tasterfeld über den sich das ganze "im Prinzip" zwanglos bedienen ließe. Soweit die Theorie.

In der Praxis:
- Wird der Taster von den Nutzern nicht angenommen (er ist auch nach meinem Empfinden schlecht, auch wenn er prinzipiell funktioniert und optisch die praktisch einzige vermittelbare Lösung darstellt!), FOH war an anderer Stelle zu einem anderen Zweck mal verbaut gewesen, ist auch keine Lösung;
- hängen sich die Leuchtmittel einfach hin und wieder weg (Tradfri) und müssen dann vom Strom. Der Schaltschrank ist zu diesem Zweck keine ernsthafte Option...

Ergo: ich will "hart" schalten können, und unter den gegebenen Voraussetzungen ist ein intelligenter Aktor besser als alles, was ich bis dato an der Stelle versucht habe (nebenbei verbessert er das Mesh in der Ecke signifikant, aber zugegebenermaßen täte er das auch, wenn er nur als "Detektor" fungieren würde)...

Was ich eigentlich gerne hätte, wäre ein (gerne optionales) Event für "jemand versucht, die Lampe xy anzuschalten". Gäbe es das, wäre der Rest relativ zwanglos so zu regeln, dass die Regierung mitspielt ;) .
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

justme1968

so ein event gibt das api nicht her.

ich denke mit dem zweiten vorschlag kommst dem ganzen am nächsten.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Beta-User

Wieso das API? Die Art Einschaltbefehl, an die ich dachte kommen alle aus bzw. über FHEM. Das wäre dann doch in HUEDevice direkt zu verorten, oder?

Vielleicht hilft das mit den Regeln in deconz weiter, also falls da jemand Ideen hat, wie man in deconz direkt auf den Versuch, ein nicht erreichbares Gerät einzuschalten eine Regel setzt: Gerne :) .
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

justme1968

dann verstehe ich gerade noch weniger. wenn du aus fhem schaltest und sich der zustand ändert bekommst du natürlich ein event. wenn die lampe aber zwischendurch wirklich stromlos ist bekommt das die bridge nur sehr zeit erzögert mit. und meldet es entsprechend spät an fhem.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Beta-User

Wie eingangs geschrieben, kommt wohl schon recht unmittelbar ein Event _zurück_: das "lastseen".

Das ist aber komplett unspezifisch und eben auch "zu spät", nämlich resultierend aus der Rückmeldung.

Nochmal ein typisches Szenarium: Alles ist aus, erreichbar ist dann nur der Aktor. Jemand sagt RHASSPY: "Schalte die Leuchte an der Wand ein", dann macht das ein "set Wandleuchten on" draus (genauso wie via FHEMWEB-Icon, fhemApp oä.). Von diesem Einschaltbefehlt sieht man aber nichts, bis er eben das "lastseen" in den Event-Monitor zaubert. (Das Problem besteht also nur, wenn nicht sowieso eine Auswertung von Rahmenbedingungen möglich ist, z.B. bei einem Taster-Event).

Anders gesagt: Wäre die Leuchte vom TYPE CUL_HM, MQTT2_DEVICE, ZWave oder MYSENSORS_DEVICE, könnte ich auf den "set_on"-Event reagieren und die Vorbedingung (=Einschalten auch des Aktors) erfüllen, im Moment bekommt man nicht mal mit, dass da jemand was haben will...
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

justme1968

natürlich gibt es ein on event. wenn der schalt befehl aus fhem auf den autor kommt meldet deconz direkt per event zurück das eingeschaltet wurde. den umweg über set_on gibt es nicht weil das ganze so schnell geht das die events unnötige last erzeugen würden.

die frage is also warum siehst du das on event nicht? ist der event websocket verbunden? siehe internal websocket. kommen events von deconz? mit verbose 4 oder 5 i'm log schauen. sind irgendwelche event attribute gesetzt? im event monitor schauen.

das sollte alles gehen und schnell genug sein wenn alles strom hat. es kann sein das die birnen aber garnicht schnell gunug bereit sind nach dem sie strom bekommen. dann wäre schneller eventuell sogar kontraproduktiv.

falls das echte event tatsächlich zu langsam sein stollte: das on kommando mit cmdalias überschreiben und bevor es an die bridge geht noch was damit machen.

hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Beta-User

Schon klar: Wenn alles unter Strom steht (und nicht grade "weggehangen" ist), ist das nicht das Problem. Es gibt aber _keinen on-Event_, wenn kein Strom da ist. Ergo bekommt man ohne (wie gesagt: gerne optionales) Event nicht mit, dass da was nicht klappt.

Das funktioniert übrigens auch gut, wenn Aktor und Leuchte in einer HUE-Gruppe sind. Sind sie aber in dem Szenarium nicht. Und wenn die Leuchte stromlos ist, ist es keine Geschwindigkeitsfrage...

Werde mir jetzt mal das mit dem cmdalias ansehen, das könnte klappen :) .
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

Beta-User

Zitat von: Beta-User am 18 Februar 2022, 15:18:34
Werde mir jetzt mal das mit dem cmdalias ansehen, das könnte klappen :) .
Klappt, DANKE!

Hier mal meine beiden Logikdevices, die das regeln.

Der neue cmdalias:
defmod al_hues cmdalias set (Wandleuchten|Licht_Spuele) (on|toggle) AS { if (!ReadingsVal('HUEDevice31','onoff',1)) { \
  my $other = $EVENT =~ m{Licht_Spuele} ? 'Wandleuchten' : 'Licht_Spuele';; return fhem("set HUEDevice31 on;; sleep 0.2;; set $other off") } \
  if ( $EVENT =~ m{Licht_Spuele} && !ReadingsVal('Licht_Spuele','onoff',1) || $EVENT =~ m{Wandleuchten} && !ReadingsVal('Wandleuchten','onoff',1) ) {\
  $EVENT =~ s{toggle}{on} } else { $EVENT =~ s{toggle}{off} };;\
  CommandSet(undef,$EVENT) }


Und zur Abrundung das notify zum Abschalten des Aktors (damit bei späterer manueller Bedienung das Erwartete passiert):
defmod n_Lichter_ez_wand notify Licht_Spuele:off|Wandleuchten:off { my $other = $NAME eq 'Licht_Spuele' ? 'Wandleuchten' : 'Licht_Spuele';; \
  return if ReadingsVal($other,'onoff',1);;\
  return CommandSet(undef, 'HUEDevice31 off')}
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