Support Thread für das hue2 und das hue3 Plugin

[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 !!!!!!!!!!!!!!!!!!!!!!

[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]

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]

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.

[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

[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.

[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.

[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]

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.