FabianVor rund zwei Jahren hat Philips Hue ein neues API eingeführt. API steht für Application Programming Interface und ist eine Schnittstelle, über die Apps Befehle an die Hue Bridge senden können, um bestimmte Aktionen auszuführen. In der Entwicklung ist man hier aber noch stark eingeschränkt, wie mir Stefan Göhler, der Entwickler von iConnectHue im Gespräch mitgeteilt hat.
Grundsätzlich haben Entwickler von Drittanbieter-Apps, dazu zählen ja beispielsweise auch Hue Essentials oder All 4 Hue, Zugriff auf die neue Schnittstelle. Anders wäre eine Steuerung von neuen Produkten, wie etwa den Gradient-Leuchtmitteln, für sie gar nicht möglich.
Skripte sind von Philips Hue noch nicht ausreichend dokumentiert
Mit dem Philips Hue Kontaktsensor ist nun erstmals seit der Einführung der neuen API-Schnittstelle ein neuer Sensor erschienen. Bisher kamen beim Zubehör sogenannte Regeln zum Einsatz, die sehr flexibel programmiert werden konnten. Mit der neuen Schnittstelle setzt Philips Hue dagegen auf Skripte – und hier beginnen die Probleme für Drittanbieter.
Aktuell ist es für Personen wie Stefan Göhler nämlich noch nicht möglich, eigene Skripte zu bauen. Es können nur vorhandene Skripte genutzt werden, die zudem aber auch noch nicht dokumentiert sind. Das bedeutet auch: Beim neuen Kontaktsensor können Drittanbieter-Apps nur die Funktionen anbieten, die bereits von Philips Hue als Skript erstellt wurden.
Es würde so viele Möglichkeiten geben
Und dabei könnte alles so schön sein. Hätten Entwickler Zugriff auf das Skripting bzw. die Behavior-API von Philips Hue, dann könnten sie die Fähigkeiten des Hue-Systems massiv ausbauen.
So wäre es beispielsweise möglich, mit einem Schalter auf der ersten Bridge einen Skript auslösen, der Lampen der zweiten Bridge steuert. Selbst Aktionen außerhalb des Hue-Systems, wie beispielsweise die Steuerung eines Sonos-Lautsprechers, könnten so realisiert werden.
Bisher gibt es keine Anzeichen dafür, als würde sich an der jetzigen Situation zeitnah etwas ändern. Insbesondere für Nutzerinnen und Nutzer, die sich intensiver mit dem System befassen, gehen so spannende Optionen verloren.
- Smart Home Controller: Die Hue Bridge verbindet bis zu 50 LED Lampen und Zubehör zu einem Netzwerk und ermöglicht die variable und weltweite...
- Einzigartige Funktionen: TV Hintergrundbeleuchtung mit Surround-Licht, zu Hause von warmem Licht begrüßt werden und mehr – mit der Hue Bridge...
Hach ja, das tolle API2… Auf dem Papier sieht es ziemlich gut aus und auch das Streichen der HSV-Farben finde ich ok weil man mit xy konsistentere Farben bekommt – wenn man es korrekt umrechnet, die Formeln auf den Hue-Entwicklerseiten sind falsch (verwenden sRGB-Gamut). Aber auf der anderen Seite sind da noch soooo viele Baustellen, die Signify trotz Klagen im Entwicklerforum ignoriert, z.B.:
– Der Eventstream meldet für jedes Gerät und Datenpunkt nur ein Event pro Sekunde. Bei Lampen ist das ja noch ok, aber bei Tastern bekommt man so bei Mehrfachklicks nur den ersten und muss dann nochmal manuell pollen um die Klickanzahl zu erfahren.
– Die API2 hat ein Ratelimit von ca. 10 Requests pro Sekunde, bei API1 war es höher. Wenn man eine Hue-Anbindung für ein anderes Smart Home-System baut, welches eigene Szenen und Gruppen hat muss man lustige Workarounds basteln damit Schaltvorgänge auf diesen auch komplett auf die Brücke geschoben werden oder diese Szenen/Gruppen auf die Bridge spiegeln und synchron halten.
– Nicht alle API1-Funktionen sind über API2 möglich, zB steht in der API2-Doku zwar schon lange drin wie man ein Licht umbenennt, aber die Bridge lehnt es mit „der Wert ist read-only“-Fehler ab. Vor über einem Jahr wurde das schonmal im Developer-Forum angemerkt, offizielle Antwort war „die Doku ist im Augenblick noch etwas Wunschdenken, wir arbeiten daran“. Passiert ist da scheinbar immer noch nichts.
– Die API ist so spezifiziert, dass sie nicht so leicht von Hue-Bridge-Emulationen wie zB deconz nachgebaut werden kann. Sie ist offiziell nur per https ansprechbar und man soll prüfen, ob das verwendete Zertifikat von einer bestimmten Signify-CA signiert wurde, was Emulationen natürlich nicht hinbekommen. Die Erkennung, ob API2 unterstützt wird läuft über ein Versionsnummernfeld im API1, welches meiner Erfahrung nach bei Emulationen komplett andere Formate verwendet.
– Ich habe länger nicht mehr verglichen, aber ich meine auf der gleichen Bridge im API1 mehr Gruppen zu sehen als im API2, die Daten sind also nicht komplett konsistent.
– Im API1 melden Gruppen „Mittelwerte“ für Helligkeit und Farbe, bei API2 fehlen diese Werte. Man kann sich natürlich aus den zuletzt gemeldeten Werten selbst etwas ausrechnen falls man den Wert im UI anzeigen möchte, aber bisher habe ich keinen Rechenweg gefunden, der das gleiche Ergebnis wie API1 liefert.
Danke für die Infos, so in etwa habe ich mir das auch vorgestellt. Dieses „Developer-Forum“ muss ich mir mal ansehen!
Inzwischen lassen sich mit API 1.60 Lampen umbenennen, und das ist auch empfehlenswert, da es einen Bug gibt, der die Namensänderung von V1 nicht auf V2 überträgt. Lampen müssen im Device-Part umbenannt werden. Möglicherweise wurde der Bug in 1.60 behoben – jedenfalls haben wir ihn gemeldet.
Falls das nicht klar ist: Traditionelle Gruppen (die, die es überhaupt zuerst gab) werden im V2-API überhaupt nicht angezeigt, nur Räume und Zonen.
Für uns fühlt sich das neue API an, als hänge alles an einem Faden, die Struktur ist unübersichtlich für die Arbeit damit. Das API wirkt auch overengineered.
Was wir uns aber wirklich wünschen, ist Zugriff auf das Skripting. Wir könnten schon jetzt soviel mehr für alle Hue-Nutzer anbieten, als jetzt aktuell möglich ist. Mit dem neuen Kontaktsensor können wir leider die ganze Vielfalt von iConnectHue voraussichtlich erst einmal nicht mehr anbieten – obwohl wir Signify schon seit knapp 2 Jahren von der Wichtigkeit des Skripting-Zugriffs zu überzeugen versuchen – das Problem ist also keineswegs unerwartet oder neu.
Sehr interessant!
Leider ein weiterer Beweis für den Niedergang von Hue, es könnte so schön sein aber man macht es einfach nicht, in so vieler Hinsicht!
Als Hue Essentials-Nutzer habe zB die Bewegungsmelder nie dazu bekommen einfach zu tun was ich will, dieses API-Chaos ist mit Sicherheit der Grund!
Wenn es schon an so grundlegendem wie einer vorhandenen Dokumentation scheitert – und das wohl Seit JAHREN – dann fühle ich mich nur darin bestätigt mir keine weiteren Hue-Produkte mehr zu kaufen, denn es wird ja fast alles nur immer schlechter, eingeschränkter, teurer und unsicherer.
Kein Wunder das es keine nennenswerte Community gibt, wer will sich schon mit undokumentierter, verrammelter Software rumärgern?
Schade!
Werde mir demnächst mal Home Assistent anschaffen und schauen, was damit für mich geht.
Bisher bin ich allein mit mehreren Bridges und vor allem Dritt Anbieter Apps wie iConnectHue unterwegs – das hat für meine Ansprüche bislang auch genügt. Jetzt bin ich aber deutlich über den Punkt hinaus, dass meine Umgebung größer ist, als die Bridges abkönnen. Zugleich steuere ich viel raumübergreifend, so dass ein Schalter beziehungsweise Sensor in anderen Räumen auch etwas auslöst. Jetzt stoße ich ständig auf das Problem, dass ich Lampen, Schalter und Sensoren nicht auf der gleichen Bridge habe, wie ich es für ein Szenario benötige. (Beispiele: Licht basierte Alarmanlage durch auslösen einer beziehungsweise mehrerer Innenraumsensoren; Einschalten der Außenbeleuchtung bei Schalter beziehungsweise Sensoren Aktivität im Innenraum – führt letztlich dazu, dass ich fast alles auf einer Bridge laufen lassen müsste, was aber eben inzwischen zu groß ist und von Phillips her nicht geht.)
Das ziemlich knappe Limit der Bridges hat der Raspberry Pi von Home Assistent ja nicht.
Allerdings habe ich den Eindruck, dass Home Assistent nicht alles kann, was im reinen Hue-Universum mit Drittanbieter Apps bisher funktioniert. Hat da schon jemand Erfahrungen? (Der Kniff der Anbindung über Apple HomeKit ist mir bekannt.)
Ich glaube, dass das für mich inzwischen aber trotzdem der richtige Weg ist, da ich den Eindruck habe, dass der damals große Vorsprung von Hue in der Lichtqualität der Leuchtmittel inzwischen obsolet geworden ist. Da dürfte man sogar mit Homeassistent inzwischen viel Geld sparen können, da man ja die Komponenten querbeet über die Hersteller viel besser zusammenfügen kann.
Mein Lieblingsbeispiel: wenn das Licht auf Rot gestellt wird, dann heizt du den Raum mit der Smart Heizung automatisch maximal hoch 😂
Last but not least umgeht man so sogar den leidigen Accountzwang von Hue. Das wäre für mich nicht Entscheidung relevant, ist aber ein netter Nebeneffekt.
Ja verstehe nicht warum man bei Hue bleibt wenn man mehr machen möchte als der Hersteller anbietet. Home assistant mit ZigBee Stick bietet unendlich viele Möglichkeiten der Konfiguration. Mittlerweile alles über die GUI.