Phillips HUE mit Loxone verwenden

[KeLa]

Tja dann wird es sportlich wenn der MS V1 raus ist. Dann wird es aber daraus hinaus laufen, dass Loxone bei mir auch raus ist. Sehe es nicht ein mir einen MS V2 zu kaufen und die KNX Extension nur um meine Buderus KNX10 Integration und HUEs weiter betreiben zu können. Für MS V2 + KNX Extension werden mal locker 1.000€ fällig und ob die KNX Extension ein vollwertiges KNX ist mit allen KNX DPTs ist bis dato auch noch fraglich. Weil knapp 500€ für eine KNX Extension welche nicht einmal alle DPTs unterstützt ist schon frech.

Andere Frage wäre ob man die HUE API V2 umgehen kann wenn man auf die ganzen Updates der HUE Bridge verzichtet.

[svethi]

Ich rege mich nicht auf, daher der lachende Smiley. Keine Ahnung warum jeder gleich immer denkt, dass ich mich aufrege. Ich rede nur nie um den heißen Brei und sage direkt heraus was ich meine ;-)
Die Rückmeldungen sind bei HUE ein bekanntes Problem und auch ich habe mich schon länger damit beschäftigt. Wenn es nur um eine Helligkeit geht, kann man das mit dem besagten Delay ja auch machen, doch das Script rechnet ja auch viel mit den Farben rum und dafür ist es ja gemacht da die Farben halt ein Problem sind, wie Du ja auch am Beispiel KNX siehst. Und dann haben auch noch alle Lampen einen anderen Farbraum. Das größte Problem ist, dass man die Farben NICHT 1:1 hinundher rechnen kann. Daher geht eine Rückmeldung der Farbe in die Hose. Du schickst da eine Farbe, errechnet aus Deinem RGB, hin und erhältst als Status aber nie genau diese Farbe zurück. In so einer Schaltung wie oben führt das zum absoluten Chaos. Aus diesem Grund gibts dieses Rückmeldung nicht im Script. Ich habe mir das hier zusammengebastelt und auf Knopfdruck die Farbe auszulesen und dann in Loxone speichern zu können. Halt nur manuell. Das geht. Ich hoffe ja auch, dass die API in dieser Hinsicht besser aufgestellt sein wird. Oder man muss in Loxone einen anderen Weg gehen, da dort teilweise auch versteckt der HUE Farbkreis verwendet wird. Dieser Wert wäre für HUE sicher besser geeignet.

[svethi]

Nein, die aktuelle API schickt keine Events raus.
Wie Ben_Mann schon schreibt, soll die neue APIv2 das unterstützen. Diese API ist noch nicht fertig, kann aber wohl schon getestet werden. Bin aber noch nicht dazugekommen.
Das Problem bei der ganzen Sache ist, dass die neue API und später auch die APIv1 (bis die sicher irgndwann ganz verschwindet) gänzlich auf ssl umgestellt werden. Damit ist dann ohne Hilfsmittel zumindest der MSv1 raus.

[Ben_Mann]

Es ist vor kurzem die Hue API V2 rausgekommen. Die V2 unterstützt jetzt das push von Zuständen. Wie man das aber mit Loxone nutzen kann ist mir noch nicht klar.

https://www.smarthomeassistent.de/neue-philips-hue-api-arbeitet-per-push-schnellere-kommunikation/amp/

[KeLa]

500ms wäre etwas arg übertrieben. Schickt HUE den Status raus oder muss man den wirklich abfragen? Steht ggf etwas in der Entwickler API zu diesem Thema?
Die Abfrage nutze ich eigentlich nur bei HUE Lampen wo ein Zwischenstecker oder eine Nano IO dazwischen hängt. Hält sich somit in Grenzen.

[KeLa]

😂 Klasse. Zuerst die Programmierung Anderer als veraltet und für Deinen Zweck nicht brauchbar deklarieren und dann die eigene Version, die unübersichtlich ist und zudem nur einen winzigen Bruchteil kann vorstellen und fragen was man davon hält ;-).
Nichts! Weil Dein Ansatz erstens zu unvorhersehbaren Rückkoppelungen führen kann und 2. keine Farben, Farbtemperatur und verschiedene Lampentypen unterstützt

