Neues Version Plugin HUE zum Betatest

[Msinn]

Feedback zur v0.95, Teil 1: Default Werte

Hallo Michel,

soweit ich feststellen konnte, funktioniert soweit alles. Was nicht bedeutet, dass ich keine Anmerkungen hätte.
Ich teile das auf mehrere Post auf, damit das übersichtlich bleibt.

plugin.conf

cycle_lamps, cycle_bridges und default_transitionTime: Haben diese Attribute Default-Werte? (Doku)

items.conf

hue_bridge_id: Die Warnung beim setzen des defaultwertes der hue_bridge_id ist nur sinnvoll, wenn mehrere Bridges konfiguriert sind, sonst muss man über all den parameter definieren nur um die Warnung wegzubekommen.

hue_lamp_id: Setzen eines defaultwertes nicht unbedingt sinnvoll -> bei mir schaltete unerwartet eine Leuchte (die die ID 1 hat). Ausserdem weicht die Doku ab. Dort ist als Defaultwert 0 angegeben im Log steht es wird auf Default = 1 gesetzt.

[Msinn]

Feedback zur v0.95, Teil 2: Dokumentation

In der README.md ist in meinen Augen die Dokumentation zu vervollständigen.

Beschreibung der plugin.conf:

Beschreibung anpassen und ergänzen gemäß Feedback Teil 1


Beschreibung der items.conf:

Die Beschreibungen zu einer großen Zahl von Attributen fehlen. Wer das Hue API nicht kennt ist da etwas verloren. Das betrifft folgende Attribute:
bridge_name, zigbeechannel, mac, dhcp, ipaddress, netmask, gateway, utc, localtime, timezone, whitelist
bridge_swversion, apiversion, swupdate, portalconnection, portalstate
power, reachable, ct, scene, bri, dim, sat, col_r, col_g, col_b, hue, dim, effect, alert
modeltype, (name), modelid, swversion

Bei welchen Attributen geht DPT3 dimming?

Das Attribut 'name' sollte im Beispiel und in der Beschreibung einen anderen Namen erhalten. Mit 'name' kann wie wir gemerkt haben smarthome.py nicht umgehen.

Es wäre übersichtlicher, wenn bei der Beschreibung jedes Attributes beschrieben wird, ob das Attribut les- und/oder schreibbar ist. Dann muss man nicht für jedes Attribut bei hue_listen und hue_send nachsehen.

Es hilft auch, wenn bei jedem Attribut beschrieben wird, ob es sich auf die bridge (hue_bridge_id) oder eine Leuchte (hue_lamp_id) bezieht. Das kann ach dadurch erreicht werden, dass die Attribute in der Doku nach Zugehörigkeit (Bridge/Light) sortiert werden.

[Orion]

Hallo Martin,

zu plugin.conf:
ja, die haben Default Werte (packe ich ins readme)

zu items.conf: Bei den Bridges bin ich wohl zu viel am loggen, ich nehme das noch für das Release raus, weil es ja auch so in Ordnung ist.

hue_lamp_id fehlend: da hast Du mit Deiner Anmerkung recht. Wenn das nicht da ist, würde ich lieber einen Error setzen und das Plugin Abbrechen. Dieser Anteil der Konfig sollte schon korrekt gesetzt sein.

Michel

[Msinn]

Feedback zur v0.95, Teil 3: Geändertes Verhalten

Hallo Michel,

ich hatte in einer der früheren Versionen bei mit in der items.conf eine "Quick & Dirty" Lösung implementiert, um standartmäßig das Licht in weiss einzuschalten, wenn OnOff (power) bedient wird (egal welche Farbe vorher eingestellt war).

Um nicht extra eine Logik zu schreiben, hatte ich bei 'ct' eoin eval mti Trigger definiert:

[[[[ct]]]]
    type = num
    hue_id = 3
    hue_send = ct
    hue_listen = ct
    enforce_updates = on
    eval = 343 if sh.wohnung.buero.dreieckschrank.onoff() else sh.wohnung.buero.dreieckschrank.ct()
    eval_trigger = wohnung.buero.dreieckschrank.onoff

Wenn OnOff betätigt wurde, wurde 'ct' auf 343 gesetzt und per enforce_updates sichergestellt, dass es auch an die Leuchte gesendet wurde. (Der else-Zweig steht da nur, weil ich im eval kein if ohne else hinbekam.)
Das funktionierte auch gut (bis incl. v0.92). Ich konnte alle Farben setzen und auch mit einem Slider für 'ct' alle Weiss-Werte ansteuern.

