Neues Version Plugin HUE zum Betatest

[Msinn]

Hallo Michel,

ich habe meine Hue Leuchten so eingerichtet, dass sie von der KNX Seite aus sich so verhalten (sollten) wie ein "normaler" KNX-Dimmer (5 Gruppenadressen incl. Antworten auf Read-Requests vom KNX-Bus):

        [[[tischleuchte]]]
            name = Tischleuchte
            type = bool
            hue_id = 1
            hue_send = on
            hue_listen = on
            knx_dpt = 1
            knx_listen = 2/1/13
            knx_status = 2/2/13
            knx_reply = 2/2/13
            [[[[reachable]]]]
                type = bool
                hue_id = 1
                hue_listen = reachable
            [[[[bri]]]]
                type = num
                cache = on
                hue_id = 1
                hue_send = bri
                hue_listen = bri
                hue_transitionTime = 0.1
                knx_dpt = 5
                knx_listen = 2/4/13
                knx_cache = 2/4/13
                knx_status = 2/5/13
                knx_reply = 2/5/13
                [[[[[dim]]]]]
                    type = list
                    knx_dpt = 3
                    knx_listen = 2/3/13
                    hue_dim_max = 255
                    hue_dim_step = 15
                    hue_dim_time = 0.1

Wenn ich jetzt von der KNX Seite aus schaue, verhält sich der Hue-Dimmer jedoch in einem Punkt etwas anders als ein KNX-Dimmer.

Ein KNX-Dimmer meldet im ausgeschalteten Zustand Off und eine Helligkeit von 0 zurück. Der Hue-Dimmer meldet jedoch Off und die letzte eingestellte Helligkeit zurück.

[Msinn]

Was mich nun noch interessieren würde wäre der "config" Strang, insb. die Daten aus der Bridge.

Zu "scenes", "groups" und "schedules" fehlen mir noch Infos, werde da mal noch etwas recherchieren....

Hi Michel,

ich arbeite zurzeit mit Hue-Szenen. Das hat damit zu tun, dass ich damit auch Leuchten schalten kann, von denen meine Bridge behauptet sie nicht zu "sehen".

Für mich wäre eine Funktion aus dem Groups-API interessant (Set Group state). Das ist der Aufruf einer gespeicherten Szene:

PUT: /api/<username>/groups/<id>/action

mit dem Body:
{ "scene": "<scenename>" }

Das definieren von Szenen ist glaube ich mit der iPad App erstmal am einfachsten. Anschließend muss man jedoch den Namen der eben erzeugten Szene über

GET: /api/knxbususer/scenes

herausfinden.

[Msinn]

...und noch einer:

Michael,

mir ist beim weiteren umstellen aufgefallen, dass Du das Attribut 'ct' nicht implementiert hast. Ich nutze das bei zwei Leuchten um den Weisston dem Umgebungslicht anzupassen (2000K bis 6500K).

[Orion]

Hallo Martin,

zu Deinem ersten Punkt:

Da habe ich keinen Ausweg. Die Hue vergessen ihren alten Helligkeitswert von selbst. Damit lasse ich ihn im item stehen, um ihn beim wieder Anschalten zu haben. Setze ich ihn auf 0, steht die Lampe auf Minimalwert. Einen weiteren Item dafür zu spendieren will ich nicht machen. Das positive daran. In der Visu kannst Du sofort sehen, auf welchen Wert die Lampe springen wird, sobald du sie anmachst.

zum zweiten Punkt:

Den Szenenabruf werde ich wahrscheinlich noch ins erste Release mit aufnehmen. Was ich nicht machen werde ist die komplette Konfiguration der Kampen und Szenen. Hier braucht es neben der Funktion auch ein sauberes User Interface. Ein widget dazu liegt im Moment nicht auf meiner Prioliste.

zum dritten Punkt:

Mal sehen....

Grüße Michel

[Msinn]

Hallo Michel,

zu Deinem ersten Punkt:

Da habe ich keinen Ausweg. ... Das positive daran. In der Visu kannst Du sofort sehen, auf welchen Wert die Lampe springen wird, sobald du sie anmachst.

Damit kann ich gut leben. Ist auch mehr ein Hinweis, dass sich eine Hue-Leuchte (auch in der SmartVISU) einen Tick anders verhält als ein KNX Dimmer.

zum zweiten Punkt:

Den Szenenabruf werde ich wahrscheinlich noch ins erste Release mit aufnehmen. Was ich nicht machen werde ist die komplette Konfiguration der Kampen und Szenen.

Auch damit kann ich gut leben. Ich hatte schon geschrieben, dass das Definieren (macht man auch nur selten und es gibt auf dem iPad ein gutes Interface) für mich auch anders geht.

zum dritten Punkt:

