Test Adapter hueemu (Hue Emulator) v0.0.x
-
@Neopholus
Hi. Überall wo discovery dran steht ist das was der Adapter via SSDP (Simple Service Discovery Protocol) zurück gibt. Anders ausgedrückt: Über diese Protokoll können andere Programme die simulierte Hue Bridge finden. In der Nachricht die dabei ausgetauscht wird würde dann genau dieser Host und Port stehen.Mein Konfigurationsbeispiel:
host: 0.0.0.0 => Adapter hört auf jedem Interface
port: 8070 => Adapter hört auf Port 8070
discoveryHost: 192.168.178.39 => Alexa findet Hue Bridge unter dieser Adresse
discoveryPort: 80 => Alexa findet Hue Bridge unter diesem PortBei meinem Setup habe ich noch einen nginx auf dem RaspberyPi, welcher diese Weiterleitung übernimmt. Port 80 ist ein wenig besonders was die Berechtigung angeht. So kann der Adapter so tun als würde er auf port 80 hören, obwohl er es nicht tut. Bei mir war Port 80 nötig wegen Alexa.
httpsPort: 8071 => Ist wie du sagst optional. Einfach leer lassen.
mac => Ja genau. Nimm die von deinem Netzwerkinterface. Theoretisch kann dort auch irgend ein "Blödsinn" stehen aber ich dachte ich lasse es konfigurierbar.Schau am besten auf die GitHub Seite. Dort kannst du dann sehen wie du Lichter erstellst und wie du das Pairing aktivierst. Ich habe es jetzt noch nicht mit Harmony probiert. Aber in der Theorie:
- In der Harmony App nach Hue Bridge suchen
- Im Adapter auf startPairing klicken
- warten und hoffen das es klappt.
Falls das nicht klappt, kannst du probieren den Loglevel vom Adapter auf debug oder silly zu stellen und schauen, ob du was findest. Falls nicht, kannst du mir die Logs auch gerne via Mail schicken. Auf Github findest du meine Email.
Ich hoffe das hilft weiter.
-
@holomekc
Vielen Dank, das hat mich in die richtige Richtung geschubst.
In der Konfiguration des Adapters ist leider nicht angegeben, welche Daten für was gelten.Meine Konfiguration, falls jemand auch seine Harmony Elite mit diesem Hue Emulator verbinden will:
- Ip-Adresse, unter der der Server gestartet wird: 0.0.0.0
- Port, auf dem der Server lauscht: 8070
- Ip-Adresse, unter der der Server gefunden wird: <IP-Adresse von ioBroker>
- Port, unter dem der Server gefunden wird: 8070
- Port für https: 8071
- Mac-Adresse: <MAC-Adresse, die zur IP-Adresse oben von ioBrober passt>
Dann war's einfach: Eine Lampe testweise anlegen, Adapter starten, In Harmony Hub eine Hue Bridge suchen, im Adapter auf StartPairing klicken und... klappt. Der Status in ioBroker lässt sich damit auch steuern.
Passt also, super!
Nun eine Frage:
- Um nun wirklich einen Effekt in ioBroker zu erzielen, muss ich auf Statusänderung der Lampe triggern und dann einen echten Homematic-IP-Schalter schalten. Korrekt?
- Oder gibt es eine Möglichkeit, direkt einen Status in ioBroker einer "Hue-Emu-Lampe" zuzuweisen?
Vielen Dank und viele Grüße
Stefan -
@holomekc
Ach ja, noch ein Hinweis: Ich habe eine einfache On/Off-Lampe angelegt, wie im Template beschrieben. In der Harmony wird dann eine schaltbare Steckdose angezeigt. Ist für mich nicht relevant, da ich einfach nur etwas schalten können will. Vermutlich liegt es aber an dem
"modelid": "Plug 01"
in dem Template. -
@Neopholus
Hi. Super das es funktioniert. Ich schaue mal das ich die Beschreibung im Konfigurationsmenü verbessere.Zu deinen Fragen:
Soweit ich weiß kannst du nicht direkt einen Status auf den anderen mappen. Dafür kannst du aber mittels Skripte Adapter auf einen Wert lauschen und dann den anderen Wert setzen:
on({id: '...', change: "any"},
function(obj) {
//ack
setState('...', obj.state.val, true).val;
});Ich denke so wäre das dann. Alternativ gibt es auch noch weitere Adapter die da helfen können
Ich habe bisher nicht versucht im Adapter direkt auf andere Objekte zu verweisen. Ich wollte versuchen den Adapter relativ allgemein/einfach zu halten.
Zu dem Plug 01:
Ok interessant. Alexa erkennt es als Lampe, obwohl ich in dem Fall lieber einen Schalter gehabt hätte. Am Sprachkommand hat es bei mir jedoch keinen Unterschied gemacht.Ich habe tatsächlich keine einzige "einfache" Lampe hier, so dass ich die Werte nicht ausgelesen bekommen habe. Ich kann auch mal schauen, das ich noch mehr Beispiele finde. Jedoch können die Werte je nach belieben ausgetauscht werden.
-
@holomekc
Hallo,danke für die weiteren Hinweise. Ich werde mit JavaScript was erstellen, allerdings dann in beide Richtungen. Wenn man ein Licht z.B. über den Schalter einschaltet, sollte man es ja auch in der Harmony sehen. Ich poste was, wenn ich fertig bin.
Bis dahin für alle, die IOT-Geräte auch in ein eigenes VLAN verbannt haben: Wenn man die Harmony temporär in das ioBroker-VLAN umzieht, dann kann man die beiden Geräte pairen. Dabei speichert die Harmony die IP-Adresse. Danach kann man die Harmony wieder ins IOT-VLAN umziehen und trotzdem funktioniert der Zugriff zwischen IOBroker und Harmony danach korrekt. Man muss nur an der Firewall dir korrekten Ports zwischen den Geräten aufmachen.
IOBroker -> Harmony: 8088 (TCP) und 5224 (UDP)
Harmony -> IOBroker: 8070 (TCP; Achtung: Hier muss der Port aus der Adapter-Konfiguration stehen!), 61991 (TCP)Viele Grüße
Stefan -
@holomekc
So bekommt man eine einfache An/Aus-Lampe in Harmony:{ "1": { "state": { "on": false, "reachable": true, "mode": "homeautomation" }, "type": "On/Off light", "modelid": "On/Off light iobroker", "uniqueid": "00:00:01", "manufacturername": "iobroker", "swversion": "V1", "name": "WZ.Licht" } }Achtung: In der Version 0.0.1 hatte der Adapter einen Fehler, der dazu führte, dass die Harmony manchmal keine Statusupdates erhalten hat, kurzzeitig Verbindungsprobleme angezeigt hat und teilweise sehr langsam reagiert hat. In 0.0.2 soll der Fehler behoben sein.
-
Und so kann man die Werte der emulierten Hue-Lampen mit z.B. Homematic IP Geräten in beide Richtungen synchronierieren:
/** * Status setzen, falls Wert bisher anders */ function statusSetzenFallsAnders(id:string, status:boolean) { if (getState(id).val != status) setState(id, status); } /** * Ein-/Ausschalten von WZ.Licht */ on ({id: "hueemu.0.1.state.on", change: "ne"}, function(obj){ statusSetzenFallsAnders('hm-rpc.1.0008556XXXXXXE.4.STATE', obj.newState.val); } ); on ({id: 'hm-rpc.1.0008556XXXXXXE.4.STATE', change: "ne"}, function(obj){ statusSetzenFallsAnders("hueemu.0.1.state.on", obj.newState.val); } ); -
@holomekc
Soweit funktionieren jetzt die Hausautomatisierungstasten an meiner Harmony und eine Liste aller Lampen ist auch am Geräte-Display angezeigt.Was mit aufgefallen ist:
- Manchmal dauert das Schalten über die Harmony relativ lange. Konnte noch nicht herausfinden, woran das liegt. Schaue ich mir noch an, könnte aber an der Harmony liegen.
- Häufig passiert folgendes, wenn man ein Gerät schaltet (über die Tasten oder im Menu ist egal, man sieht die Fehlermeldungen aber nur im Geräte-Menu):
- Klicken auf "Lampe ein"
- Lampe geht ein
- Der angezeigte Status der Lampe auf der Harmony ändert sich sofort (hier hat die Harmony noch kein Feedback von Hue Emu erhalten, ich vermute, er nimmt einfach an, dass der Schaltbefehl erfolgreich war)
- Neben der Lampe wird nach ein paar Sekunden ein rotes "!" angezeigt und darunter die Fehlermeldung "Keine Verbindung"
- Nach weiteren wenigen Sekunden ist die Meldung wieder verschwunden.
Ich habe das Log-Level zwar auf silly hochgestellt, aber so ganz klar ist mir das Verhalten nicht. Eine Vermutung:
- Die Harmony frägt alle ca. 10 Sekunden den Status der Lampen ab
- Klickt man auf eine Lampe, sendet de Harmony einen Befehl an den Hue Emulator
- Hue Emulator schaltet die Lampe, sendet aber kein Feedback an die Harmony, dass geschaltet wurde (stimmt das?)
- Nach einem relativ kurzen Timeout geht die Harmony dann davon aus, dass die Verbindung unterbrochen ist und zeigt den Fehler an, wie oben beschrieben
- Bei der nächsten zyklischen Anfrage von Harmony an Hue Emulator kommen dann die aktuellen Lampenzustände. Harmony geht davon aus, dass die Verbindung wieder hergestellt worden ist, und löscht die Fehlermeldung.
Könnte das sein? Sollte der Hue Emulator nach einem Schaltvorgang ein Statusupdate schicken? Ich habe leider keine Hue Bridge und kann das Verhalten daher leider nicht überprüfen.
Laut Hue-API-Dokumentation, Kapitel 1.6.5. wird eine Antwort wie z.B.
[ {"success":{"/lights/1/state/bri":200}}, {"success":{"/lights/1/state/on":true}}, {"success":{"/lights/1/state/hue":50000}} ]erwartet nach einem
/api/<username>/lights/<id>/stateeine Antwort wie z.B.
[ {"success":{"/lights/1/state/bri":200}}, {"success":{"/lights/1/state/on":true}}, {"success":{"/lights/1/state/hue":50000}} ]Update:
Laut Wireshark wird gesendet:[{"success":{"/lights/1/state/on":false}}]Meine Vermutung war also falsch. Irgendeine andere Idee, woran es liegen kann?
Update 2
In meinem PCap-Trace, den ich gerade analysiert habe, kommen durchaus Statusänderungen einer Lampe vor, auf deren HTTP-Request nicht geantwortet wurde. Das ist komisch, da der Hue Emulator ja prinzipiell funktioniert und auch im Log kein Fehler steht. Irgendwie scheint es Situationen zu geben, auf die der Hue Emulator zwar den Status intern umstellt im Objekt, dann aber keine Antwort verschickt.Viele Grüße
Stefan -
@Neopholus
Hi Danke für die vielen Infos und detaillierten Analysen. Wenn ich jetzt das Update 2 richtig verstanden habe siehst du das Requests (Ich vermute /api/<username>/lights/<id>/state) nicht beantwortet werden? Also die Vermutung ist das Hamony hier in einen Timeout läuft. Ist das 100% reproduzierbar oder nur hin und wieder?Der Request beinhaltet nur das Ein- und Ausschalten oder? Ich kann heute Abend mal probieren das Interface zu bombardieren und zu schauen, ob ich das auch nachstellen kann.
Optimal wäre, wenn du den Request mit allen Details von Nachricht body, header in einen curl formulierst und auf der gleichen Maschine abschickst, wo auch der Emulator läuft. Somit könnte man ausschließen, dass es irgendwie an der Netzwerkverbindung liegt.
Ich hatte am Anfang so ein ähnliches Problem, welches aber 100% reproduzierbar war. Daher hatte ich HTTP Header: Connection: close hinzugefügt, da einige Clients sonst Probleme damit hatten und die Hue Bridge das tatsächlich auch schickt.
-
@holomekc
Hi, wahrscheinlich bin ich schon zu spät dran, aber um deine Fragen zu beantworten:- Ja, es geht um simple Anfragen wie /api/<username>/lights/<id>/state
- Tritt nicht reproduzierbar auf. Zumindest ist mir bisher kein Muster aufgefallen.
Eine Nachricht, die beantwortet wird:
PUT /api/60329b2b-ff27-XXXX-XXXX-c7f8b05b00a2/lights/5/state HTTP/1.1 connection: close, TE content-length: 12 user-agent: LuaSocket 2.0.2 te: trailers content-type: application/json host: 192.168.3.105 {"on":false} HTTP/1.1 200 OK X-Powered-By: Express Access-Control-Allow-Origin: * Access-Control-Allow-Methods: POST, GET, OPTIONS, PUT, DELETE, HEAD Access-Control-Allow-Credentials: true Access-Control-Max-Age: 3600 Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept Connection: close Content-Type: application/json; charset=utf-8 Content-Length: 42 ETag: W/"2a-uykK5pYlmrKxqMEgMLTtq2vhWxQ" Date: Tue, 31 Mar 2020 20:15:57 GMT [{"success":{"/lights/5/state/on":false}}]Ein nicht beantworteter Request:
PUT /api/60329b2b-ff27-XXXX-XXXX-c7f8b05b00a2/lights/3/state HTTP/1.1 connection: close, TE content-length: 30 user-agent: LuaSocket 2.0.2 te: trailers content-type: application/json host: 192.168.3.105 {"xy":[0,0],"on":true,"bri":0}Das mit curl kann ich erst am Wochenende versuchen um Netz-Probleme auszuschließen. Gute Idee.
Danke, Stefan
-
@holomekc
Einer Eingebung folgend habe ich alle einfachen An/Aus-Lampen mit doch recht stark reduzierten Attributen durch "Extended Color Light" mit allen Attributen einer Originallampe angelegt.Seitdem treten weder die Fehlermeldungen auf der Harmony noch die teilweise langen Verzögerungen mehr auf.
Verstehen tu ich es nicht, aber die Probleme waren sofort nach der Lampen-Neudefinition (und neue Sync auf die Harmony) weg.
Sorry, dass ich dir deswegen Arbeit gemacht habe.
Fazit: Der Adapter funktioniert gut, auch mit der Harmony.
-
@Neopholus
Hi. Habe gerade den fix hochgeladen
Es ist wie du sagt. Wenn einer der Werte nicht gefunden wurde, dann hat der Adapter der Library nicht bescheid gegeben, dass die Bearbeitung fertig ist. Dadurch hing der Request fest und wurde nicht beantwortet. In 0.0.2 ist das jetzt behoben. Dann würde die Antwort bspw so aussehen:
[ { "error": { "type": 6, "address": "/lights/1/state/xy", "description": "parameter, xy, not available" } }, { "error": { "type": 6, "address": "/lights/1/state/bri", "description": "parameter, bri, not available" } }, { "success": { "/lights/1/state/on": true } } ]Edit:
Ich war am überlegen, ob ich dann einfach die Werte hätte hinzufügen sollen. Aber theoretisch ist das denke ich das was auch die hue bridge sagen würde.Edit:
Ich bin eher dankbar, dass du dir das angeschaut hast! Das ganze soll ja funktionieren. Von daher ist Feedback immer Willkommen. Also kurz gesagt: Danke -
@holomekc
Sehr gerne. Und Danke für den Bugfix. Hab ich vor allem gemacht, weil mit ha-bridge und was es sonst noch gibt einfach zu kompliziert oder komplex waren oder einen weiteren Raspi brauchen. Deine Lösung ist super-schlank und wunderbar in iobroker integriert.Das Javascript oben zum Auswerten der Änderungen des Hue Emulators ist übrigens getestet. Kannst du gerne in die Anleitung auf Github kopieren, wenn du willst.
-
Hi,
hab voller Vorfreude den Adapter mal testweise installiert, da ich auch ganz gern meine Wohnzimmerbeleuchtung/Raffstores mit der Harmony FB steuern würde.
Leider kann ich den Hub nicht mit dem Emulator verbinden.Nach kurzer Analyse mittels Wireshark dürfte ich dasselbe Problem haben wie in diesen Thread erwähnt:
https://github.com/diyhue/diyHue/issues/147Auch mein Hub schein nicht nach der HueBridge zu suchen sondern nach dem Hunter Douglas Powerview Hub.
@Neopholus
kannst du mal checken welche FW version auf deinem Hub läuft?
Bzw. hast du eine Elite oder Companion?SG
Christianclosed Harmony Hub unable to detect diyHue bridge #147
-
@bullrandle
Hi Christian,ich habe eine Elite.
FW-Version:- Fernbedienung: 4.15.264
- Hub: 4.15.264
- Nest: 1.1.4
- HEOS: 1.1.7
- Caseta: 1.2.3
- Root-Certificates: 1.1.7
- Quivicon: 1.2.3
Wie sieht deine Konfiguration denn aus?
Meine ist:
- Ip-Adresse, unter der der Server gestartet wird: 0.0.0.0
- Port, auf dem der Server lauscht: 8070
- Ip-Adresse, unter der der Server gefunden wird: 192.168.X.X (die lokale IP meines Raspberry Pis)
- Port, unter dem der Server gefunden wird: 8070
- Bei Bedarf können Sie einen Port für https angeben: 8071
- Mac-Adresse, die in API-Antworten verwendet wird: MAC-Adresse der LAN-Schnittstelle meines Raspberry
Damit ging es dann plötzlich
Viele Grüße
Stefan -
Hab diesselbe FW Version am Hub allerdings nur die Companion, sollte aber ja eigentlich keinen unterschied machen.
Meine Konfiguration für den Adapter ist exakt gleich.
@Neopholus
Kannst du evtl. mal mit Wireshark checken was der Harmony Hub bei dir ausgibt, wenn du nach einer Hue Bridge suchst? -
Kurze Frage zur Funktion: Könnte man mit diesem Adapter jede in ioBroker integrierte Lampe über diese emulierte Hue Bridge steuern? Also dass man mit den bekannten Hue Apps quasi jede seiner smarten Lampen steuern kann? Und ganz einfach Szenen anlegen?
-
@siggi85
Wenn ich dich richtig verstehe dann ja
. Du musst jedoch jede Lampe erst einmal in dem Adapter anlegen. Dazu kannst du die vorhandenen Templates (An/Aus, Farbe, Dimmbar) verwenden. Anschließend musst du die Lampen zu den anderen States in ioBroker verlinken.Du erstellst also immer eine "Fake" Lampe und verknüpfst sie mittels Blockly, Skripte, Node-Red, etc. mit der tatsächlichen Lampe in ioBroker.
-
@holomekc Coole Sache. Man könnte hier doch auch Informationen aus dem neuen Devices Adapter beziehen, oder? Also dass man die Lampen im zentralen Devices Adapter definiert und der Hue Adapter die Informationen genau daraus zieht. Der Devices Adapter ist ja prinzipiell genau für sowas gedacht.
Ist sowas geplant? -
@Neopholus
Vergiss es, musste die gut versteckte XMPP API in der Harmony App aktivieren.
Menu > Harmony Setup > Add/Edit Devices & Activities > Remote & Hub > Enable XMPPJetzt hab ich zumindest mal die Bridge in der Harmony App, allerdings sehe ich noch keine "Lampen" ...