Jetzt ist 'ct' auf 343 "festgenagelt". Der Trigger (Veränderung von 'OnOff') scheint ständig auszulösen. Wenn ich eval und eval_trigger auskommentiere, verhält sich 'ct' wieder wie gewohnt. Allerdings schaltet 'OnOff' dann (wie zu erwarten) in der letzten eingestellten Farbe ein.

... Dann muss ich wohl doch 'ne Logik erstellen.

Mit diesem Verhalten kann ich leben. Es ist nicht unbedingt ein Fehler. Ich wolle es Dir trotzdem beschreiben, da es ein Indiz für ein Fehlverhalten sein kann, welches ich im Moment nicht überblicke.

So jetzt bin ich mit dem Testlauf soweit durch. Ich werde jetzt alle Leuchten für die v0.95 umkonfigurieren und beobachten, ob dann noch Punkte hochkommen.

[Msinn]

Feedback zur v0.95, Teil 4: hue_ip in plugin.conf

Hallo Michel,

ich hatte zum Test die Section in der plugin.conf ganz minimalistisch ausgelegt:

[HUE]
    class_name = HUE
    class_path = plugins.hue
    hue_user = knxbususer

Daraufin bekam ich beim Start von smarthome.py folgendes log:

2015-01-10 18:24:58 ERROR    Main         HUE: Error in plugin.conf: you have to specify all hue_ip
2015-01-10 18:24:58 ERROR    Main         Plugin HUE exception: HUE: Plugin stopped due to configuration fault in plugin.conf
Traceback (most recent call last):
  File "/usr/local/smarthome/lib/plugin.py", line 53, in __init__
    plugin_thread = Plugin(smarthome, plugin, classname, classpath, args)
  File "/usr/local/smarthome/lib/plugin.py", line 80, in __init__
    exec("self.plugin = {0}.{1}(smarthome{2})".format(classpath, classname, args))
  File "<string>", line 1, in <module>
  File "/usr/local/smarthome/plugins/hue/__init__.py", line 53, in __init__
    raise Exception('HUE: Plugin stopped due to configuration fault in plugin.conf')
Exception: HUE: Plugin stopped due to configuration fault in plugin.conf

Das war unerwartet, da in der README drin steht, dass man hue_ip nicht angeben muss, dann würde der default 'Philips-hue' genommen.


2. Versuch: hue_ip = Philips-hue ergänzt.
Dann habe ich keinen Log Eintrag nach dem Start. Wenn ich aber etwas warte, erhalte ich seitenweise Wiederholungen der folgender Fehlermeldungen:

2015-01-10 18:26:12 ERROR    hue-update-bridges Method hue-update-bridges exception: [Errno -2] Der Name oder der Dienst ist nicht bekannt
Traceback (most recent call last):
  File "/usr/local/smarthome/lib/scheduler.py", line 344, in _task
    obj()
  File "/usr/local/smarthome/plugins/hue/__init__.py", line 476, in _update_bridges
    returnValues = self._request(hueBridgeId, '/config')
  File "/usr/local/smarthome/plugins/hue/__init__.py", line 347, in _request
    connectionHueBridge.request(method, "/api/%s%s" % (self._hue_user[int(hueBridgeId)], path), data)
  File "/usr/lib/python3.2/http/client.py", line 970, in request
    self._send_request(method, url, body, headers)
  File "/usr/lib/python3.2/http/client.py", line 1008, in _send_request
    self.endheaders(body)
  File "/usr/lib/python3.2/http/client.py", line 966, in endheaders
    self._send_output(message_body)
  File "/usr/lib/python3.2/http/client.py", line 811, in _send_output
    self.send(msg)
  File "/usr/lib/python3.2/http/client.py", line 749, in send
    self.connect()
  File "/usr/lib/python3.2/http/client.py", line 727, in connect
    self.timeout, self.source_address)
  File "/usr/lib/python3.2/socket.py", line 397, in create_connection
    for res in getaddrinfo(host, port, 0, SOCK_STREAM):
socket.gaierror: [Errno -2] Der Name oder der Dienst ist nicht bekannt

3. Versuch: Wenn ich hue_ip = 10.0.0.136 setze, läuft alles.

[Msinn]

XY to RGB Conversion

Hi Michel,

Du warst mit den erreichbaren Farben bei der Umwandlung nicht zufrieden. Das könnte an den angesteuerten Leuchten liegen. Welche Typen hast Du denn im Einsatz? (Mein Schwerpunkt liegt bei den Hue Bulbs. Ich habe aber auch von den "Living Colors" eine Leuchte und LED Stripes)