Nicht aufregen! Vielen Dank für Deine Bemühungen das Skript weiter zu verbessern. Ich nutze aktuell das Skript von 2020. Läuft soweit ganz gut.

Ich hatte mir das ISE HUE KNX GW gegönnt. Dieses aber nach 3 Tagen wieder ausgebaut und zurück geschickt. Mag sein, dass es User gibt die mit dem Teil zufrieden sind, ich war es jedenfalls nicht. Zum einen weil Loxone nicht alle KNX DP-Typen unterstützt, dann war die Farbkonvertierung ehr mangelhaft, die Szenen-Ansteuerung eine Katastrophe und verdammt viel Logik notwendig um aus den RGB Farbwert (DP-Typ 232.600) einzeln in R, G und B (jeweils DP-Typ 5) aufzulösen.
Für die Szenen Auslösung ist DPT 18.001 erforderlich. Mit etwas gefrickel konnte man den auch abändern so das es funktionierte. Sollte nun Szene "ABC" blinken, konnte man dies in der WEB-GUI des ISE HUE KNX so hinterlegen. Allerdings blinkte die Szene dann mit geschätzten 20% Helligkeitswert für AUS und 100% für EIN. Also es flackerte mehr. Sollten die Lampe "xyz" blinken (konnte man separat auslösen), hat die zwar schön geblinkt (0% AUS und 100% AN) aber nach 15sek hörte die einfach auf zu blinken. Die 15sek sind so in dem ISE HUE KNX hinterlegt und können nicht abgeändert werden. Lediglich in der Szenensteuerung konnten die Zeitwerte fürs Blinken geändert werden. Wie oben bereits erwähnt war das aber ehr ein flackern und kein blinken.
Einzigste Vorteil war die halbwegs flotte Rückmeldung (<2sek) der Zustände.

Für meine Ansprüche ist das Pico C Skript vollkommen ausreichend und ist mittlerweile gefühlt sogar schneller als die KNX Lösung. Anpassungen können schneller vorgenommen werden und der Farbkreis von Loxone ist inzwischen fast deckungsgleich mit dem von HUE. Die Farbkonvertierung bei der KNX Variante konnte man nicht korrigieren und wich erheblich von dem HUE Farbkreis ab.
Also warum 300-400€ für das HUE KNX ausgeben wenn dies weniger kann als das kostenlose Skript?

[svethi]

Das ist das Problem. So lange Du nicht aktiv bei Änderung den neuen Status mitgeteilt bekommst, sondern abfragen musst, musst Du auch mit einem Delay leben. Geht leider nicht anders. Und wenn ich das richtig lese, würdest Du sonst auch die Abfragewiederholung niedriger setzen. Auf was denn? 500ms? Und damit dann den MS und Dein Netzwerk lahmlegen?

[KeLa]

Hallo zusammen,
leider fehlt bei mir immer die Zeit mich mit dem Thema tiefer zu befassen und mal in die Diskussion einzusteigen. Jedoch möchte ich trotzdem mal meinen Ansatz vorstellen. Ausgangspunkt war das Problem, dass ich auf der einen Seite meine Lichtsteuerung über die normalen Lichtschalter, zusätzlich aber auch über die Hue App steuern wollte. Das Problem dabei ist, dass dadurch der aktuelle Zustand in der Loxone App nicht mehr passt. Deshalb kam für mich dieses PICCO Programm nicht in Frage. Ich finde das ganze auch ziemlich veraltet.
Deshalb läuft das bei mir alles über Virtuelle http Eingänge/Ausgänge. Dabei frage ich erstmal die Liste aller Lampen von der Hue Bridge ab und nutze dann die Befehlserkennung um den Status und die Helligkeit der einzelnen Lampen zu erhalten. Beispiel Status \i"37":\i\i"all_on":\i\1 die 37 ist die Nummer der Lampe in der Hue ( entsprechend die Helligkeit \i"37":\i\i"bri":\i\v) . Bisher habe ich da für jede Lampe 2 Einträge zum Lesen der Werte. Ich kann mir vorstellen, dass das sicher auch besser geht. Vielleicht ein Picco Programm?
Diese beiden Werte übergebe ich dann an einen Status Baustein und Schalte entsprechend einen Dimmer Baustein. Anschließend nutze ich wieder einen Status Baustein um einen neuen Wert an die Hue Bridge zu senden. Dieser Wert wird dann über einen Virtuellen Ausgang wieder gesendet.
Wie schon gesagt, fehlt mir die Zeit um das Ganze zu optimieren. Jedoch läuft es jetzt schon über ein Jahr sehr stabil.
Was denkt ihr dazu?
Viele Grüße
Ben

