Test Adapter hueemu (Hue Emulator) v0.0.x
-
@holomekc Jetzt habe ich das alles etwas besser verstanden. Ich habe mir über:
https://<bridge ip address>/api/1028d66426293e821ecfd9ef1a0731df/lights
Die Konfigurationen meiner Lampen geholt. Danach habe ich den Namen einer Farblampe verändert und in den Emulator importiert.Mit der HuePro App konnte ich mich danach sogar verbinden (automatisch wurde die Bridge nicht gefunden, manuell ging es aber). Hier wurden Veränderungen an meiner Testlampe an den Datenpunkten übernommen. Die Hue Werte von existierenden Leuchtmitteln im ioBroker sind meist 0-360 und er spuckt hier 0-65535 aus, aber das kann man ggf. noch regeln (vielleicht kann das irgendwann auch der Adapter übernehmen
)Leider ging das Verbinden mit Hue Essentials nicht (das wäre allerdings mein Favorit). Hier kam entweder ein Fehler beim Anmelden oder die App ist abgebrochen beim Versuch sich zu verbinden. Die Bridge wurde auch hier nicht automatisch entdeckt und ich musste die IP-Adresse manuell eingeben. Beim manuellen Pairen kann ich in Hue Essentials dann folgendes auswählen:
Philips Hue
IKEA TRADRFRI
deCONZ
diyHueIch habe Philips Hue und diyHue ausprobiert, beides ging nicht. Hast du hier ggf. noch ne Idee?
Hier mal der Log, wenn ich es mit diyHue ausprobiere und die App dabei abstürzt.
Aber trotzdem schon mal cool, dass es mit deinem Adpater mind. eine schicke Hue App gibt, die beim Konfigurieren einer Lampe Daten in den ioBroker gepusht bekommt.
-
@siggi85
Das mit Hue Essentials kann ich mir mal anschauen. Auch das mit Umrechnungen zwischen Hue Api und ioBroker. Ich packe es zumindest mal auf die Liste. Was ich aktuell jedoch noch abarbeiten muss ist:
wolf ism7 to mqtt für einen Freund, Jalousien automatisieren auch für einen Freund, Definitiv noch Cyberpunk 2077, ioBroker.bshb noch updaten und dann hätte ich Zeit für hueemu. -
@holomekc OK, ich warte gespannt.
-
-
Hi mal ein paar Infos:
habe den server durch fastify ausgetauscht. Reponse ist bei 5-7ms. Das würde ich jetzt erst einmal so lassen.
Bei discovery bin ich noch dran. Mir fehlen hier Geräte um es auszuprobieren. Nächste Woche bin ich wieder daheim, da kann ich mehr testen. Habe mir das python script und deconz angeschaut. Beide funktionieren ähnlich, wobei ich glaube das der Ansatz von deconz mehr abdeckt. Ich würde das dann übernehmen.
Zu Hue essentials: Ich glaube das kann ich nicht umsetzen. Die app nutzt nicht ssdp, sondern n-upnp. Zumindest denke ich das. Ich kann es nicht genau sagen, da ich keinen Einblick dort habe. Details zu den verschiedenen Möglichkeiten eine Hue-Bridge zu finden gibt es hier:
https://developers.meethue.com/develop/application-design-guidance/hue-bridge-discovery/Bissle mehr im Detail. Die Bridge (oder bspw. Deconz) schickt in einem definierten Interval Bridge-Informationen an einen Server. Bei hue ist es https://discovery.meethue.com/ (Wobei ich hier die put/post Adresse/Methode nicht kenne) und bei deconz/phoscon ist es https://phoscon.de/discover. Die hue essentials app ruft vermutlich dann einfach diesen Endpunkt auf, um sehr schnell die verfügbaren Bridges im Netzwerk zu finden. Da die app nur den Endpunkt abfragen muss (Kann man im Browser austesten) ist das wirklich sehr schnell.
Ich hatte probiert das gleich zu machen wie deconz. Das hat jedoch irgendwie noch nicht funktioniert. Jedoch weiß ich nicht, ob die Kollegen das soll toll fänden, wenn ich deren Endpunkt verwende und Hue-Emu würde dann dort als Phoscon aufgelistet werden.
Der Grund warum hue-essentials dann phoscon bridges findet, ist dass dort in der app der phoscon endpunkt sehr wahrscheinlich abgerufen wird. Auf der offiziellen Seite von hue-essentials wird phoscon auch aufgelistet. Selbst wenn ich einen Server hinstellen würde an den ich die Informationen von hue-emu schicke, würde das nichts bringen, da die App diesen Endpunkt nicht abfragen wird.
Letzte Hoffnung die ich noch habe ist mDNS, da im developer portal von hue steht das ssdp/upnp deprecated ist und durch n-upnp oder mDNS ausgetauscht werden soll. Ersteres ist nicht wirklich praktikabel und mDNS muss ich mir erst anschauen.
-
@holomekc
Hört sich sehr interessant an.
Was wie gesagt noch klasse wäre, wenn man im Adapter direkt mit dem tatsächlichen Gerät verknüpfen könnte. Somit würde man alles dann im Adapter ohne zusätzliche Scripte lösen können.Wenn du ne Testversion hast, sag Bescheid, dann kann ich hier testen und dir Feedback geben, ob sich die Systemlast des Adapters verbessert hat
-
So sorry. Hat wieder etwas länger gedauert. Hatte noch anderes zu tun und ich hatte Probleme beim Pairing. Harmony ging direkt aber Alexa wollte nicht mehr. Lag bei mir an den Templates die ich verwendet habe. Ich habe dementsprechend alle einmal ausgetauscht mit den Infos die meine echten Hue Lampen zurück geben. Ich habe kein on/off light aber ich habe die Osram Steckdose genommen und dann on/off light hingeschrieben. Mit Alexa ging das auf jeden Fall. Die alten Templates existieren im Unterordner old.
Ansonsten wird man noch nicht viel neues sehen. Das Logging ist hoffentlich etwas besser und bezüglich Performance vielleicht einmal kurz folgende Info. Die größte Verzögerung kommt durch das Auslesen der Objekte und States in ioBroker. Die .../api/xxx/lights Endpunkte waren so um die 100ms, wobei dies bestimmt von der Anzahl der Lichter ankommt. Ich habe beim Setzen von states Werten von Lichtern das Auslesen von ioBroker States entfernt, da diese Info von der hueemu lib nur zum Logging verwendet wird. Der Endpunkt ist mit 20-40ms deutlich schneller. Zumindest nach meinem Gefühl ist die Steuerung über Alexa viel viel schneller als wenn ich normale Hue Lampe steuere.
Eine Überlegung wäre es hier das ich einige Werte Cache. Würde aber bedeuten, dass der Adapter neugestartet werden muss, wenn neue Lichter angelernt werden. Ich weiß nicht, ob sich das lohnt. Normalerweise werden die Werte mehr geändert als das der lights Endpunkt ständig aufgerufen wird.
Getestet habe ich auf einen Raspberry Pi 4. Wäre toll, wenn ihr schon einmal bissle testen könntet. Ich würde mir dann das Thema mit den linked devices oder wie das heißt und GUI anschauen. Bei letzterem wäre Hilfe auch willkommen.
-
@holomekc sagte in Test Adapter hueemu (Hue Emulator) v0.0.x:
Ich würde mir dann das Thema mit den linked devices oder wie das heißt und GUI anschauen. Bei letzterem wäre Hilfe auch willkommen.
Ich würde im Menü eine Tabelle machen, wo das tatsächliche Gerät hinzugefügt werden kann (also der state.
Da würde ich dann auch die hue Geräte mit einfügen. Im Code hast du dann die Tabelle als json und kannst diese auswerten und die Geräteverknüpfungen machen.Eine Beispieltabelle hätte z.B. shuttercontrol
-
Hmm ich brauche noch einmal Feedback zu dem verknüpfen wie es gewünscht war. War hiermit ein anderer Adapter gemeint? Linked devices oder devices adapter? Beide hatte ich mir angeschaut aber irgendwie verstehe ich noch nicht wie mich das weiter bringt.
Oder war gemeint das in hueemu selber ein andere state hinterlegt werden kann so wie ich es vom yahka adapter kenne? Also bspw. Für hueemu.0.1.state.on hinterlege ich deconz.0....on Und falls ja, dann müsste ich mehr anbieten als nur state hinterlegen, da unter umständen die Werte ins passende Format umgewandelt werden müssen.
-
@holomekc
Ich würde es direkt in hueemu hinterlegen.
Welches Gerät man denn wählt, ist ja jedem überlassen. Man könnte die ID nehmen oder auch den alias -
@simatec
Ok. Danke für das Feedback.Habe jetzt erst einmal vorher noch folgendes geändert. Ist jedoch noch nicht gepushed:
- Neue config: UPnP mit folgenden Werten. Damit wird der Upnp Server und damit Port 1900 wie folgt verwendet:
- Aktiviert
- Deaktiviert
- Beim koppeln
Ich hätte ein paar Fragen zu der admin ui. Bisher hatte ich immer nur index_m.html verwendet. Jedoch gibt es auch noch tab_m.html und custom_m.html. Ich kann die letzten beiden irgendwie nicht zuordnen. Gibt es hier irgendwo eine Beschreibung dazu?
- Neue config: UPnP mit folgenden Werten. Damit wird der Upnp Server und damit Port 1900 wie folgt verwendet:
-
Hier ein paar Wireframes für eine mögliche GUI. Feedback wäre toll:
Lichter Konfiguration:
Das waren meine ersten Gedanken. Bin bissle vorbelastet durch die yahka GUI. Die fand ich gar nicht so schlecht. Außerdem wollte ich das es möglichst flexible ist. Daher sind bspw. die states Werte komplett individualisierbar. Heißt theoretisch könnte dort auch "brabbel" stehen. Die Templates für das erstellen eines Lichtes würde dann zumindest das initiale Erstellen erleichtern. Aber es würde auch nicht limitieren.
Lichter Konfiguration mittels JSON:
Das gleiche wie oben jedoch rein als JSON. Im Prinzip wäre der Gedanke das der Tab General ein JSON erstellt, welches via Tab JSON eingesehen als auch editiert werden kann. Hier wäre es auch möglich die Werte die bisher unter data stehen einzutragen. Zusätzlich kommen Konfiguration hinzu wie das verlinken und Mapping.
Lichter erstellen aus Template oder JSON:
Hier ein Modal zum initialen erstellen eines Lichtes. Hierbei sollen die Templates verwendet werden die es bereits gibt, bzw. kann auch ein eigenes Template verwendet werden. Nach dem Erstellen würden im General Tab bei states immer Value als initialer Type eingestellt werden. Änderung auf Verlinkung zu einem State wäre dann natürlich möglich.
Ich hoffe die Idee davon wird klar. Wie bereits oben erwähnt. Feedback wäre super.
-
Ahoi!
Ich versuche gerade wieder meine Harmony mit dem hueemu zum Laufen zu bringen.
Leider wechselt der Adapter nach 20 Sekunden immer wieder auf rot um dann nach 30 Sekunden wieder zu starten.
Im Log sieht das Ganze so aus:hueemu.0 2021-02-19 09:55:00.681 info (29682) Terminated (NO_ERROR): Without reason hueemu.0 2021-02-19 09:55:00.680 info (29682) terminating hueemu.0 2021-02-19 09:55:00.638 info (29682) cleaned everything up... hueemu.0 2021-02-19 09:55:00.637 error (29682) Error [ERR_SOCKET_DGRAM_NOT_RUNNING]: Not running at healthCheck (dgram.js:899:11) at Socket.send (dgram.js:624:3) at Timeout._onTimeout (/opt/iobroker/node_modules/hue-emu/dist/up hueemu.0 2021-02-19 09:55:00.636 error (29682) uncaught exception: Not running hueemu.0 2021-02-19 09:54:40.683 info (29682) state hueemu.0.disableAuth changed: false (ack = true) hueemu.0 2021-02-19 09:54:40.667 info (29682) HueServer: Http-Server listening 0.0.0.0:8080 hueemu.0 2021-02-19 09:54:40.613 info (29682) starting. Version 0.0.5 in /opt/iobroker/node_modules/iobroker.hueemu, node: v12.20.0, js-controller: 3.1.6 hueemu.0 2021-02-19 09:54:09.083 info (29634) Terminated (NO_ERROR): Without reason hueemu.0 2021-02-19 09:54:09.082 info (29634) terminating hueemu.0 2021-02-19 09:54:09.039 info (29634) cleaned everything up... hueemu.0 2021-02-19 09:54:09.039 error (29634) Error [ERR_SOCKET_DGRAM_NOT_RUNNING]: Not running at healthCheck (dgram.js:899:11) at Socket.send (dgram.js:624:3) at Timeout._onTimeout (/opt/iobroker/node_modules/hue-emu/dist/up hueemu.0 2021-02-19 09:54:09.038 error (29634) uncaught exception: Not running hueemu.0 2021-02-19 09:53:49.086 info (29634) state hueemu.0.disableAuth changed: false (ack = true) hueemu.0 2021-02-19 09:53:49.070 info (29634) HueServer: Http-Server listening 0.0.0.0:8080 hueemu.0 2021-02-19 09:53:49.014 info (29634) starting. Version 0.0.5 in /opt/iobroker/node_modules/iobroker.hueemu, node: v12.20.0, js-controller: 3.1.6Ich habe es bis jetzt auch nicht geschafft, die Harmony damit zu pairen. Ich weiß nicht ob das an den Neustarts liegt.
Mein ioBroker läuft unter Docker auf einer Synology. Um zu pairen habe ich alles was den Port 1900 verwendet deaktiviert außer minissdpd von der Syno. Sobald ich diesen Dienst stoppe, startet er sofort wieder.
Könnt ihr mit da vielleicht weiterhelfen?
-
@airmaxchen
Hi. Bei mir läuft es auch in docker. Ich habe allerdings network_mode host eingestellt, da sonst das ssdp Protokoll nicht funktionieren wird. Es scheint auch irgendwie das er den udp server nicht bei dir starten kann, wobei die Fehlermeldung nicht genauer sagt warum :(. -
Ich habe es nochmal versucht und, aus welchem Grund auch immer, jetzt mehr Fehlermeldungen:
host.iobroker 2021-02-20 10:47:27.809 info Restart adapter system.adapter.hueemu.0 because enabled host.iobroker 2021-02-20 10:47:27.809 info instance system.adapter.hueemu.0 terminated with code 0 (NO_ERROR) host.iobroker 2021-02-20 10:47:27.809 error Caught by controller[0]: at processTicksAndRejections (internal/process/task_queues.js:85:21) host.iobroker 2021-02-20 10:47:27.809 error Caught by controller[0]: at dgram.js:338:20 host.iobroker 2021-02-20 10:47:27.809 error Caught by controller[0]: Error: bind EADDRINUSE 0.0.0.0:1900 host.iobroker 2021-02-20 10:47:27.808 error Caught by controller[0]: HueUpnp: Server error. Shutdown server: hueemu.0 2021-02-20 10:47:27.290 info (20397) Terminated (NO_ERROR): Without reason hueemu.0 2021-02-20 10:47:27.289 info (20397) terminating hueemu.0 2021-02-20 10:47:27.245 info (20397) cleaned everything up... hueemu.0 2021-02-20 10:47:27.245 error (20397) Error [ERR_SOCKET_DGRAM_NOT_RUNNING]: Not running at healthCheck (dgram.js:899:11) at Socket.send (dgram.js:624:3) at Timeout._onTimeout (/opt/iobroker/node_modules/hue-emu/dist/up hueemu.0 2021-02-20 10:47:27.244 error (20397) uncaught exception: Not running hueemu.0 2021-02-20 10:47:07.294 info (20397) state hueemu.0.disableAuth changed: false (ack = true) hueemu.0 2021-02-20 10:47:07.275 info (20397) HueServer: Http-Server listening 0.0.0.0:8080 hueemu.0 2021-02-20 10:47:07.219 info (20397) starting. Version 0.0.5 in /opt/iobroker/node_modules/iobroker.hueemu, node: v12.20.2, js-controller: 3.1.6Vielleicht hilft das weiter?
-
@airmaxchen
Ja das hilft. Port 1900 ist bereits in Verwendung. Daher funktioniert das Pairing über das SSDP Protokoll nicht. Oder anders ausgedrückt. Der Adapter kann nicht auf sich aufmerksam machen. Daher funktioniert das Pairing nicht mit Harmony.probier mal:
sudo netstat -nap | grep 1900Irgend ein anderer Prozess lauscht offenbar auf diesen Port. Könnte sogar sein das ein package vom Synology NAS diesen Port verwendet, denn leider ist dies nicht unüblich und das Protokoll läuft leider nur über eben diesen Port.
Prinzipiell müsste es gehen den Prozess, welcher den Port blockiert einmal beenden. Dann den Adapter starten (In den Einstellungen UPnP Verhalten auf "beim koppeln" stellen) und anschließend mit Harmony pairen. Anschließend sollte der Port nicht mehr benötigt werden. Durch die Einstellung beim koppeln sollte der Adapter auch nicht immer direkt versuchen den Port 1900 zu belegen, so dass der andere Prozess vom NAS diesen wieder verwenden kann.
-
@holomekc Ja, der Port 1900 wir von einigen Dingen (Fakeroku, TVHeadend,...) verwendet. Die habe ich auch alle deaktivieren können mit Ausnahme von minissdpd von der Syno. Ich kann zwar den Prozess killen aber leider startet er sich sofort wieder.
Da muss ich noch schauen wie ich den Neustart verhindern kann.
Liegt es auch daran, dass hueemu immer wieder neu startet? Weil ich die anderen Dienste nach erfolgreichem Pairing wieder starten muss und da sollte hueemu laufen und nicht immer neu starten. -
@airmaxchen
Ich denke das Neustarten sollte sich durch die Einstellung von UpnP verhindern lassen. Denke. Ansonsten muss ich noch einmal schauen. Ist definitiv nicht ideal. Eigentlich sollte er nicht deswegen neustarten. -
Ich habe es jetzt endlich geschafft den Port 1900 frei zu machen. Also laut netstat wird er nur von hueemu verwendet und der Adapter startet sich auch nicht mehr ständig neu.
Leider schaffe ich es trotzdem nicht, die Harmony zu verbinden. Weder mit der Android-App noch mit dem Desktop-Programm am PC wird hueemu gefunden.
Meine Einstellungen:
IP gestartet: 0.0.0.0
Port lauscht: 8070
IP gefunden: 192.168.178.34 (mein NAS mit ioBroker im Docker)
Port gefunden: 8070
Port https: 8071
Mac: die Mac meines NAS
UPnP: 1900Alle Ports sind frei und meine Harmony funktioniert sonst einwandfrei. Im Log kommt auch keine Meldung.
-
@airmaxchen
Anhand der IP vermute ich du hast docker im network mode host laufen. Das wäre ja dann passend. Du kannst probieren den Adapter mal auf debug oder silly zu stellen. Dann müssten die ssdp Nachrichten sichtbar sein. Dort müssten auch welche von der ip von Harmony auftauchen.Ich meine Harmony kam auch mit ports != 80 klar. Das kann ich später noch mal bei mir testen.
