Phillips HUE mit Loxone verwenden

[Gast]

Was ist ein WA? Hast du einen Link?

[hme0354]

Post 455 vom 23.Nov.2019, 22:14

[Gast]

Okay ich habe das gemacht was bei 455 stand, dabei kam das in meinem Browser raus:
[{"error":{"type":4,"address":"/","description":"method, GET, not available for resource, /"}}] passt das? wenn ja soll ich dann wie auf der Developer Seite so weiter machen, also /api und

{"devicetype":"my_hue_app#iphone peter"}

Und dann Button drücken und dann auf Post? Passt das dann so?

Grüße Leonard

[Gast]

Habs geschafft sorry wegen dem stress

Grüße

[DeadMau5]

Hi zusammen,
vielen herzlichen Dank Euch allen schonmal für diese super Skript und die ganzen Hilfestellungen hierzu. Hab es gerade eben endlich erfolgreich geschafft meine Hue Lampen in die Loxone zu integrieren.
Ich hatte jetzt leider nur bei Verwendung des neuesten Skripts vom 5.1.2020 ein etwas größeres Problem. Ich hab es damit überhaupt nicht zum Laufen bekommen.
Letztendlich habe ich folgendes aus meine Loxone Log auslesen können:

2020-01-11 00:17:48.568;PRG got restart command
2020-01-11 00:17:50.658;Loading sps_new.zip - Remove old custom changes
2020-01-11 00:18:08.663;PRG start program
2020-01-11 00:18:08.945;RestoreRemanenceState /sys/rem/rem36.xml and /sys/rem/rem136.xml OK, /sys/rem/rem1098.xml for Messagecenter OK
2020-01-11 00:18:09.431;Program started: /prog/sps_0173_20200110235741.zip
2020-01-11 00:18:10.057;Rename program /prog/sps_0173_20200111001809.zip
2020-01-11 00:18:20.298; if (bri == 1 OR bri == 255) {
^
Programm:185:16 identifier not expected here

Ist dieser Fehler bereits sonst bei jemandem aufgetreten? Ich bin leider nicht wirklich Fit in Pico C und konnte den Fehler nicht beseitigen. Erst mit Verwendungen des etwas älteren Skripts hat es bei mir geklappt.

Danke Euch schon mal im voraus.
Grüße, Matthias

[romildo]

OR wird von PicoC nicht verstanden. Es müsste || sein.
Also: if (bri == 1 || bri == 255) {

[svethi]

Das hatte ich auch schon gemerkt und auch geändert. Hatte nur leider dem Andreas die falsche Version geschickt. Ist ja aber nun alles schon längst Geschichte. Ich hab ja nun schon eine korrigierte Version gepostet und Andreas hat die auch schon im Post 1 ausgetauscht.
Solche blöden Typofehler entstehen, wenn man ständig zwischen verschiedenen Sprachen hinundher springt ;-)

[svethi]

Ach Du Schreck, da habe ich dem Andreas wohl ne falsche Version geschickt. Ich stelle die richtige nachher mal zur Verfügung

[svethi]

So, hier die richtige Version

[frankenhooker]

Danke, die neue Version funktioniert nun auch bei mir.

[einzelkind]

Vielen Dank, für das Script. Wäre es möglich, dass das Script den IST-Wert der Lampen in einem Intervall abfragt?

[Gast]

Hallo,

ich bin gerade auf der Suche nach Infos, um meine Hue Bridge 2 (weiß nicht ob es eine 2.0 oder 2.1 ist - hab sie in der 2. Hälfte 2019 im Offlineshop "zwischen Jupiter und Uranus" gekauft) mit Loxone zu verbinden und auch in Loxone-Lichtszenen einzubinden. Ich habe elf Leuchten der Art RGB-CCT (also 5-Kanäle mit R, G, B, CW, WW [cold white, warm white]) LED-Streifen, die ich über Zigbee Controller von Iluminize mit der Hue-Bridge verbunden habe und per Philips Hue App auch schon normal ansteuern kann (also bisher noch ohne Loxone). Philips Hue kennt ja auch diese 5 Kanäle.

Ich habe im Internet nun im Wesentlichen zwei Ansätze gefunden, die sich offenbar unterscheiden(??) (sorry, sich fange gerade an):

• Dieser Thread "https://www.loxforum.com/forum/faqs-tutorials-howto-s/7738-phillips-hue-mit-loxone-verwenden"
• Oder "https://ownsmarthome.de/2017/03/25/philips-hue-in-loxone-integrieren/" (mit sogenanntem PicoC-Skript)

Im ersten Fall (hier) wird ein Text file angeboten, das sich wie ein C-File liest. Im zweiten Fall wird eien XML-File angeboten, das aber auch C-Code enthält.

Beide Ansätze scheinen sich unabhängig voneinander entwickelt zu haben und einen anderen Ansatz zu verfolgen.

In allen Beschreibungen ist stets nur von R,G,B zu lesen, soweit ich es erkennen kann, also drei Kanäle. Ich frage mich, ob die schönen Warm/Kaltweiß-LEDs überhaupt unterstützt werden bei den Loxone-Philips-Hue-Lösungen.

Bevor ich mich nun weiter irgendwo vertiefe, eine Frage vorab, weil ich dieses Thema nie behandelt sehe in den Diskussionen:

• Welchen Ansatz soll ich verfolgen?
• Hat der Ansatz in diesem Thread auch Unterstützunfg für die RGB-CCT 5-Kanal-Leuchten (also R,G,B,CW,WW)?
• Kennt jemand auch den anderen Ansatz (siehe oben) mit PicoC-Skript und kann etwas dazu sagen im Vergleich? Vorteile/Nachteile?

Vielen Dank!

[romildo]

Hallo,
Beide Links beziehen sich auf das PicoC-Skript. Beim Text file handelt es sich um das PicoC-Programm welches in den Programmbaustein eingefügt werden muss.
In diesem Thread bist Du also genau richtig und solltest auch alle Antworte dazu finden.

[Gast]

Ok, mit dem Skript hier hat es geklappt! Super! Spitzen-Forum!!! Ich habe es auf meine Situation mit Zigbee Iluminize Controllern (Iluminize 511.050) und 5-Kanal LED Stripes angepasst. Momentan noch im 3-Kanal-RGB-Modus, aber ich denke ich kann auch 5-Kanal-Modus verwenden, oder (werde das modifizierte Skript dann natürlich veröffentlichen, wenn's soweit ist!)? (welchen Loxone Licht-Typ muss ich dann für RGB+CW+WW wählen? Der Typ RGB hat ja nur 3 Kanäle, oder? Auch wenn die GUI in der App dazu eine RGB-Bereich und einen CW/WW-Bereich hat).

Aber was ich nicht verstehe ist, wie das mit den Szenen funktioniert. Ich kann z.B.
URL = /api/j58hs4he894jkdjrjhusghjdfnjkdfngkjnsfdgkd/groups/2/action/ --> PUT {"scene": "t64hi98ope7dhe"}
machen, und in der Tat wird die Szene "t64hi98ope7dhe" dann aktiviert.

Aber wo sind denn die Licht-Spezifikationen der einzelnen Szenen überhaupt hinterlegt???

Mit URL = /api/j58hs4he894jkdjrjhusghjdfnjkdfngkjnsfdgkd/ --> GET

bekomme ich zu der Szene sowas wie:

"scenes": {
"t64hi98ope7dhe": {
"name": "Sonnenuntergang Savanne",
"type": "GroupScene",
"group": "2",
"lights": [
"1",
"2",
"8",
"10"
],
"owner": "94dbf169-f991-41cb-a5b3-16f4208c0d6e",
"recycle": false,
"locked": false,
"appdata": {
"version": 1,
"data": "reUty_r01_d15"
},
"picture": "",
"lastupdated": "2019-06-02T01:19:08",
"version": 2
},

Ok, da steht, dass die Szene sich auf Gruppe 2 bezieht und die Leuchten 1, 2, 8 und 10 betrifft (was ja schon redundante Info ist, da die Angabe der Gruppe ja reichen würde!?!).

Aber nirgends steht in der Szenen-Definition, welche RGB-Werte welche Leuchte in dieser Szene konkret hat. Woher holt sich die Hue-Bridge dann diese Info, und wie mach ich die mit GET sichtbar und kann mit PUT Szenen umdefinieren oder neu definieren?

[svethi]

Wenn Du tiefer in das Thema einsteigen willst, dann solltest Du Dich bei HUE als Entwickler registrieren, dann bekommst Du Zugriff auf die komplette API Doku

Danke Svethi, guter Hinweis, werde ich dann wohl mal machen, mich bei Philips Hue als Developer registrieren. Das ist kostenlos, oder?

[svethi]

Also als ich mich da registriert habe, war das kostenlos

[tottia79]

Hallo, wo finde ich den das aktuelle Script ?? Irgendwie finde ich das nicht .....Danke für eure Hilfe !!!

Im allerersten Post dieses Threads, auf Seite 1 ganz oben. Der Themenersteller hat jenes allererste Post bearbeitet, da sind die letzten Skripte gelistet und zum Download verlinkt.

[Gast]

Hallo Svethi und Andreas L. und alle anderen Beitragenden zu diesem Script!

Ich bin mal in das Skript eingetaucht und nun dabei, es auszuputzen, die Wartbarkeit und Benutzerfreundlichkeit zu erhöhen (Kommentierung, Strukturierung) und den Funktionsumfang zu erweitern. Vieles dazu hab ich schon fertig und es sieht gut aus!

Selbstredend, dass ich danach dieses Skript zum Wohle Aller veröffentlichen werde. Voher muss ich aber noch einige Punkte klären, die ich trotz Lesens des gesamten Threads (32 Seiten) nicht beantwortent kann. Ich stelle die Fragen deshalb hier:

1. Warum werden Dimmfunktion und Szenen-Auswahl mittels "sceneIDforGroup[idx]" miteinder vermischt? Wenn ich den Code richtig verstehe, passiert bei diesem Feature Folgendes:
   Wenn ich eine Lampengruppe dimme, dann passiert bei Dimmwerten [0, 2, 3, 4, 5, ..., 253, 254] stets die übliche Dimmung.
   Wenn jedoch der Dimmwert auf =1 (bzw. DIMMER_MIN) oder =255 (bzw. DIMMER_MAX) steht UND die entspr. sceneIDforGroup[idx] definiert (nicht leer) ist, dann wird die Hue-Szene dieses Namens in der Hue-Bridge aktiviert.
   
   --> Ich frage mich, ob ich dieses Feature aus meiner "ausgeputzten" Version löschen soll, weil ich den Sinn nicht erkenne. Andererseits kam es mit der 2020-er Version des Skripts überhaupt erst frisch rein, jemand muss sich also etwas dabei gedacht haben, ich habe hier im Thread aber nichts dazu gefunden.
   
   Ich kann das Feature nicht nachvollziehen: Wenn ich per GUI dimme und der Min und Max Wert für Szenenauswahl verwendet wird, dann ist das nicht gerae benutzerfreundlich sondern "strange". Hier würden sich doch eher Radio Buttons oder Ähnliches anbieten. Auch ist mir unklar, warum nur EINE Szene so anwählbar ist. Ich meine, wenn man das schon so macht, dann würde es sich doch anbieten, für Dimmwert = 1 und =255 unterschiedliche Scenen zu assoziieren. Oder noch besser, gleich einen ganzen "Block von Dimmwerten", z.B. [1, 2, 3, 4, ..., 9, 10], für die Anwahl von 10 Szenen vorzuhalten, und die eigentliche Dimmfunktion auf den Dimmbereich 11..255 zu beschränken (und die lineare Kennlinie entsprechend anzupassen, so dass ein 90 --> 255 Mapping stattfindet statt das sonst übliche 100-->255 Mapping).
   
   Ich möchte das verstehen, um das Script im Sinne des Erfinders zu verbessern oder zumindest nicht zu verschlechtern.
   ..
2. Was ist der Sinn von DIMMER_MIN = 15? Dies erschließt sich mir in der jetzigen Implementierung in keinster Weise.
   Code reading zeigt: Mit diesem Setting gilt: Ein vom Loxone Dimmer-Ausgang (der ja immer von 0 bis 100 rangiert) gelieferter Wert zwischen 1 und 14 liefert negative Werte zur Hue-Bridge, d.h. man würde negative 'bri' Werte an die Hue-Bridge schicken. Ist doch sinnlos, oder? Man reduziert dadurch lediglich seine Auflösung unnötig, d.h. statt einem Mapping [1..100]-->[1..255] hat man ein Mapping [15..100]-->[1..100], was die ohnehin schon schlechte grob-granulare Loxone-Auflöung der Dimmung noch weiter verschlechtert, ohne dass man etwas gewonnen hat.
   
   (!) Ich könnte mir vorstellen, dass der "Erfinder" etwas anderes im Sinn hatte, nämlich folgendes: Wenn man bei einer Lampe z.B. die oberen 5% und unteren 10% der Helligkeits-Range gar nicht benutzen will, dann heißt das, dass man in Richtung Hue Bridge nur die 'bri'-Werte 13 bis 230 schicken will und auf die "Ränder" verzichten will. Das heißt, man kann die Loxone-Range [0..100] auf die Hue-Range [13..230] mappen. Dies hält den Aussteuerbereich im gewünschten Rahmen und verbessert als Nebeneffekt auch noch die Auflösungsverluste der auf 100 Werte beschränkten Loxone-Range! Ich vermute, so war die Idee, oder?
   
   Wenn nichts dagegen spricht, werde ich das Skript in diesem Sinne umgestalten, so dass dieses Prinzip korrekt und optimal umgesetzt wird.
   ..
3. Farbtemperatur-Ausgang des Lumitech-Farbtempertur-Ausgangs (das "TTTT" im "value=20bbbTTTT"): Verstehe ich es richtig, dass dies IMMER den Range 2700-6500 K hat und dieser Wertebereich in Loxone nicht konfigurierbar ist? (vgl. #322.2 und #419 in diesem Thread)
   
   Falls ja, dann werde ich eine Parametrisierung einführen, die in der Funktion setCtBri() den Wertebereich [2700..6500] durch eine lineare Konvertierungsfunktion auf einen für die konkrete Lampe maßgeschneiderten Ziel-Wertebereich ummappt, so dass per Loxone-GUI der CW/WW-Auswahl auch der gesamte hardwaremäßig unterstützte Wertebereich der Lampe ansteuerbar ist.
   ..
4. Sleep timer: Auf Seite 20 in diesem Thread wurde vielfach berichtet, dass nach einem bestimmten Loxone FW-Update das Skript nicht mehr ging, weil der "stream_close(TcpStream)" in der Funktion "sendCommand" zu schnell kam. Gegenmaßnahme war das Einfügen eines "sleep(150)" dirket davor. Im Gegenzug hat man das "sleep(150)" in der endlos-while-loop ganz unten im Skript auskommentiert/entfernt.
   
   Im aktuellen Skript ist diese Maßnahme aber wieder rückgängig gemacht worden. Ist das Absicht?
   
   Ich meine, das "sleep" in der while-loop hat schon seine Berechtigung, um die Last des Mini-Servers zu begrenzen, und sollte besser bleiben. Soweit gut. Aber warum wurde der andere "sleep" vor "stream_close(TcpStream)" wieder entfernt/auskommentiert? Ist er nun doch nicht mehr notwendig? Gab's ein weiteres Hue-FW-Update, welches das Problem wieder beseitigte?
   ..
5. Es wurde schon mehrfach gefragt, was der Unterschied zw. dem Loxone Lichtbaustein-Ausgangstyp Lumitech und RGB ist. Ich habe Folgendes verstanden - kann das jemand bestätigen/korrigieren? (es wurde im Thread darüber nur spekuliert und nie bestätigt soweit ich gesehen habe)
   • Beide haben das gleiche Loxone-App GUI, d.h. eine RGB-Auswahl im Kreis, eine CW/WW Auswahl im Kreis, und einen Helligkeitsdimmer als Schieberegler.
   • Die CW/WW Auswahl hat im Falle des RGB-Ausgangs-Types aber keinerlei Funktion/Konsequenz.
   • Somit kann jede Lampe, die mit "Lumitech"-Type angesteuert werden kann, auch mit "RGB"-Type angesteuert werden, es fehlt dann halt nur das Feature Kalt/Warm-Weiß.
     ..
6. Stimmt es, dass der Lichtbaustein-Ausgangstyp "Smart Actor" NICHT einen (float) Wert liefert, welcher vom Script empfangen und verarbeitet werden kann, d.h. diese Schnittstelle zum PicoC Skript ist für den Smart Actor nicht verwendbar?! Hat es schonmal jemand probiert? Was, wenn man es probiert? Ist es von "getinputevent()" nicht erfassbar (das könnte man noch work-arounden)? Oder ist der Wert selbst nicht lesbar/immer Null, d.h. "getinput()" versagt?

Wie ihr seht, brenne ich darauf, die Fragen zu klären und dann das verbesserte und runderneuerte Skript fertig zu stellen!

Pkt. 3 - ja - LoxOne kennt nur den Werte Bereich 2700K-6500K, das sich nicht anpassen lässt - d.h. verwendet man andere Lampen mit anderem Wertebereich, muß bzw. sollte diesen Wert entsprechend skalieren.

[svethi]

https://www.loxforum.com/forum/faqs-tutorials-howto-s/7738-phillips-hue-mit-loxone-verwenden?p=228949#post228949

zu 6. hast Du denn schonmal erfolgreich einen Smartaktor an den Programmbaustein angebunden?

zu 6.: Noch nicht, bin noch Anfänger und "Theoretiker" (aber nicht mehr lange!). Aber ich vermute, so wie du schreibst, quittiert das Loxone Config den Versuch einer solchen Anbindung gleich mit einer Fehlermeldung oder lässt die "Verkabelung auf dem Bildschirm" erst gar nicht zu!(?)

[svethi]

Weißt Du was? Du schreibst hier ständig nur von nicht überprüften, nicht stimmenden Thesen und fängst an ein Script über den Haufen zu werfen, was jetzt Jahrelang problemlos läuft. Stellst Dinge in Frage, die im Thread aber bereits beantwortet wurde (was Du angeblich alles gelesen hast). Krabbel doch erstmal ein bißchen bevor Du laufen lernst.
Zur Scenensteuerung: Wenn Du nicht dimmen willst, dann häng doch einfach nur nen Schalter ran. Genau dafür ist der Wert 1 gedacht. Wenn Du die Scene aber auch dimmen willst, dann hängst Du eben einen Dimmer ran und weil Du den Wert 1 mit nem Slider nicht einfach anfahren kannst, der Wert 100. Wenn Dir dazu die Fantasie fehlt, tut es mir leid
sleep: ist auch erklärt. Wenn Du den Code mal richtig lesen würdest bevor Du jetzt alles rausschmeißt, dann hättest Du erkannt, warum dieser nicht mehr nötig ist und nun entfernt wurde.

Nichts liegt mir ferner, als die Arbeit der selbstlosen Helden und Helfer hier madig zu machen. Das genaue Gegenteil ist der Fall! Wenn das anders rüber kam, bitte ich ausdrücklichst um Entschuldigung! Ich wollte nur sachlich-konstruktiv sein. Dass ich beim mehrstündigen Lesen durch die 32 Seiten ein paar Sachen übersehen haben könnte, bitte ich zu entschuldigen. Ich habs wenigstens versucht und mich durch den ganzen langen Thread durchgearbeitet. Z.B. hab ich mind. 2x gesehen, dass jemand nach dem Sinn von "DIMMER_MIN=15" gefragt hat (also bin ich nicht der Einzige), aber eine Antwort dazu habe ich WIRKLICH nicht gefunden, obwohl ich sie gesucht habe - kann mein Fehler gewesen sein (Übermüdung nach dem vielen Lesen?), aber mehr kann ich ehrlich nicht sagen.

Zum "sleep()": Ja, im zweit-neuesten der fünf Scripts ist ein Kommentar, der auf ein Posting auf S. 21 dieses Threads verlinkt, was mir ja schon bekannt war. Da steht Hue-Bridge Gen.2 braucht diesen sleep(). Mein gut gemeinter Vorschlag wäre nun, diesen Hinweis dann unbedingt auch in den nachfolgenden Skript-Versionen zu belassen, WENN er noch weiterhin gültig ist. Da er in der neuesten Version weg ist, nahm ich an, es hat sich an der Faktenlage inzwischen wieder etwas geändert - fand meine Nachfrage darum nicht unangebracht. Ich kann das Gen.2-Problem übrigens nicht bestätigen, habe Hue-Bridge V.2 mit 11 Leuchten und Loxone 10.3, und das auf meine Leuchten angepasste Script "HUE_Vers_2020_01_05-2.txt" tut auch ohne diesen sleep() problemlos. Hängt dann vllt. von der genauen Hue-Bridge HW- oder SW-Revision ab.

Zur Scenen-Steuerung wurde ich wohl missverstanden. Egal. Eine Alternativ-Idee: Einen Formelbaustein z.B. vor den AI10 Programm-Input hängen, mit zwei Formel-Inputs wie folgt: Input AI1=Wert vom Dimmer (0..100), AI2=Impuls (0/1) von Taster ö.ä. Formel AQ = AI1 + 1000*AI2 gibt ohne AI2 Impuls den Dimmerwert AQ=AI1 (0..100) raus, sonst einen Wert AQ>=1000. Das PicoC Skript kann diesen Wert dann z.B. am Programm-Input A10 auf >=1000 abfragen. Wenn ja, schaltet es die im PicoC-Code benannte Szene aktiv. Wenn nein, leitet es den Dimmerwert wie heute an die Hue-Bridge und dimmt diese Scene.

[svethi]

Keiner lehnt hier Verbesserungen und schon gar keine Fehlerbeseitigung ab. Unter konstruktiver Kritik/Diskussion verstehe ich aber etwas anderes. Dazu gehören für mich Tatsachen und keine nicht überprüften, falschen Thesen. Du verstehst z.B. die Scenensteuerung nicht und stellst in den Raum, dass beim dimmen der Gruppe die „Scene“ zerstört wird und hätte wäre wenn. Sieh es Dir doch erstmal an wie es funktioniert und komme dann mit Deiner konstruktiven Kritik.
Zu Deinem Vorschlag ... sicher kann man dies machen und man kann jenes machen. Dein Vorschlag bedingt aber, dass man den Impuls für die Scene triggern muss. Das zeige mir doch mal wie das mit der Lichtsteuerung geht. Da hast Du einen Schieberegler und bräuchtest aber noch einen Button. In der HUE App gehst Du auf die Scene und kannst dort dann auch gleich dimmen. So wollte es nunmal der Nutzer haben. Was man alles anders machen könnte interessiert dann aber gar nicht.

Zum sleep. Es wurde noch nie ein sleep benötigt. Das sleep war nur eine quick&dirty Lösung für die Probleme mit der Gen2. Das Problem bei vielen Geräten ist, dass diese auf einen Anfrage Änderung auch eine Antwort senden. Im besagt Fall wurde die Verbindung aber getrennt, bevor die Gegenstelle die Anwort loswerden konnte. Viele Geräte reagieren da allergisch drauf. Die Lösung war das sleep. Das sleep kann aber zu lang, oder aber auch zu kurz sein, daher habe ich das dahin gehen geändert, dass nun die Antwort von der Gegenstelle eingelesen wird. So macht man das richtig und so bedarf es auch keines sleeps mehr

[svethi]

Mit dimmer-min und den Minuswerten habe ich auch schon gemerkt. Halte mich aber in dieser Beziehung immer zurück. Das Script hat Einflüsse von verschiedenen Programmierern. Jeder programmiert etwas anders und versteht den Code etwas anders. Wenn Du jetzt alles umschreibst, versteht es vielleicht der Entwickler nicht mehr. Daher halte ich mich auch da zurück. Soll aber nicht heißen das es nicht besser geht. Von daher bin ich mal gespannt auf das Ergebnis

[deepinpowder]

Netter Ton hier. Ist mir neu.

Zur Info. Es gibt ein neues Sicherheitsupdate:

Hier der Link


Manche haben ihre Hue ja nicht auf AutoUpdate.

[svethi]

Wusste ich noch nicht. Danke.