Support Thread für das hue2 Plugin

[whe]

zu #33

in meiner plugin.yaml habe ich laut Dokumentation nur den Namen eingetragen.
das Discovery funktioniert dann wohl und es werden die anderen Einträge hinzugefügt.

HUE2:
    plugin_name: hue2
    bridge_serial: 001788762a60
    bridge_user: 55qxWqzH0YJaKcw6NCaJyFsAHBkA54hjpyIl3yGg
    bridge_ip: 192.168.178.50

danach kann ich das webif aber nicht mehr aufrufen. (Error 500)
es hat wohl auch nichts damit zu tun, dass ich in meiner ges. Konfiguration noch alle Definitionen des alten plugins drin habe.
wenn ich in der plugin.yaml den alten Eintrag rausnehme ändert sich nichts.

zur 2. Frage:
ich betreibe zwei Raspberries; meine funktionsfähige Umgebung mache ich ja nicht eher platt, bevor die neue funktioniert.

[Msinn]

Das Portal von hue hat heute mal wieder Probleme. Das führt beim Start von SmartHomeNG zu folgendem Logeintrag:

2021-02-19  10:34:12 ERROR    discoverhue          Problem at portal: HTTP Error 404: Not Found

Das rührt daher, dass die von Philips/Signify empfohlene Discover Methode das Portal anfragt. Denn Bridges der Version 2 melden sich dort an.

Außer, dass das Portal nicht sehr stabil zu sein scheint (ich hatte diesen Fehler bereits mehrfach in den letzten Wochen), finde ich ich es nicht schön, dass die erste Methode zum discovern einer Bridge im eigenen LAN eine Anfrage ins Intrnet ist. Ich werde in einer kommenden Version das Package discoverhue ersetzen und das zumindest schaltbar machen.

[Msinn]

Wie sieht denn Deine etc/plugin.yaml aus?

und zu #30 : Wieso hat Dein Pi 2 zusätzliche IP Adressen?

[whe]

zu #30

muss leider noch mal auf mein 500 Problem zurückkommen. am langsamen Pi2 liegt es nicht, auf dem neuen Pi4 kommt der gleiche Fehler beim Aufruf des webif. Zu dem cherrypy.error kann ich nichts bei Google finden.
hier jetzt ein Auszug aus dem WARNING log:

2021-02-13  19:38:55 WARNING  lib.smarthome.main  --------------------   Init SmartHomeNG 1.8.1.master (84873f74)   --------------------
2021-02-13  19:38:55 WARNING  lib.smarthome.main  Running in Python interpreter 'v3.7.3 final', from directory /usr/local/smarthome
2021-02-13  19:38:55 WARNING  lib.smarthome.main   - on Linux-5.10.11-v7l+-armv7l-with-debian-10.8 (pid=3558)
2021-02-13  19:38:56 WARNING  lib.smarthome.main   - Nutze Feiertage für Land 'DE', Provinz 'NW', benutzerdefinierte(r) Feiertag(e) nicht definiert
2021-02-13  20:39:15 WARNING  lib.smarthome.main  --------------------   SmartHomeNG initialization finished   --------------------
2021-02-13  20:39:15 WARNING  plugins.smartvisu   Deprecated widget usage (used in # sv_widgets): {'basic.button': 2, 'basic.switch': 10}
2021-02-13  20:42:07 WARNING  plugins.smartvisu   client_info = [{'ip': '192.168.178.21', 'port': '50754', 'protocol': 'ws', 'sw': 'smartVISU', 'swversion': 'v2.9', 'hostname': '', 'browser': 'Firefox', 'browserversion': '85'}]
2021-02-13  20:43:12 ERROR    cherrypy.error.2819222448 [13/Feb/2021:20:43:12] HTTP
Traceback (most recent call last):
  File "/home/smarthome/.local/lib/python3.7/site-packages/cherrypy/_cprequest.py", line 638, in respond
    self._do_respond(path_info)
  File "/home/smarthome/.local/lib/python3.7/site-packages/cherrypy/_cprequest.py", line 697, in _do_respond
    response.body = self.handler()
  File "/home/smarthome/.local/lib/python3.7/site-packages/cherrypy/lib/encoding.py", line 219, in __call__
    self.body = self.oldhandler(*args, **kwargs)
  File "/home/smarthome/.local/lib/python3.7/site-packages/cherrypy/_cpdispatch.py", line 54, in __call__
    return self.callable(*self.args, **self.kwargs)
  File "/usr/local/smarthome/plugins/hue2/webif/__init__.py", line 113, in index
    br_object=self.plugin.br)
  File "/usr/lib/python3/dist-packages/jinja2/asyncsupport.py", line 76, in render
    return original_render(self, *args, **kwargs)
  File "/usr/lib/python3/dist-packages/jinja2/environment.py", line 1008, in render
    return self.environment.handle_exception(exc_info, True)
  File "/usr/lib/python3/dist-packages/jinja2/environment.py", line 780, in handle_exception
    reraise(exc_type, exc_value, tb)
  File "/usr/lib/python3/dist-packages/jinja2/_compat.py", line 37, in reraise
    raise value.with_traceback(tb)
  File "/usr/local/smarthome/plugins/hue2/webif/templates/index.html", line 413, in top-level template code
    {% set tab6title = "<strong>Hue Bridge</strong>" %}
  File "/usr/local/smarthome/modules/http/webif/gtemplates/base_plugin.html", line 183, in top-level template code
    {% if scroll_heading is not defined %}
  File "/usr/local/smarthome/modules/http/webif/gtemplates/base.html", line 1, in top-level template code
    {% block doc -%}
  File "/usr/local/smarthome/modules/http/webif/gtemplates/base.html", line 4, in block "doc"
    {%- block html %}
  File "/usr/local/smarthome/modules/http/webif/gtemplates/base.html", line 76, in block "html"
    {% block body -%}
  File "/usr/local/smarthome/modules/http/webif/gtemplates/base.html", line 79, in block "body"
    {% block content -%}
  File "/usr/local/smarthome/modules/http/webif/gtemplates/base_plugin.html", line 155, in block "content"
    {% block bodytab2 %}
  File "/usr/local/smarthome/plugins/hue2/webif/templates/index.html", line 221, in block "bodytab2"
    <td class="py-1">{{ bridge_lights[l].config.startup.mode }}</td>
  File "/usr/lib/python3/dist-packages/jinja2/environment.py", line 430, in getattr
    return getattr(obj, attribute)
jinja2.exceptions.UndefinedError: 'dict object' has no attribute 'startup'

[mike]

Sie verhält sich eben nicht genau wie eine Philips v1 Bridge.

Mist das ist mein Fehler. Ich bitte vielmals um Entschuldigung. Ich habe die deCONZ-Software schon eine Weile nicht mehr aktualisiert. Alles hatte ohne Probleme funktioniert ...

Jetzt habe ich mal nachgesehen und tatsächlich gibt es schon längst ein Update ... Das habe ich ausgeführt und nun ist das auch eine v2 Bridge (aber API-Version weiterhin auf 1.16).
Diese Version liefert bei der Abfrage globaler Szenen eine leere Liste. Das try-except erübrigt sich daher.

Die alte Philips v1 Bridge ist mir aber dennoch wichtig, da die alten LivingColor Lichter nur mit dieser Bridge funktionieren. Die folgten damals noch einem anderen Standard den deCONZ nicht unterstützt (muss ich auch noch mal mit der aktuellen Version testen).

Die Philips v1 Bridge funktioniert mit dem hue2 Plugin mit den LivingColors bereits einwandfrei.

[whe]

versuche gerade auch mein HUE System auf hue2 umzustellen.
habe jetzt auch mal das plugin auf DEBUG gestellt, aber das discovery funktioniert bei mir nicht.
ich erhalte im webif immer den Fehler 500.
im log finde ich nur folgende Zeilen. Offenbar geht das connect schief:

2021-02-10  14:07:10 INFO     plugins.hue2        Discoverd bridge = {'mac': '001788762a60', 'ip': '192.168.178.50', 'friendlyName': 'Philips hue (192.168.178.50)', 'manufacturer': 'Signify', 'modelName': 'Philips hue bridge 2015', 'modelNumber': 'BSB002', 'serialNumber': '001788762a60', 'UDN': 'uuid:2f402f80-da50-11e1-9b23-001788762a60', 'URLBase': 'http://192.168.178.50:80/', 'version': 'v2'}
2021-02-10  14:07:10 INFO     plugins.hue2        Discoverd bridge = {'mac': 'b827eb0f180f', 'ip': '192.168.178.47'}
2021-02-10  14:07:10 INFO     plugins.hue2        Discoverd bridge = {'mac': 'b827eb3d13d8', 'ip': '192.168.178.42'}
2021-02-10  14:08:08 INFO     plugins.hue2        Connect: connect=