Hallo,

ich ergänze die Sache hier mal etwas. Danke Ben_Mann für die Vorarbeit.

Status einzelner Lampen abfragen

virt. HTTP Eingang mit der Url:
http:/IP der HUE Bridge/api/API aus dem Skript/lights/

virt. HTTP Eingang Befehl mit der Befehlserkennung:
\i"Nummer der Lampe":\i\i"on":\i\1 Beispiel: \i"17":\i\i"on":\i\1 - Liest den Zustand der Lampe aus (AN oder AUS)
\i"Nummer der Lampe":\i\i"bri":\i\v Beispiel: \i"17":\i\i"bri":\i\v - Liest den Helligkeits- / Dimmwert der Lampe aus

Korrekturwerte für den Zustand der Lampe
Eingangswert 1 - 102
Zielwert 1 - 0 (Lampe Aus)
Eingangswert 2 - 116
Zielwert 2 - 1 (Lampe An)

Korrekturwerte für den Helligkeitswert der Lampe
Eingangswert 1 - 0
Zielwert 1 - 0 (Dimmstufe 0%)
Eingangswert 2 - 254
Zielwert 2 - 100 (Dimmstufe 100%)
Einheit <v>% (Rundet somit auf ganze Zahlen)

Status von Gruppen abfragen

virt. HTTP Eingang mit der Url:
http:/IP der HUE Bridge/api/API aus dem Skript/groups/

virt. HTTP Eingang Befehl mit der Befehlserkennung:
\i"Nummer der Gruppe":\i\i"all_on":\i\1 Beispiel: \i"7":\i\i"all_on":\i\1 - Liest den Zustand der Gruppe aus (AN oder AUS)
\i"Nummer der Gruppe":\i\i"any_on":\i\v Beispiel: \i"7":\i\i"any_on":\i\v - Zeigt an ob irgend eine Lampe der Gruppe an/aus ist

Es gibt sicherlich noch mehr Möglichkeiten zum Auslesen von den Parametern. Einfach mal die URL mit IP + API (die aus dem HTTP Eingang) in den Browser eingeben. Die ausgegebenen Daten sind eigentlich selbst erklärend. Bei der Befehlserkennung können dann die Parameter "all_on" bzw "bri" durch die gewünschten Parameter ersetzt werden.

Integration von Amazon Alexa

Durch das Auslesen des Status der Lampe könnte man nun auch Alexa integrieren. Ich habe eine HUE Beleuchtungsgruppe über der Essecke hängen. Diese wird mittels Loxone Touch und Nanio IO geschalten / gedimmt.


Oben Links lese ich den Zustand der Beleuchtung aus. Einmal einer einzelnen Lampe und zusätzlich der Gruppe. Dies liegt aber daran, dass ich bei Alexa einmal nur eine Lampe "Bastellicht" hinterlegt habe und einmal die Gruppe "Essecke". Sicherlich könnte ich auch über die Befehlskennung der Gruppe "any_on" abfragen. Die Rückmeldung läuft dann über die Flankenerkennung und schaltet mir die Szene (via T5/x) ein bzw über R aus. Dies wirkt sich auf den Ausgang AQ4 aus welcher die Nano IO ein bzw aus schaltet.

Aktuell gibt es nur ein Problem. Dies ist die Verzögerung bei der HTTP Abfrage der Zustände. Als minimaler Wert kann hier nur 10sek gewählt werden. AUS geht sofort wobei AQ4 max 10 sek später erst AUS geschalten wird. Bei EIN dauert es bis zu 10sek. Wenn hier noch jemand eine Idee hat wie man dies schneller lösen kann nur her mit den Vorschlägen.

Gruß
Lars

[Ben_Mann]

