Support Thread für das hue2 und das hue3 Plugin

[Msinn]

Ja, die aktuelle inzwischen im develop befindliche Version des hue3 Plugins bnötigt den core aus dem develop. Sie läuft nicht mit dem aktuellen master.

[marmbruster]

Vielen Dank Martin für die Entwicklung des hue3-Plugins!
Ich habe großes Interesse daran, da ich auch die Dimm-Funktion über die KNX-Taster benötige (nutze momentan noch das "hue1"-Plugin).

Habe einen neuen Raspberry aufgesetzt mit aktuellem master-branch und der dev-Version des Plugins - hier fehlt scheinbar das Atrribut 'start_asyncio':

2024-05-26  20:43:10 NOTICE   lib.smarthome       --------------------   Init SmartHomeNG v1.10.0-master (4b25822a0)   --------------------
2024-05-26  20:43:10 NOTICE   lib.smarthome       Running in Python interpreter 'v3.11.2 final' in virtual environment, from directory /usr/local/smarthome
2024-05-26  20:43:10 NOTICE   lib.smarthome        - operating system 'Debian GNU/Linux 12 (bookworm)' (pid=7774)
2024-05-26  20:43:10 NOTICE   lib.smarthome        - on 'Raspberry Pi (Rev. b03115)'
2024-05-26  20:43:16 ERROR    lib.plugin          Plugin 'hue3' exception in run() method: 'HueApiV2' object has no attribute 'start_asyncio'
Traceback (most recent call last):
  File "/usr/local/smarthome/lib/plugin.py", line 756, in run
    self.plugin.run()
  File "/usr/local/smarthome/plugins/hue3/__init__.py", line 131, in run
    self.start_asyncio(self.plugin_coro())​

Liegt das an der Verwendung des master-branch?

Vielen Dank für Deine Bemühungen,
Matthias

[Msinn]

Für Experimentierfreudige steht das neue hue3 Plugin, welches die Hue Bridge über das neue API v2 anspricht, im develop Branch zur Verfügung. Voraussetzung ist mindestens SmartHomeNG v1.10.0, sinnvollerweise jedoch der aktuelle develop Branch.

Die Doku zu dem develop-Stand des Plugins findet sich hier.

[Msinn]

Ich bin dabei ein weiteres hue Plugin zu erstellen. Das Plugin wird auf dem Hue API v2 aufsetzen. Der wichtigste Unterschied zwischen den zwei Philips Hue API Versionen ist, dass bei der v1 die Bridge regelmäßig gepollt werden musste, um die aktuellen Werte zu erhalten. Das API v2 sendet Veränderungen aktiv. Daher stehen die Veränderungen an den Hue Devices (Leuchten, Taster, ...) ohne Verzögerung zur Verfügung.

Da das API v2 eine größere Anzahl von Breaking Changes beinhaltet, ist ein neues Plugin notwendig. Eine Kompatibilität zum bisherigen hue2 Plugin ist nicht wirklich herzustellen. Bei der Konfiguration werde ich mich aber soweit möglich an das hue2 Plugin anlehnen.

Die wichtigsten Features/Änderungen beim API v2:

• Keine Unterstützung der alten Bridges (und deCONZ)
• Aktive Meldung von Veränderungen durch die Bridge
• https Verbindung statt http
• Unterstützung mehrerer Lights in einem Device
• Andere Ansteuerung von Szenen
• Konzentration auf das Farbsystem xy
  • Keine Unterstützung für hue und sat Werte
  • Unterstützung von ct nur beim setzen von Werten (keine ct Werte von der Bridge)
• Keine Untersützung von bri_inc (ich werde versuchen, das im Plugin zu unterstützen)
• brightness Werte in Prozent (also 0 .. 100, nicht mehr 0 .. 255)

Das hue2 Plugin wird parallel bestehen bleiben, um unter anderem alte Bridges zu unterstützen.

[jzehnter]

Ich konnte das eben bei mir, genau wie du es beschrieben hast, nachstellen.

Ohne eine Transistion-Time wird "bri" nicht auf 1 gesetzt beim Ausschalten und beim Wiedereinschalten wird der vorherige Wert direkt angewendet

[jzehnter]

Ah cool - danke für das Debugging.

Wäre das nicht ein Pull-Request wert? Unklar ist allerdings wie andere Nutzer mit den geänderten Handling umgehen würden.

Ich für meinen Teil hab derzeit dafür einen nur halb funktionierenden Eval Workaround.

[Robert]

Es liegt eindeutig an der "transitiontime" in den qhue Aufrufen.

Mit

b.groups[3]['action'](on=False,transitiontime=10)

oder

b.groups[3]['action'](on=False,transitiontime=0)

bekomme ich irgendwann brightness = 1

Mit

b.groups[3]['action'](on=False)

bleibt immer der alte Wert.