Mal sehen....

Das ist für mich, da ich die Produktivumgebung von smarthome.py auf das neue Plugin umstelle essentiell. Ich habe mir das in ver v0.7 schnell nachimplementiert. Im Großen und Ganzen nur den 'bri' Block kopiert und die min und max Werte auf 153 und 500 gesetzt.

[Msinn]

Hallo Michel,

Du hattest geschrieben:

Generell stelle ich fest, dass der Converter nicht optimal ist. Für bessere Vorschläge bin ich immer zu haben.

Wo siehst Du Verbesserungspotenitial?

Ich habe noch im Hinterkopf (irgendwo gelesen), dass 'Hue Lightbulbs' und 'Friends of Hue' (also: LDS Stripes und die Leuchten zum hinstellen) einen unterschiedlichen Farbraum haben und dieses auch bei der Umwandlung durch das Ändern von Parametern berücksichtigt werden kann/muss. Falls es darum geht, suche ich das gerne nochmal raus.

[Orion]

Hallo,

wenn mir kein grosser Fehler unterlaufen ist (da werde ich nochmal kurz die Tasten schwingen) ist jetzt der aktuelle Stand master 0.7 und in develop die version 0.8.

changelog v0.8:

- viel refactoring am code
- viele wertechecks und warnings falls notwendig
- ct als feature mit rein
- Szenenabruf als alpha mal zum Testen (hier bitte darauf achten auf enforce_updates = true, sonst nur einmal die Szene abrufbar)
- interaktive function get_config(), die in ein logger.info alle user und alle bekannten Szenen schreibt. Hier kann man sich auch die kryptischen szenennamen, die man auf z.B. dem iPad geschrieben hat heraussuchen für die Visu.

Ansonsten muß sich das alles jetzt mal setzen.

@Martin: Schön, dass Du so einfach den Code ändern kannst ich hoffe er ist leserlich genug. So soll es ja sein. Wenn Du es schon produktiv einsetzt, alle Achtung! Es ist aus meiner Sicht noch kein erstes Release, da haben wir alle zu wenig im Grenzbereich getestet. Wegen der Konvertierung: Gefühlt komme ich nicht in alle Farben per z.B. Colordisk, die ich aber mit bri, sat und hue einstellen kann. Das Thema ct mußt Du testen, habe dazu leider keine Verwendung !

Viel Spaß

Michel

[Msinn]

Hallo Michel,

Deine Reaktion auf Wünsche und die Geschwindigkeit der Implementation ist grandios.

Ich habe die Szenen bisher noch nicht getestet. Ich will Dir aber meine bisherigen Findings nicht vorenthalten:

README:
- Die Beschreibung der Attribute für dir items ist nicht vollständig
- in der items/test.conf hast Du ein Item [[[name]]] genannt. Wenn ich das tue, fliegt mir smarthome.py um die Ohren (das ist etwas für Marcus). Nachdem ich das Item umbenannt hatte, ging alles gut.
- get_config() ist nicht dokuentiert

'ct':
- funktioniert, damit es sicher funktioniert sollte enforce_updates gesetzt sein -> Ein Fall für die Doku

Szenen (noch nicht wirklich getestet):
- Wozu muss ich die hue_id setzen? Szenen sind nicht Leuchten-spezifisch. Ja, Du nutzt hue_id als Trigger, ob Du bei dem Item was tun musst, dazu muss dann hue_id gesetzt sein, kann aber einen beliebigen Wert haben. -> Entweder anderen Trigger wählen, oder dokumentieren, dass hue_id = yes auch richtig ist
- Szenen basieren auf dem API 1.4. Da Du in der Funktion get_config() das Szenen API nutzt, solltesd Du den Header-Kommentar in __init__.py anpassen

get_config()
- um die Szenen aufzurufen, musst Du die definierten User nicht auslesen. Jeder User des 'whitegelistet' ist, kann mit der Bridge alles tun. Es gibt keine benutzerabhängigen Szenen, weshalb das iPad wohl so kryptische Namen vergibt.

[Msinn]

Hallo Michel,

einen hab' ich noch zur v0.8...

Im Normalfall funktioniert das Einschalten in der Helligkeit, in der sie ausgeschaltet wurde.

Wenn ich jedoch, während eine Hue-Leuchte eingeschaltet ist, smarthome.py durchstarte, wird bei der Initialisierung die Leuchte dunkler (nicht jedoch minimale Helligkeit).

Wenn beim Durchstart von smarthome.py die Leuchte ausgeschaltet ist, bleibt sie ausgeschaltet.

[Orion]

Hallo Martin,

Danke für die Rückmeldung. Mit der Geschwindigkeit kann ich dich beruhigen, es wird nicht so bleiben, wenn die Ferien rum sind 😉.