Der erreichbare Farbraum ist unterschiedlich für Hue Bulbs und die Friends of Hue. Im Converter kann das in den ersten drei Zeilen der Class ColorHelper beeinflusst werden. Der Standard ist:

class ColorHelper:

    Red = XYPoint(0.675, 0.322)
    Lime = XYPoint(0.4091, 0.518)
    Blue = XYPoint(0.167, 0.04)

Ich habe jetzt noch folgende Information gefunden:

Current Philips lights have a color gamut defined by 3 points, making it a triangle.

For the hue bulb the corners of the triangle are:

Red: 0.674, 0.322
Green: 0.408, 0.517
Blue: 0.168, 0.041

For LivingColors Bloom, Aura and Iris the triangle corners are:

Red: 0.703, 0.296
Green: 0.214, 0.709
Blue: 0.139, 0.081

Wenn Du Living Colors einsetzt, probiere doch mal die zweite Zahlengruppe im Converter aus und melde Dich zurück.

[Orion]

Hallo Martin,

Teil 3:

Muß ich mal nachstellen. Ich da eine Ahnung was ich geändert hatte. Aber ein Loop sollten nicht entstehen. Es gibt eine Routine, die beim Setzen der Werte die von der darauf Bridge zurückgemeldeten wieder in die Items zurückschreibt. Eigentlich ganz sinnvoll, wenn etwas nicht komplett an der Bridge ankommt. In Vergangenheit hatte ich die Routine drin, hatte aber eine Fehler und kam nie zum Tragen. Jetzt funktioniert sie... mal sehen.

Teil 4:

Bei mir hatte die Adresse Philips-hue nie funktioniert, sondern immer nur die IP Adresse, daher hatte ich das als default herausgelassen. Wenn es bei dir funktioniert hatte, nehme ich sie einfach wieder rein !

Zu den Farben: Schöne info, probiere ich mal aus. da muß mir nur etwas einfallen um die Farbkonvertierung anzupassen. In der Library ist ja die erste Variante eingebunden. Damit muß ich an diese Library ran.

Teil 1:

Die Dicht werde ich noch etwas verbessern. Aber ganz ehrlich: ich würde ungern ein 1:1 Kopie in der Erklärung der Hue API machen. Wenn jemand diese Details einsetzen will, dann muß er sich etwas einlesen. Ich habe sie ja teilweise auch nur einfach "rausgelegt" ohne mich wirklich mit zu beschäftigen. Ich glaube ich würde es nur verschlimmbessern. Ich packe einen Link auf die Doku rein.

Wegen attribut = name: das geht bei mir ohne Probleme !?

Grüße Michel

[Msinn]

Hallo Michel,

Teil 4:

Bei mir hatte die Adresse Philips-hue nie funktioniert, sondern immer nur die IP Adresse, daher hatte ich das als default herausgelassen. Wenn es bei dir funktioniert hatte, nehme ich sie einfach wieder rein !

Nein, bei mir funktioniert Philips-hue auch nicht, in Deiner README ist aber beschrieben, es würde funktionieren.

Vieleicht hilft eine Namensauflösung bevor Du

        connectionHueBridge = http.client.HTTPConnection(self._hue_ip[int(hueBridgeId)])

aufrufst.

Bei einer Socket Komunikation mache ich das mit

realip = socket.gethostbyname( host )

wobei host bereits eine IP-Adresse sein darf

Zu den Farben: Schöne info, probiere ich mal aus. da muß mir nur etwas einfallen um die Farbkonvertierung anzupassen. In der Library ist ja die erste Variante eingebunden. Damit muß ich an diese Library ran.

Ist für Dich auch erstmal 'ne Info zum testen. Ist nicht für Release 1.0 gedacht.

Teil 1:

Die Dicht werde ich noch etwas verbessern. Aber ganz ehrlich: ich würde ungern ein 1:1 Kopie in der Erklärung der Hue API machen. Wenn jemand diese Details einsetzen will, dann muß er sich etwas einlesen. Ich habe sie ja teilweise auch nur einfach "rausgelegt" ohne mich wirklich mit zu beschäftigen. Ich glaube ich würde es nur verschlimmbessern. Ich packe einen Link auf die Doku rein.