Habe jetzt im Plugin alle

self.br.lights[plugin_item['id']]['state'](on=value,transitiontime=hue_transistion_time)

gegen

self.br.lights[plugin_item['id']]['state'](on=value)

ersetzt (bei allen light, allen groups und bei allen Actions) - damit funktioniert es.

Kann ich auch mit dem qhue-Module direkt auf der Python-Zeile nachstellen.


edit:

Hier ist der Bug auch beschrieben:

https://huegely.readthedocs.io/en/la...ion_times.html

Setting transition times does not cause any additonal requests, so performance-wise it shouldn’t be a consideration. However, there is a bug in the hue API that that causes any light that is turned off with a transition specified to be at minimum brightness when turned back on. Huegely deals with this by remembering the brightness and re-applying it when the light is turned on, which causes one extra request.

This will work fine if only huegely is used to control the lights, but there are scenarios where it will still cause problems:

• If a light is turned off with a transition and some other app turns it back on, the brightness won’t be applied.
• If a light is turned off with a transition, some other app turns it on, modifies the brightness and turns it back off, the next time huegely turns it on the saved brightness will be applied.

Basically, if in doubt, don’t use transition times for turning lights off.

[jzehnter]

Ich bin der Sache etwas näher gekommen, aber noch nicht mit der totalen Erkenntnis.

Die Hue-App schaltet immer eine Gruppe/Szene. Bei mir schalte ich gezielt eine Lampe.
In der Gruppe, die die App schaltet ist die Helligkeit auf 254 hinterlegt.

Das sieht man auch im WebIF.

Bei mir ist dort bei "Hue Gruppen" in der relevanten Gruppe wo meine Lampe mit drin ist, folgende Action hinterlegt:

{'on': True, 'bri': 254, 'hue': 0, 'sat': 0, 'effect': 'none', 'xy': [0.3805, 0.3769], 'ct': 370, 'alert': 'select', 'colormode': 'hs'}

Damit war es für mich in der Theorie schlüssig, dass es mit der App geht, während ich beim "nackten" Einschalten (on=True) ein anderes Verhalten habe.


Auf dem ersten Blick verwendest du aber das Group-Struct und schaltest nicht nur eine Lampe sondern auch die Gruppe? Gibt es ggf mehr Gruppen und via shng und App sind es unterschiedliche?

Habs bei mir aber noch nicht in der Praxis mit der Gruppe verprobt.

[Robert]

Leider nervt das Thema doch, und ich finde den Fehler nicht.