Wegen der Szenen: ich habe das mal schnell eingebaut, um zu sehen, wie weit das Architektur Konzept des Plugins trägt. Deswegen ging eigentlich auch alles schnell. Die Szenen passen nicht wirklich rein. Das siehst du schon wegen dem Hinweis auf die hue_id. ich würde da eher Abstand von nehmen. Mit den Szenen, die ohnehin in smarthome schon drin sind geht das gleiche, zusätzlich aber auch alle Anderen Umfänge. Daher brauche ich das nicht aufzudoppeln nur für die hue.

Wegen Name im Ihrem: ich habe das genau so, und es ist kein Problem bei mir.
Mit dem enforce_updates : wenn du mehrfach den gleiche Wert senden willst, dann muss es rein.

Mit den Helligkeiten beobachte ich auch einmal.

Grüße Michel

[Msinn]

Hallo Michel,

mein Hinweis bei den Szenen auf den Trigger hue_id war auch etwas allgemeiner gemeint. Es gibt einige Funktionen die vieleicht von Interesse sind, die nicht die Hue Leuchtmittel adressieren, sondern die Bridge. Wenn Du z.B. die Firmware der Bridge oder die API Version zurückmelden willst...

Die Hue Szenen würde ich nicht unterschätzen. Wo möglich werde ich auch die Szenen innerhalb von Smarthome nutzen. Allerdings ermöglichen die Hue Szenen und Gruppen einen völlig synchronen Farbwechsel über die adressierten Leuchten. Ich erzeuge damit synchrone Farbwechsel über 7 Leuchten.

[Msinn]

Hallo Michel,

ich schon wieder...

Mir sind zum Logging einige Punkgte aufgefallen.

1. Es wäre evtl. sinnvoll den Log-Texten ein 'HUE:' voranzustellen, wie das z.B. das KNX Plugin macht

2. Ich habe zwei Log Einträge gefunden, die mich auf die Suche schicken, da sie mir nicht verraten, bei welchem Item ich vergessen habe ein Attrobut zu setzen:

2015-01-05 01:20:42 WARNING  Main         _dimmenDPT3: no hue_dim_step defined using default
2015-01-05 01:20:42 WARNING  Main         _dimmenDPT3: no hue_dim_time defined using default

3. Durch eval Funktionen sende ich (unbeabsichtigt und auch nicht störend) Kommandos au eine Leuchte wenn sie ausgeschaltet ist. Ich bin mir nicht sicher, ob das jedes mal einen Log Eintrag wert ist

2015-01-05 01:28:19 WARNING  wohnung.gast.tischleuchte.ct hue_set_lamp_state - hueObjectStatus no success:: error: {'type': 201, 'description': 'parameter, ct, is not modifiable. Device is set to off.', 'address': '/lights/1/state/ct'} command state {'transitiontime': 1, 'ct': 343}

Ich habe die evals bisher nicht so formuliert bekommen, dass sie nur im eingeschalteten Zustand senden.

Die Log Einträge zum senden an ausgeschaltete Lampen können in anderen Situationen sicherlich hilfreich sein. Deshalb meine Frage, ob die Einträge schaltbar gemacht werden können (entweder durch einen Eintrag in der plugin.conf oder durch ein Logging als DEBUG statt als WARNING).

[Orion]

Hallo Martin,

es gibt die 0.9 zum Test auf Github.

changelog:

Die Meldungen sollten jetzt entweder eindeutig sein oder nicht mehr kommen. Da hatte ich einen Fehler in der Zustandsauswertung. Wenn Lampe aus, brauche ich nichts zu schicken. Damit ist aber der Automat komplett neu ! Sollte identisch bis auf diesen Fall arbeiten....wir werden sehen.

Die Szene hat jetzt eine hue_bridge als Kennzeichen. Bitte mal ausprobieren. Hast Du eine Ahnung, wie bei Hue die Bridges durchnummeriert sind ? Ich würde gerne die IDs dafür identisch wählen wie bei den Lampen auch.

Michel

[Sandman60]

Die Szene hat jetzt eine hue_bridge als Kennzeichen. Bitte mal ausprobieren. Hast Du eine Ahnung, wie bei Hue die Bridges durchnummeriert sind ? Ich würde gerne die IDs dafür identisch wählen wie bei den Lampen auch.

Kann meine zweite Bridge zu Testzwecken gerne in Betrieb nehmen, brauche dann allerdings noch Infos bzgl. dem Testcase was Du wissen möchtest.

[Orion]

Hallo Oliver,

super Idee, allerdings habe ich keine zweite Bridge :-)

....und der Code dafür ist auch noch nicht geschrieben. Insofern mußt Du erst einmal die Variante mit einer Bridge testen.

Michel