aber warum ? liegt wohl am webif und nicht am plugin.

Nachtrag: die beiden zusätzlichen IP-Adressen vom Discover sind meine beiden raspis; wieso ?

Jetzt hat plötzlich das webif die Bridge doch konfiguriert:

2021-02-10  14:08:08 INFO     plugins.hue2        Connect: connect=
2021-02-10  16:38:53 INFO     plugins.hue2        Connect: connect=001788762a60
2021-02-10  16:38:53 INFO     plugins.hue2        create_new_username: Generated username = ayEREzTffAW-YV84dGKw4wGC46qFjREWcs6YaSf2
2021-02-10  16:38:53 INFO     plugins.hue2        get_bridgeinfo: self.bridge = {'mac': '001788762a60', 'ip': '192.168.178.50', 'friendlyName': 'Philips hue (192.168.178.50)', 'manufacturer': 'Signify', 'modelName': 'Philips hue bridge 2015', 'modelNumber': 'BSB002', 'serialNumber': '001788762a60', 'UDN': 'uuid:2f402f80-da50-11e1-9b23-001788762a60', 'URLBase': 'http://192.168.178.50:80/', 'version': 'v2', 'username': 'ayEREzTffAW-YV84dGKw4wGC46qFjREWcs6YaSf2'}
2021-02-10  16:38:54 DEBUG    plugins.hue2        update_config_section: Beginning to update section 'HUE2' of ../etc/plugin.yaml
2021-02-10  16:38:54 DEBUG    plugins.hue2        update_config_section: valid parameter names to update = ['polltime_lights', 'polltime_sensors', 'polltime_bridge', 'bridge_serial', 'bridge_user', 'bridge_ip']
2021-02-10  16:38:54 INFO     plugins.hue2        update_config_section: Config file = '/usr/local/smarthome/etc/plugin', update data = {'bridge_serial': '001788762a60', 'bridge_user': 'ayEREzTffAW-YV84dGKw4wGC46qFjREWcs6YaSf2', 'bridge_ip': '192.168.178.50'}
2021-02-10  16:38:54 INFO     plugins.hue2        update_config_section: Changing Parameter 'bridge_serial' -> type = 'str' from 'None' to '001788762a60'
2021-02-10  16:38:54 INFO     plugins.hue2        update_config_section: Changing Parameter 'bridge_user' -> type = 'str' from 'None' to 'ayEREzTffAW-YV84dGKw4wGC46qFjREWcs6YaSf2'
2021-02-10  16:38:54 INFO     plugins.hue2        update_config_section: Changing Parameter 'bridge_ip' -> type = 'ip' from 'None' to '192.168.178.50'
2021-02-10  16:38:54 DEBUG    plugins.hue2        update_config_section: Config section content = 'ordereddict([('plugin_name', 'hue2'), ('bridge_serial', '001788762a60'), ('bridge_user', 'ayEREzTffAW-YV84dGKw4wGC46qFjREWcs6YaSf2'), ('bridge_ip', '192.168.178.50')])'
2021-02-10  16:38:54 DEBUG    plugins.hue2        update_config_section: Finished updating section 'HUE2' of ../etc/plugin.yaml

allerdings bekomme ich jetzt den ERROR 500 schon beim Aufruf des webif.
könnte es ein timing Problem sein, weil ich das ganze auf einem lahmen Pi 2 teste; das hat auch an anderer stelle schon mal merkwürdige Effekte.

[Msinn]

Genau das ist der Grund, wieso ich die deconz Bridge erkennen wollte
Sie verhält sich eben nicht genau wie eine Philips v1 Bridge.

Einzelne excepts helfen hier nur bedingt weiter. Ich verschiebe Damit den Fehler an andere Stellen, da das Plugin nicht an jeder Stelle wieder erneut prüft, ob dieser oder jener Teil der Bridge Funktionalität von der jeweiligen Bridge unterstützt wird.