Ich habe jetzt in einer Python Shell direkt das qhue Module (https://github.com/quentinsf/qhue) getestet:

Das Problem liegt eindeutig beim Einschalten durch smarthomeNG bzw. das Hue2 Plugin?

Das Hue2 Plugin läuft parallel - ich schließe also Fehler durch das zyklische Abfragen der Werte etc. aus...

import qhue
b = qhue.Bridge("192.168.178.xx", "username")

# auslesen der Gruppe '3'
b.groups[3]()

# einschalten
b.groups[3]['action'](on=True)
# [{'success': {'/groups/3/action/on': True}}]

# brightness setzen auf ca. 60%
b.groups[3]['action'](bri=150)
# [{'success': {'/groups/3/action/bri': 150}}]

# ausschalten
b.groups[3]['action'](on=False)
[{'success': {'/groups/3/action/on': False}}]

# brightness abfragen
b.groups[3]()['action']['bri']
# 150

# einschalten
b.groups[3]['action'](on=True)
# [{'success': {'/groups/3/action/on': True}}]

# brightness abfragen
b.groups[3]()['action']['bri']
# 150

# ausschalten via smarthomeNG

# brightness abfragen
b.groups[3]()['action']['bri']
# 150

# einschalten via smarthomeNG

# brightness abfragen
b.groups[3]()['action']['bri']
# 1 !!!!!!!!!!!!!!!!!!!!!!

[Hubiflieger]

Ich habe mich heute ein wenig mit Git herumgeschlagen, und benutze jetzt die Version 2.3.0 . Die Bridge wurde nicht automatisch erkannt, aber nach manuellem eintragen der Daten in die plugin.yaml wird die Bridge gefunden, und die mit der Bridge verbundenen Lampen werden angezeigt.
Danke erstmal für die Hilfe.
Viele Grüße
Andreas

[Robert]

Das enforce_updates: True ist in den structs bewusst gesetzt, um Bedienprobleme zu verhindern.
Beispiel mit enforce_updates: False:
- Du schaltest eine Leuchte über SmartHomeNG ein
- Du schaltest die Leuchte außerhalb von SmartHomeNG aus (Hue App, Hue Lichtschalter oder anderes)
- Wenn Du nun über SmartHomeNG die Leuchte wieder einschalten möchtest, passiert nichts, da der Itemwert bereits auf eingeschaltet steht
- Erst wenn das Item durch pollen der Bridge den realen aktuellen Wert erfahren hat, kannst Du wieder über SmartHomeNG wieder einschalten

Hmm, die meisten Items "togglen" ja, z.b. in der GUI. Da hilft enforce_updates auch nicht, weil ich erst mal "ahnungslos" ausschalten muss um anschließend wieder einzuschalten - das funktioniert auch mit enforce_updates = false.
Aber stimmt schon, ich muss noch Mal überlegen warum mich das gestört hat.

jzehnter : danke dir - dann weiß ich, dass ich nicht alleine bin!

So ganz den Mechanismus verstehe ich aber immer noch nicht.

In https://github.com/smarthomeNG/plugi...init__.py#L339 wird "nur" ausgeschaltet - im Gegensatz zu zwei Zeilen drunter, wo explizit beim Setzen einer Helligkeit größer 0 auch eingeschalten wird.
Werde morgen Mal testen einfach nur dort "bri=<aktueller Wert>" mitzugeben. Irgendwo wird da ein bri=0 mitgeschickt...

Evtl auch https://github.com/Koenkk/zigbee2mqtt/issues/3799

[jzehnter]

Achja, BTW:
https://github.com/bahamas10/hueadm

Heute gefunden, da ich bei einer 1er Bridge die IP auf statisch ändern wollte. In der aktuellen App wird die ja nicht mehr supported.

Hat per CLI auf Anhieb geklappt und damit ist es sehr komfortabel zu debuggen

[Msinn]

Komplett verhindern könnte man da nur, wenn man auf das API v2 von Hue umsteigt. Das neue API ermöglicht, dass die Bridge Änderungen aktiv (ohne Polling) meldet. Das bedeutet allerdings eine komplette Neuentwicklung des Plugins.

Das neue API ist anders struktuiriert und die Verbindung ist nur über https möglich. Damit wird sich ein neues Plugin in die Ztetifikats-Hölle begeben müssen. Außerdem funktioniert das neue API nur mit der eckigen Bridge und nicht mit der Bridge v1 oder der DeKONZ Software Bridge.

[jzehnter]

Problem:
Schalte ich die Hue-Gruppe (bei z.B. 50% Helligkeit) per KNX "aus", wird ein paar Sekunden später das Helligkeitsstatus-KO/Item auf 0% gesetzt - schätze durch Rückmeldung aus dem Hue-System, aber ich fürchte letztlich weil das Plugin das triggert. Sende dann wieder einen Ein-Befehl - habe ich nur 1% Helligkeit.
Das ganze ist inkonsistent zur Hue App: Schalte ich mit dieser "aus", wird die Helligkeit NICHT geändert und auch das Helligkeitsstatus-KO/Item wird NICHT auf 0% gesetzt, so dass bei einem erneuten "ein", sei es durch Hue-Plugin oder Hue-App, auch bei z.B. 50% weitergeht.

Habe ich hier eine falsche Erwartung oder evtl. doch irgend einen Fehler?

Ich habe das selbe Verhalten bei mir auch.
Habe die Wirkung eingeschränkt, durch das Pollen der Lampen jede Sekunde. Aber trotzdem gibt es teilweise mehrere Sekunden, wo auch der Wert dann durch Hue auf 1 setzt.

Wenn ich die Tage Mal Zeit habe, schneite ich die Requests aus der App Mal mit. Ggf merkt die auch den Wert und schickt diesen direkt mit.

[Msinn]

Das Setzen der Helligkeit auf 0 ist eine explizite Sonderbehandlung, damit sich Hue Leuchten analog zu KNX Dimmern verhalten. Bei denen wird in der Visu nach dem Ausschalten auch eine Helligkeit von 0% angezeigt.

Ich kann das nicht genau sagen, evtl. entstehen Deine Probleme, weil Du die enforce_updates Voreinstellungen der struct mit enforce_updates: False überschrieben hast.

Das enforce_updates: True ist in den structs bewusst gesetzt, um Bedienprobleme zu verhindern.
Beispiel mit enforce_updates: False:
- Du schaltest eine Leuchte über SmartHomeNG ein
- Du schaltest die Leuchte außerhalb von SmartHomeNG aus (Hue App, Hue Lichtschalter oder anderes)
- Wenn Du nun über SmartHomeNG die Leuchte wieder einschalten möchtest, passiert nichts, da der Itemwert bereits auf eingeschaltet steht
- Erst wenn das Item durch pollen der Bridge den realen aktuellen Wert erfahren hat, kannst Du wieder über SmartHomeNG wieder einschalten

Wie stark sich das Problem auswirkt, hängt von der Pollzyklus Zeit ab. Die Bridge kann nur gepollt werden. Sie meldet nicht aktiv Veränderungen.
Da Problem wird durch enforce_updates: True umgangen.