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

[Neopholus]

@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

[Neopholus]

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

[holomekc]

@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

[Neopholus]

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

[bullrandle]

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/147

Auch 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
Christian

arachnetech created this issue in diyhue/diyHue

closed Harmony Hub unable to detect diyHue bridge #147

[Neopholus]

@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

[bullrandle]

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?

[siggi85]

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?

[holomekc]

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

[siggi85]

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

[bullrandle]

@Neopholus
Vergiss es, musste die gut versteckte XMPP API in der Harmony App aktivieren.
Menu > Harmony Setup > Add/Edit Devices & Activities > Remote & Hub > Enable XMPP

Jetzt hab ich zumindest mal die Bridge in der Harmony App, allerdings sehe ich noch keine "Lampen" ...

[bullrandle]

Wohl doch zu früh gefreut, Harmony findet die Bridge nicht mehr

[bullrandle]

Testweise hab ich mal eine HABridge auf Windows laufen lassen und die wird von meinem Harmony Hub gefunden.
Somit glaube ich nicht, dass es (nur) an meinem Hub liegt.

Bin etwas ratlos wie ich weitermachen bzw. was ich noch ausprobieren kann/soll ...

@holomekc
@Neopholus
habt ihr mal probiert ob die Hue App die hueemu bridge findet? Sollte das funktionieren?

[holomekc]

@bullrandle
Hi aktuell bin ich etwas unter Wasser. Aber am langen Wochenende kann ich schauen. Mit der Hue App habe ich nicht probiert. Ich habe Harmony aber auch hier. Hatte aber bisher nur Alexa gekoppelt. Ich teste mal ein wenig.

[holomekc]

@bullrandle
Hi. Ich habe es gerade getestet und bei mir geht es mit der aktuellen Version. Auch die Lichter werden in der Harmony App richtig erkannt. Ich musste auch nicht XMPP aktivieren. Das sollte damit auch nichts zu tun haben. Das ganze läuft über SSDP.

Was mir jedoch aufgefallen ist. Ich habe auch ioBroker.deconz installiert. Dieser hat den Port 1900 blockiert. Dort wird es wohl verwendet, um zu schauen, ob eine Hue Bridge noch da ist. Ist für hueemu ganz schlecht, da dort die SSDP Nachrichten abgehandelt werden. Was du in so einem Fall machen kannst ist deconz kurz deaktivieren, dann hueemu starten und dann das Pairing starten.

Zum testen (so sah das bei mir aus):

sudo netstat -nap | grep 1900
udp        0      0 0.0.0.0:1900            0.0.0.0:*                           3919/io.deconz.0
udp6       0      0 :::1900                 :::*                                3919/io.deconz.0
udp6       0      0 :::1900                 :::*                                3919/io.deconz.0
udp6       0      0 :::1900                 :::*                                3919/io.deconz.0
udp6       0      0 :::1900                 :::*                                3919/io.deconz.0

Was bei hueemu vielleicht nicht so gut ist, ist das die Info dazu bisher nur auf debug geloggt wird. Das kann ich mir bei Gelegenheit mal anschauen:
hueemu.0 2020-05-02 18:43:16.212 debug (22985) HueUpnp: Server error. Shutdown server: Error: bind EADDRINUSE 0.0.0.0:1900 at dgram.js:334:20 at processTicksAndRejections (internal/process/task_queues.js:82:21)

@siggi85
Den Devices Adapter schaue ich mir mal bei Gelegenheit an.

[bullrandle]

@holomekc
Das war der goldene Tipp. Port 1900 war bei mir von fakeroku blockiert. Kurz deaktiviert und im 2. Anlauf gings dann.

Nachdem ich auf einem jungfräulichen ioBroker nur die hueemu installiert hatte und die von meiner Harmony gefunden wurde hatte ich auch schon angefangen in Richtung der Ports zu debuggen, hätt aber wohl noch länger gedauert bis ich das gefunden hätte, danke für die Zeitersparnis

Ja, die Fehlermeldung als error im Log wär wohl sehr hilfreich gewesen, aber was nicht ist ...

[Airmaxchen]

Ich habe jetzt auch versucht hueemu mit meinem Harmony Hub zu verbinden. Leider funktioniert das Pairing nicht.
Die Einstellungen habe ich mMn richtig gemacht. Stimmt es, dass die Mac-Adresse mit Doppelpunkten geschrieben wird?Der Adapter ist auch grün.
XMPP ist aktiv.