Ich muss eine einfache Möglichket für die deconz Bridge finden. Insgesamt werde ich nicht mehr viel Zeit in v1 Bridges investieren, zumal Philips sie deutlich als End-of-Life klassifiziert hat.

[mike]

Welches der 3 Vorkommnisse von self.br.lights() meinst Du? Oder: Was soll ich sehen?

Sorry, da fehtle etwas Kontext:
Es geht um den commit "hue2: Added support for bridges using port different from default port 80; Caught exception for lights that do not support hue and sat attributes/functions".

Dort in get_bridgeinfo hast du eine Änderung vorgenommen, so dass all Abfrage-Methoden in einem try-except Block laufen:

@@ -557,13 +567,24 @@ class Hue2(SmartPlugin):
             self.bridge_sensors = {}
             return
         self.logger.info("get_bridgeinfo: self.bridge = {}".format(self.bridge))
-        self.br = qhue.Bridge(self.bridge['ip'], self.bridge['username'])
-        self.bridge_lights = self.br.lights()
-        self.bridge_groups = self.br.groups()
-        self.bridge_config = self.br.config()
-        self.bridge_scenes = self.br.scenes()
-        self.bridge_sensors = self.br.sensors()
-        return
+        self.br = qhue.Bridge(self.bridge['ip']+':'+self.bridge['port'], self.bridge['username'])
+        try:
+            self.bridge_lights = self.br.lights()
+            self.bridge_groups = self.br.groups()
+            self.bridge_config = self.br.config()
+            self.bridge_scenes = self.br.scenes()
+            self.bridge_sensors = self.br.sensors()
+        except Exception as e:
+            self.logger.error(f"Bridge '{self.bridge.get('serialNumber','')}' returned exception {e}")
+            self.br = None
+            self.bridge_lights = {}
+            self.bridge_groups = {}
+            self.bridge_config = {}
+            self.bridge_scenes = {}
+            self.bridge_sensors = {}
+            return False
+
+        return True

Sobald also ein Aufruf eine Exception liefert, wird die ganze Bridge als unbrauchbar markiert (zumindest verstehe ich "self.br = None" so) und False zurück geliefert.
Das führt zu dem von mir berichtetem Fehler wo du meintest das käme von meinen eigenen Änderungen.
Wenn du in diesen try-except-Block ein "throw "Test"" einfügst, dann solltest du das Problem nachvollziehen können.

Meine Bitte ist, das nicht so zu machen, sondern jeden einzelnen Aufruf in ein try-except und dann jeweils nur die entsprechende Info als leere Liste setzen. Das hilft bei deconz, da dort scenes() immer eine Exception liefert.

[Msinn]

Kannst du hier bitte mal bei dir in den try-except-Block nach Code:

self.br.lights()

ein throw einfügen und dir ansehen was dann passiert?

Welches der 3 Vorkommnisse von self.br.lights() meinst Du? Oder: Was soll ich sehen?

[Msinn]

Meiner Meinung nach ist das Problem, dass man nur auf API-Version 1.0 Knoten vertrauen darf. Bzw. bei Abwesenheit eines Knotens diese Information nicht liefern kann.

Das ist mir schon klar. Ist auch schon eingebaut.
Wegen anderer Änderungen/Erweiterungen läuft das Plugin aus dem develop aber jetzt nicht mehr mit dem v1.8.1 master. Das bedeutet, dass Du Dich ca. 2 Wochen gedulden musst und erst mit der v1.8.2 in den Genuss kommen wirst.

Eigentlich geht es ja nicht einmal um die Erkennung der deconz-Bridge

Ich möchte nur gerne auch das anzeigen, was man anspricht.

[mike]

Erkennen ist easy. Das hier ist die description.xml:

<?xml version="1.0"?>
<root xmlns="urn:schemas-upnp-org:device-1-0">
  <specVersion>
    <major>1</major>
    <minor>0</minor>
  </specVersion>
  <URLBase>http://127.0.0.1:88/</URLBase>
  <device>
    <deviceType>urn:schemas-upnp-org:device:Basic:1</deviceType>
    <friendlyName>Philips hue (127.0.0.1) compatible Wireless Light Control Gateway</friendlyName>
    <manufacturer>Royal Philips Electronics</manufacturer>
    <manufacturerURL>http://www.dresden-elektronik.de</manufacturerURL>
    <modelDescription>dresden elektronik Wireless Light Control</modelDescription>
    <modelName>Philips hue bridge 2012</modelName>
    <modelNumber>929000226503</modelNumber>
    <modelURL>http://www.dresden-elektronik.de</modelURL>
    <serialNumber>00212EFFFF014181</serialNumber>
    <UDN>uuid:a38c46ea-4b38-4b89-8ec4-b3834cff903d</UDN>
    <gatewayName>Deconz</gatewayName>
    <presentationURL>index.html</presentationURL>
    <iconList>
      <icon>
        <mimetype>image/png</mimetype>
        <height>48</height>
        <width>48</width>
        <depth>24</depth>
        <url>hue_logo_0.png</url>
      </icon>
      <icon>
        <mimetype>image/png</mimetype>
        <height>120</height>
        <width>120</width>
        <depth>24</depth>
        <url>hue_logo_3.png</url>
      </icon>
    </iconList>
  </device>
</root>

Eigentlich geht es ja nicht einmal um die Erkennung der deconz-Bridge. Eine Sonderbehandlung dafür wäre ja blöd.
Meine Original Philips Bridge liefert die "config" und "capabilities" auch nicht! Das ist also kein deconz-Problem.

Meiner Meinung nach ist das Problem, dass man nur auf API-Version 1.0 Knoten vertrauen darf. Bzw. bei Abwesenheit eines Knotens diese Information nicht liefern kann.

Das einzige was mir wirklich negativ an der deconz iaufgefallen ist, ist das sie im Gegensatz zur Philips keine globalen Scenen unterstützt. D.h. die Abfrage der Scenen liefert ein 404 weil es den Knoten im REST gar nicht gibt. Daher bitte ich dich ja darum, wenn diese Abfrage eine Exception wirft dann die Liste der Scenen als leer anzusehen, aber nicht die Bridge komplett rauszuwerfen.

[Msinn]

ort liefert deconz auch "Royal Philips ..". Einfach aus Kompatibiltätsgründen

Das war mir nicht bewusst, dass andere Hersteller dort "schummeln". Meines sind beide original Philipy bzw. Signify Bridges.

Kann ich eigentlich die Deconz Bridge an irgendwas erkennen?

[mike]

Unter https://developers.meethue.com/develop/hue-api/supported-devices/ findet man so etwa ab kurz vor der Mitte (vor 1.2 Dimmable light), die Information in welchem API-Release die jeweiligen Knoten hinzukamen. Dort sieht man "config" gibt es ab 1.24 und "capabilities" ab 1.22. Nur auf die Knoten die seit 1.0 definiert sind kann man sich wirklich verlassen.

[mike]

Schau auf den 1. Post in diesem Thread. Da sieht Du es.

Meinst du im Screen-Dump die Spalte "Hersteller"?

Dort liefert deconz auch "Royal Philips ..". Einfach aus Kompatibiltätsgründen ...
Meine Frage bezog sich daher auf die Hardware an sich und nicht auf das was in der Info zurück kommt. Ich verstehe dich dann aber so, dass du jeweils eine Original Philips/Signify-Bridge hast.

Ich habe eine Original Philips v1 Bridge und den Deconz-Klon.

Diese Meldung: Code:

{% if (bridge_count > 0) and (br_object.config().whitelist|length > 1) %} jinja2.exceptions.UndefinedError: 'None' has no attribute 'config'
Hatte ich abgefangen. Die hast Du durch Änderungen neu erzeugt.

Kannst du hier bitte mal bei dir in den try-except-Block nach

self.br.lights()

ein throw einfügen und dir ansehen was dann passiert?
Also Bridge wieder austragen aus der plugin.yaml und dann neu Verbinden.

Die letzte Änderung "hue2: Added support to webinterface for bridge/lights that do not support startup-mode" geht schon in die richtige Richtung. Allerdings gibt es auch Lampen die "config" und "capabilities" _komplett_ nicht unterstützen. D.h. es gibt weder einen "config" noch einen "capabilities" Knoten.
Das ist bei mir auch bei der Original Philips v1 Bridge so. (siehe die Lights-Ausgabe weiter oben, die ist von dieser Bridge).

[Msinn]

Schau auf den 1. Post in diesem Thread. Da sieht Du es.