Ein Hinweis auf das API ist sicherlich nicht schlecht. Für den Nutzer des Plugins aber aufwendig. Er muss sich für den Zugang zum API registrieren und sich dann da durcharbeiten. (Das ist nicht für jeden Nutzer von Hue leistbar)

Wenn Du die README soweit fertig hast, würde ich mich bereit erklären Beschreibungen zu ergänzen.

Wegen attribut = name: das geht bei mir ohne Probleme !?

Ich hatte Dir weiter vorne im Thread den Trace geschickt und Du hattest geschrieben, dass das von ausserhalb des Plugins käme (war mir schon klar). Wenn ich ein Attribut in der items.conf [name] nenne, kommt der Trace. Nenne das Attribut in der README doch einfach [lightname] oder so...

[Orion]

Hallo Martin,

schau mal bei develop 0.96 ins Readme. Dein Angebot nehme ich gerne an, habe schon etwas gemacht. Passt jetzt besser.

Die Namensauflösung werde ich mal ausprobieren, ansonsten eher der Hinweis dass dort etwas einzutragen ist mit der Fehlermeldung die du ja gesehen hattest.

Dein Thema mit dem eval kann ich bei mir nicht nachvollziehen. On setzt 343, ich kann das ändern und es bleibt so. beim mir setzt aber auch das ausschalten 343.

Aus meiner Sicht muß enforce_updates = yes nicht unbedingt gesetzt sein ??? Aber bei eval kennen ich mich nicht gut genug aus.

Michel

[Sandman60]

Hallo Michel, Martin,

mußte leider zwangsweise ein paar Tage aussetzen und konnte nicht wirklich testen.

Bzgl. Namensauflösung. Kann nichts zur aktuellen Version des Plugins sagen, aber in der ersten Version hat es bei mir auf Anhieb mit dem Default-Namen geklappt.

Komme hoffentlich morgen nun endlich zu den finalen Tests und melde mich wieder.

Cheers,
Oliver

[Msinn]

Hallo Michel,

was ist denn in der v0.96 neu? Ich habe sie noch nicht installiert.

Ich habe mich erstmal über die README hergemacht. Die Tabellen mit den Attributen gefallen mir schon ganz gut. Ich gruppiere Sie noch ein wenig nach Funktion (analog zum Hue-API) und ergänze einige Texte.

Ich entferne auch die TABs aus den Tabellen. Ich habe die Datei mit verschiedenen (Text- und Markdown-Editoren) geöffnet und die Tabellen sahen immer etwas anderes aus.

[Orion]

Hallo Martin,

Neu war im das readme und die Herausnahme dess Loggings für fehlende Bridge Einträge bei nur einer Bridge. Funktional keine Änderung.

Michel

[Msinn]

Hi Michel,

ich habe die Tabellen überarbeitet (sortiert formatiert). Dabei habe ich zum Lights API zwei Sätze ergänzt und hue_transitionTime ergänzt. (Iste der Name nicht etwas lang?).

Bei der transitiontime war ich mir nicht sicher, ob Du die auch lesbar ausgeführt hast. Deshalb ist in der Tabelle dort noch ein Fragezeichen.

Bei der hochgeladenen Datei habe ich ein .txt angehängt, da das Forum die Datei sonst nicht hochladen wollte.

[Sandman60]

Moin,

bin gerade dabei das Plugin einzufügen und die items.conf anzugleichen mit meiner bisherigen items.conf.

Dabei ist mir im Readme noch ein Typo bei der Netmask aufgefallen, hier steht netwask anstatt netmask.

Die Items-Conf. kann ja jeder anlegen wie er will, mein Favorit ist aktuell die items.conf analog den API-Daten aufzubauen, sprich es gibt jeweils eine Mittelsektion [config], [lamps] usw. Werde nun testen ob das auch noch so stringent durchzuhalten ist und Euch das Ergebnis dann mal zuschicken...

Cheers,
Oliver

[Orion]

Hallo Martin, Oliver

@Martin: Danke für die redaktionelle Arbeit. Ich habe es mal in GitHub hochgeladen, da kannst Du Dir das auch nochmal anschauen.

Ein Punkt: ich hatte die Trennung bei mehreren Parametern in der plugin.conf durch Kommata getrennt nicht Semikolon. Würde ich so lassen und habe das auch so angepasst.

@Oliver: Richtig gefunden. Hatte nachdem ich den Parser auf Fehlermeldungen getrimmt hatte auch automatisch ausgespuckt. hatte es nur nicht in der Doku korrigiert. Ist aber auch gemacht !

...nach wie vor in v0.96 develop....

Michel