Sagen wir es mal so, der Picco Baustein konnte nicht das was ich wollte, war also für mich unbrauchbar. Die Beschreibung meines Ansatzes ist soweit vollständig beschrieben, aber wie du ja schon angemerkt hast, kann ich damit noch nicht alles was der PICCO Baustein kann, das liegt aber nicht daran, dass es nicht gehen würde, sondern dass ich bisher noch keine Zeit gefunden habe mich damit zu beschäftigen und andere Funktionen einzubauen. Meine Lösung tut was sie soll (An/Aus und Dimmer) funktioniert soweit. Mit Rückkopplungen habe ich bisher noch keine Probleme gehabt, was nicht heißt das man damit Probleme haben könnte.

[svethi]

😂 Klasse. Zuerst die Programmierung Anderer als veraltet und für Deinen Zweck nicht brauchbar deklarieren und dann die eigene Version, die unübersichtlich ist und zudem nur einen winzigen Bruchteil kann vorstellen und fragen was man davon hält ;-).
Nichts! Weil Dein Ansatz erstens zu unvorhersehbaren Rückkoppelungen führen kann und 2. keine Farben, Farbtemperatur und verschiedene Lampentypen unterstützt

[Ben_Mann]

Hallo zusammen,
leider fehlt bei mir immer die Zeit mich mit dem Thema tiefer zu befassen und mal in die Diskussion einzusteigen. Jedoch möchte ich trotzdem mal meinen Ansatz vorstellen. Ausgangspunkt war das Problem, dass ich auf der einen Seite meine Lichtsteuerung über die normalen Lichtschalter, zusätzlich aber auch über die Hue App steuern wollte. Das Problem dabei ist, dass dadurch der aktuelle Zustand in der Loxone App nicht mehr passt. Deshalb kam für mich dieses PICCO Programm nicht in Frage. Ich finde das ganze auch ziemlich veraltet.
Deshalb läuft das bei mir alles über Virtuelle http Eingänge/Ausgänge. Dabei frage ich erstmal die Liste aller Lampen von der Hue Bridge ab und nutze dann die Befehlserkennung um den Status und die Helligkeit der einzelnen Lampen zu erhalten. Beispiel Status \i"37":\i\i"all_on":\i\1 die 37 ist die Nummer der Lampe in der Hue ( entsprechend die Helligkeit \i"37":\i\i"bri":\i\v) . Bisher habe ich da für jede Lampe 2 Einträge zum Lesen der Werte. Ich kann mir vorstellen, dass das sicher auch besser geht. Vielleicht ein Picco Programm?
Diese beiden Werte übergebe ich dann an einen Status Baustein und Schalte entsprechend einen Dimmer Baustein. Anschließend nutze ich wieder einen Status Baustein um einen neuen Wert an die Hue Bridge zu senden. Dieser Wert wird dann über einen Virtuellen Ausgang wieder gesendet.
Wie schon gesagt, fehlt mir die Zeit um das Ganze zu optimieren. Jedoch läuft es jetzt schon über ein Jahr sehr stabil.
Was denkt ihr dazu?
Viele Grüße
Ben

Hello guys,

I don't understand german, so I'll write in english, I hope someone is able to reply.
Thanks for the script to everyone involved in the development.

Everything works fine for me, but I have one problem:

I use push-buttons connected to the miniserver for turning the hue lights ON/OFF through the script, but for controlling scenes I use the hue app on a dedicated android tablet.
The problem is that if the lights are turned ON/OFF through the app, then the next press of the push button doesn't trigger the lights, since the script is not aware of the change that happened through the app.
Is someone able to help me write a program block that would check the status of the lights, and return a 1 if any hue light in a group is ON?
The status can be accessed through the API: https://<bridge IP>/api/<user ID>/groups/1/ where the status parameter "any_on" returns "true" if any of the lights in the group is ON.
I have little programming knowledge and would really appreciate some help.
Thanks!

Vielen Dank.

[svethi]

So ist es.

Hallo,

verstehe ich es es richtig, die Zahl nach dem Gleich ist also die ID der Lampe auf der Hue Bridge?
D.h. wenn ich in meinem Fall die übernächste Lampe, die dann in der Hue Bridge die ID13 bekommen wird am Baustein auf den aktuell noch freien Anschluß AI1 legen will muß das im Script so aussehen:

inputType[0] = 0;
und
lightOrGroupID[0] = 13;

Gruß,
Martaeng