[holomekc]

@Airmaxchen
Schau mal bitte, ob die Infos bezüglich des blockierten ports nicht auch für dich gelten. XMPP muss nicht für die Funktionalität aktiviert werden.
Anonsten stell den Adapter mal auf silly und schau was er dir beim starten sagt.

[Airmaxchen]

Ok, da steige ich leider aus.

2020-05-11 12:16:55.590 - info: host.iobrokerpi "system.adapter.hueemu.0" enabled
2020-05-11 12:16:55.615 - info: host.iobrokerpi instance system.adapter.hueemu.0 started with pid 3476
2020-05-11 12:16:57.096 - debug: hueemu.0 (3476) Redis Objects: Use Redis connection: 127.0.0.1:9001
2020-05-11 12:16:57.149 - debug: hueemu.0 (3476) Objects client ready ... initialize now
2020-05-11 12:16:57.155 - debug: hueemu.0 (3476) Objects create System PubSub Client
2020-05-11 12:16:57.157 - debug: hueemu.0 (3476) Objects create User PubSub Client
2020-05-11 12:16:57.158 - debug: hueemu.0 (3476) Objects client initialize lua scripts
2020-05-11 12:16:57.173 - debug: hueemu.0 (3476) Objects connected to redis: 127.0.0.1:9001
2020-05-11 12:16:57.182 - debug: hueemu.0 (3476) objectDB connected
2020-05-11 12:16:57.186 - debug: hueemu.0 (3476) Redis States: Use Redis connection: 127.0.0.1:9000
2020-05-11 12:16:57.192 - debug: hueemu.0 (3476) States create User PubSub Client
2020-05-11 12:16:57.195 - debug: hueemu.0 (3476) States create System PubSub Client
2020-05-11 12:16:57.202 - debug: hueemu.0 (3476) States connected to redis: 127.0.0.1:9000
2020-05-11 12:16:57.202 - debug: hueemu.0 (3476) statesDB connected
2020-05-11 12:16:57.956 - info: hueemu.0 (3476) starting. Version 0.0.2 in /opt/iobroker/node_modules/iobroker.hueemu, node: v10.20.1
2020-05-11 12:16:58.007 - silly: hueemu.0 (3476) onReady called. Load configuration
2020-05-11 12:16:58.041 - info: hueemu.0 (3476) hueemu.0
2020-05-11 12:17:03.059 - debug: hueemu.0 (3476) HueUpnp: Server listening 0.0.0.0:1900
2020-05-11 12:17:03.068 - debug: hueemu.0 (3476) HueServer: Http-Server listening 0.0.0.0:8070
2020-05-11 12:17:03.068 - debug: hueemu.0 (3476) HueServer: Https-Server listening 0.0.0.0:8071
2020-05-11 12:17:03.070 - silly: hueemu.0 (3476) States system redis pmessage system.adapter.hueemu.0.logLevel/system.adapter.hueemu.0.logLevel:{"val":"silly","ack":true,"ts":1589192218025,"q":0,"from":"system.adapter.hueemu.0","lc":1589192218025}
2020-05-11 12:17:03.083 - silly: hueemu.0 (3476) States system redis pmessage *.logging/system.adapter.admin.0.logging:{"val":true,"ack":true,"ts":1589192218255,"q":0,"from":"system.adapter.admin.0","lc":1589192218255}
2020-05-11 12:17:03.084 - debug: hueemu.0 (3476) system.adapter.admin.0: logging true
2020-05-11 12:17:03.115 - silly: hueemu.0 (3476) States user redis pmessage hueemu.0.*/hueemu.0.disableAuth:{"val":true,"ack":true,"ts":1589192223110,"q":0,"from":"system.adapter.hueemu.0","user":"system.user.admin","lc":1589187670741}
2020-05-11 12:17:03.118 - info: hueemu.0 (3476) state hueemu.0.disableAuth changed: true (ack = true)
2020-05-11 12:17:10.363 - silly: hueemu.0 (3476) HueUpnp: Server got request: M-SEARCH * HTTP/1.1
HOST: 239.255.255.250:1900
MAN: "ssdp:discover"
ST: upnp:rootdevice
MX: 5
from 192.168.178.34:48316
2020-05-11 12:17:10.363 - debug: hueemu.0 (3476) HueUpnp: Server got M-SEARCH request: M-SEARCH * HTTP/1.1
HOST: 239.255.255.250:1900
MAN: "ssdp:discover"
ST: upnp:rootdevice
MX: 5
from 192.168.178.34:48316
2020-05-11 12:17:10.366 - debug: hueemu.0 (3476) HueUpnp: Send response to M-SEARCH request from 192.168.178.34:48316
2020-05-11 12:17:11.343 - silly: hueemu.0 (3476) HueUpnp: Server got request: M-SEARCH * HTTP/1.1
HOST: 239.255.255.250:1900
MAN: "ssdp:discover"
MX: 1
ST: urn:dial-multiscreen-org:service:dial:1
from 192.168.178.57:40798
2020-05-11 12:17:11.344 - debug: hueemu.0 (3476) HueUpnp: Server got M-SEARCH request: M-SEARCH * HTTP/1.1
HOST: 239.255.255.250:1900
MAN: "ssdp:discover"
MX: 1
ST: urn:dial-multiscreen-org:service:dial:1
from 192.168.178.57:40798
2020-05-11 12:17:11.345 - debug: hueemu.0 (3476) HueUpnp: Send response to M-SEARCH request from 192.168.178.57:40798
2020-05-11 12:17:11.654 - silly: hueemu.0 (3476) HueUpnp: Server got request: M-SEARCH * HTTP/1.1
HOST: 239.255.255.250:1900
MAN: "ssdp:discover"
MX: 1
ST: urn:dial-multiscreen-org:service:dial:1
from 192.168.178.57:40798
2020-05-11 12:17:11.655 - debug: hueemu.0 (3476) HueUpnp: Server got M-SEARCH request: M-SEARCH * HTTP/1.1
HOST: 239.255.255.250:1900
MAN: "ssdp:discover"
MX: 1
ST: urn:dial-multiscreen-org:service:dial:1
from 192.168.178.57:40798
2020-05-11 12:17:11.656 - debug: hueemu.0 (3476) HueUpnp: Send response to M-SEARCH request from 192.168.178.57:40798
2020-05-11 12:17:11.957 - silly: hueemu.0 (3476) HueUpnp: Server got request: M-SEARCH * HTTP/1.1
HOST: 239.255.255.250:1900
MAN: "ssdp:discover"
MX: 1
ST: urn:dial-multiscreen-org:service:dial:1
from 192.168.178.57:40798
2020-05-11 12:17:11.958 - debug: hueemu.0 (3476) HueUpnp: Server got M-SEARCH request: M-SEARCH * HTTP/1.1
HOST: 239.255.255.250:1900
MAN: "ssdp:discover"
MX: 1
ST: urn:dial-multiscreen-org:service:dial:1
from 192.168.178.57:40798
2020-05-11 12:17:11.961 - debug: hueemu.0 (3476) HueUpnp: Send response to M-SEARCH request from 192.168.178.57:40798
2020-05-11 12:17:20.363 - silly: hueemu.0 (3476) HueUpnp: Server got request: M-SEARCH * HTTP/1.1
HOST: 239.255.255.250:1900
MAN: "ssdp:discover"
ST: upnp:rootdevice
MX: 5
from 192.168.178.34:48316

Zu Info: 192.168.178.34 ist mein Synology NAS und .57 ist ein Android Tablet, das aber eigentlich nichts mit ioBroker und Harmony zu tun hat.

[holomekc]

@Airmaxchen
Das mehrere Geräte antworten ist normal das liegt an dem SSDP Protokoll. Das schreit sozusagen in deinem Netztwerk: Hey hier bin ich und antworte mir doch mal. Und jeder im Netzwerk der das Protokoll spricht antwortet halt.

Sieht aber eigentlich erst einmal gut aus. Ich schaue noch mal genauer, wenn ich mehr Zeit habe.

Bei mir gibt der Adapter vor er würde auf Port 80 laufen, obwohl er auf 8070 läuft. Glaube aber nicht das es für Harmony eine Rolle spielt. Hatte das bisher nur bei Alexa gesehen. Werde ich aber auch mal testen.

Ansonsten ist in solchen Fällen wireshark immer ganz gut, um zu schauen was für Nachrichten verschickt werden.

Edit:
Kannst du vielleicht auch mal deine Konfiguration posten?