Test Adapter hueemu (Hue Emulator) v0.0.x

[siggi85]

@holomekc OK, ich warte gespannt.

[simatec]

@siggi85 sagte in Test Adapter hueemu (Hue Emulator) v0.0.x:

OK, ich warte gespannt.

Ich auch

[holomekc]

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.

[simatec]

@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

[holomekc]

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.

[simatec]

@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

[holomekc]

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.

[simatec]

@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

[holomekc]

@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?

[holomekc]

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.

[Airmaxchen]

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.6

Ich 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?

[holomekc]

@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 :(.

[Airmaxchen]

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.6

Vielleicht hilft das weiter?

[holomekc]

@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 1900

Irgend 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.

[Airmaxchen]

@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.

[holomekc]

@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.

[Airmaxchen]

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: 1900

Alle Ports sind frei und meine Harmony funktioniert sonst einwandfrei. Im Log kommt auch keine Meldung.

[holomekc]

@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.

[Airmaxchen]

Ich habe es jetzt auch mit Port 80 versucht. Leider kein Erfolg.
Mir ist noch aufgefallen, dass, wenn ich das Pairing par Android-App versuche, mir angezeigt wird, dass eine Philips Hue Bridge im Netzwerk gefunden wurde. Nur das Pairing funktioniert nicht.
Diese Anzeige kommt aber auch wenn ich den Adapter deaktiviere.

Ich habe im Log auf silly umgestellt. Da kommen aber auch nicht mehr Infos.

[holomekc]

@airmaxchen
Hmm. Noch einmal der Vollständigkeit halber. Du hast Lichter angeklickt und dann auch den startPairing Button? Ich habe kein Android SmartPhone. Das kann ich leider nicht testen.