Einrichtung node-red-contrib-amazon-echo #305

janner2000 · 2020-01-15T06:03:15Z

Kannst du mir helfen das "node-red-contrib-amazon-echo" zum laufen zu bekommen????

Was mich nur wundert das im Fehlerlog steht das "all handlers for /addons/red/comms? on /addons/red/ are down." sind

CCU3 mit aktueller Raspberrymatic
Node Red 5.3.9
node Amazon Echo Hub auf Port 6502 eingestellt und ist Online.
Amazon Alexa findet keine Geräte. Einrichtung mit Alexa App in IOS.
Firewall in der CCU3 ist AUS um zu verhindern das Ports geblockt werden.

lighthttp-error.log

2020-01-14 22:03:19: (server.c.1521) server started (lighttpd/1.4.54)
2020-01-14 22:03:31: (gw_backend.c.236) establishing connection failed: Connection refused socket: tcp:127.0.0.1:1880
2020-01-14 22:03:31: (gw_backend.c.939) all handlers for /addons/red/comms? on /addons/red/ are down.
2020-01-14 22:03:33: (gw_backend.c.315) gw-server re-enabled: tcp:127.0.0.1:1880 127.0.0.1 1880
2020-01-14 22:03:34: (gw_backend.c.236) establishing connection failed: Connection refused socket: tcp:127.0.0.1:8183
2020-01-14 22:03:34: (gw_backend.c.939) all handlers for /esp/system.htm?sid=@UfXme0SERL@&action=UpdateUI on are down.
2020-01-14 22:03:35: (gw_backend.c.236) establishing connection failed: Connection refused socket: tcp:127.0.0.1:1880
2020-01-14 22:03:35: (gw_backend.c.939) all handlers for /addons/red/comms? on /addons/red/ are down.
2020-01-14 22:03:36: (gw_backend.c.315) gw-server re-enabled: tcp:127.0.0.1:8183 127.0.0.1 8183
2020-01-14 22:03:37: (gw_backend.c.315) gw-server re-enabled: tcp:127.0.0.1:1880 127.0.0.1 1880
2020-01-14 22:03:39: (gw_backend.c.236) establishing connection failed: Connection refused socket: tcp:127.0.0.1:1880
2020-01-14 22:03:39: (gw_backend.c.939) all handlers for /addons/red/comms? on /addons/red/ are down.
2020-01-14 22:03:41: (gw_backend.c.315) gw-server re-enabled: tcp:127.0.0.1:1880 127.0.0.1 1880
2020-01-14 22:03:42: (gw_backend.c.236) establishing connection failed: Connection refused socket: tcp:127.0.0.1:1880
2020-01-14 22:03:42: (gw_backend.c.939) all handlers for /addons/red/comms? on /addons/red/ are down.
2020-01-14 22:03:44: (gw_backend.c.315) gw-server re-enabled: tcp:127.0.0.1:1880 127.0.0.1 1880
2020-01-14 22:03:46: (gw_backend.c.236) establishing connection failed: Connection refused socket: tcp:127.0.0.1:1880
2020-01-14 22:03:46: (gw_backend.c.939) all handlers for /addons/red/comms? on /addons/red/ are down.
2020-01-14 22:03:48: (gw_backend.c.315) gw-server re-enabled: tcp:127.0.0.1:1880 127.0.0.1 1880
2020-01-14 22:03:49: (gw_backend.c.236) establishing connection failed: Connection refused socket: tcp:127.0.0.1:8183
2020-01-14 22:03:49: (gw_backend.c.939) all handlers for /esp/system.htm?sid=@UfXme0SERL@&action=UpdateUI on are down.
2020-01-14 22:03:51: (gw_backend.c.315) gw-server re-enabled: tcp:127.0.0.1:8183 127.0.0.1 8183

wernersv · 2020-01-15T06:20:01Z

Der Port 1880 ist offenbar nodered selbst. Funktioniert redmatic ohne die alexa node?

janner2000 · 2020-01-15T06:23:56Z

Funktioniert alles wunderbar.
Ich habe allerdings noch um mit Alexa zu steuern das node-red-contrib-alexa-home-skill installiert.
Wollte wegen der Doppeladministration davon weg.

MaStahl84 · 2020-01-16T16:05:55Z

Hallo, das gleiche Problem tritt bei mir auch auf. Bekomme das "node-red-contrib-amazon-echo" nicht dazu bewegt von einen Amazon Echo Gerät erkannt zu werden. Egal ob v1, v2, v3 oder Android Alexa-App. Port steht auf 6502 wie beschrieben.
Ports im Redmatic habe ich test weise ebenfalls alle geöffnet.
"lighthttp-error.log" sieht gleich aus.
Bei einem Test in iobroker mit Node-Red funktioniert der "node-red-contrib-amazon-echo" und Alexa erkennt die Geräte sofort im Netzwerk.

jadze65 · 2020-01-16T18:27:35Z

Habe das gleiche Problem wie @janner2000.
Im Error Log taucht der 6502 nicht auf.

Aktuelles Redmatic auf ccu3.

@wernersv Auf welcher Plattform läuft es bei dir ?

muellerjm · 2020-01-17T05:54:52Z

Hallo, bei mir auch das Gleiche. Keine Chance. Auch nicht nach einer Neuinstallation

marcdo70 · 2020-01-17T21:06:38Z

Bei mir auch das gleiche Problem, Port 6502 online aber keine Geräte gefunden

wernersv · 2020-01-19T10:43:02Z

Meine Firmwareversion: 3.47.22.20191130 (Raspberrymatic)
node-red-contrib-amazon-echo läuft in der CCU

# netstat -pan|grep "1880.*LISTEN"
tcp        0      0 127.0.0.1:1880          0.0.0.0:*               LISTEN      1278/node-red

Wenn bei Port 1880 ein Connection Refused kommt, dann ist node-red nicht gestartet.
Startseite > Einstellungen > Systemsteuerung -->Redmatic
Node-RED Prozess sollte auf running stehen.

Im Flow sollte "Amazon Echo Hub" im Status online sein
Der Port für die Node kann auch auf einen anderen gesetzt werden. Dann ist jedoch die Proxy-Regel in /usr/local/addons/redmatic/etc/lighttpd.conf anzupassen.

$HTTP["url"] =~ "(^/description.xml)|(^/api/.*/lights)" {
  proxy.server = ( "" => ("localhost" => ("host" => "127.0.0.1", "port" => 6502)))
}

Hier das error log direkt nach dem reboot:

# less lighttpd-error.log
2020-01-19 10:32:03: (server.c.1464) server started (lighttpd/1.4.53)
2020-01-19 10:32:06: (gw_backend.c.240) establishing connection failed: Connection refused socket: tcp:127.0.0.1:8183
2020-01-19 10:32:06: (gw_backend.c.956) all handlers for /? on  are down.
2020-01-19 10:32:08: (gw_backend.c.319) gw-server re-enabled: tcp:127.0.0.1:8183 127.0.0.1 8183
2020-01-19 10:34:38: (server.c.2059) server stopped by UID = 0 PID = 653
2020-01-19 10:34:38: (server.c.1464) server started (lighttpd/1.4.53)
2020-01-19 10:34:38: (server.c.2059) server stopped by UID = 0 PID = 1628
2020-01-19 10:34:38: (server.c.1464) server started (lighttpd/1.4.53)
...

Portnummer 8183 ist Homematic ReGa und hat nichts mit Redmatic zu tun. Das tritt bei mir auch ohne Redmatic auf.

Successful Discover:

tail -1000 -f lighttpd-access.log |grep -v Windows
192.168.177.57 192.168.177.6 - [19/Jan/2020:10:40:20 +0100] "GET /api/c6260f982b43a226b5542b967f612ce/lights HTTP/1.1" 200 14506 "-" "-"
192.168.177.66 192.168.177.6 - [19/Jan/2020:10:40:20 +0100] "GET /api/c6260f982b43a226b5542b967f612ce/lights HTTP/1.1" 200 14506 "-" "-"
192.168.177.43 192.168.177.6 - [19/Jan/2020:10:40:21 +0100] "GET /api/c6260f982b43a226b5542b967f612ce/lights HTTP/1.1" 200 14506 "-" "-"
192.168.177.43 192.168.177.6 - [19/Jan/2020:10:40:23 +0100] "GET /upnp/basic_dev.cgi HTTP/1.1" 200 981 "-" "-"
192.168.177.57 192.168.177.6 - [19/Jan/2020:10:40:30 +0100] "GET /upnp/basic_dev.cgi HTTP/1.1" 200 981 "-" "-"
192.168.177.66 192.168.177.6 - [19/Jan/2020:10:40:33 +0100] "GET /upnp/basic_dev.cgi HTTP/1.1" 200 981 "-" "-"

Es sind 3 identische Anfragen zu sehen, welche vermutlich von meinen 3 Echo Dot Geräten stammen.
Alle werden mit HTTP-Status 200 (ok) beantwortet. Dabei werden 14506 Byte als Antwort gesendet.

Schalte ich die Proxy-Regel aus, so bekommen die Requests einen 404 als Antwort.

192.168.177.43 192.168.177.6 - [19/Jan/2020:10:47:23 +0100] "GET /api/c6260f982b43a226b5542b967f612ce/lights HTTP/1.1" 404 341 "-" "-"
192.168.177.66 192.168.177.6 - [19/Jan/2020:10:47:23 +0100] "GET /api/c6260f982b43a226b5542b967f612ce/lights HTTP/1.1" 404 341 "-" "-"
192.168.177.57 192.168.177.6 - [19/Jan/2020:10:47:23 +0100] "GET /api/c6260f982b43a226b5542b967f612ce/lights HTTP/1.1" 404 341 "-" "-"
192.168.177.66 192.168.177.6 - [19/Jan/2020:10:47:24 +0100] "GET /upnp/basic_dev.cgi HTTP/1.1" 200 981 "-" "-"
192.168.177.57 192.168.177.6 - [19/Jan/2020:10:47:27 +0100] "GET /upnp/basic_dev.cgi HTTP/1.1" 200 981 "-" "-"
192.168.177.43 192.168.177.6 - [19/Jan/2020:10:47:28 +0100] "GET /api/c6260f982b43a226b5542b967f612ce/lights HTTP/1.1" 404 341 "-" "-"
192.168.177.66 192.168.177.6 - [19/Jan/2020:10:47:28 +0100] "GET /api/c6260f982b43a226b5542b967f612ce/lights HTTP/1.1" 404 341 "-" "-"
192.168.177.57 192.168.177.6 - [19/Jan/2020:10:47:28 +0100] "GET /api/c6260f982b43a226b5542b967f612ce/lights HTTP/1.1" 404 341 "-" "-"
192.168.177.43 192.168.177.6 - [19/Jan/2020:10:47:33 +0100] "GET /api/c6260f982b43a226b5542b967f612ce/lights HTTP/1.1" 404 341 "-" "-"
192.168.177.66 192.168.177.6 - [19/Jan/2020:10:47:33 +0100] "GET /api/c6260f982b43a226b5542b967f612ce/lights HTTP/1.1" 404 341 "-" "-"
192.168.177.57 192.168.177.6 - [19/Jan/2020:10:47:33 +0100] "GET /api/c6260f982b43a226b5542b967f612ce/lights HTTP/1.1" 404 341 "-" "-"
192.168.177.43 192.168.177.6 - [19/Jan/2020:10:47:36 +0100] "GET /upnp/basic_dev.cgi HTTP/1.1" 200 981 "-" "-"
192.168.177.43 192.168.177.6 - [19/Jan/2020:10:47:38 +0100] "GET /api/c6260f982b43a226b5542b967f612ce/lights HTTP/1.1" 404 341 "-" "-"
192.168.177.66 192.168.177.6 - [19/Jan/2020:10:47:38 +0100] "GET /api/c6260f982b43a226b5542b967f612ce/lights HTTP/1.1" 404 341 "-" "-"
192.168.177.57 192.168.177.6 - [19/Jan/2020:10:47:38 +0100] "GET /api/c6260f982b43a226b5542b967f612ce/lights HTTP/1.1" 404 341 "-" "-"
192.168.177.43 192.168.177.6 - [19/Jan/2020:10:47:43 +0100] "GET /api/c6260f982b43a226b5542b967f612ce/lights HTTP/1.1" 404 341 "-" "-"
192.168.177.66 192.168.177.6 - [19/Jan/2020:10:47:43 +0100] "GET /api/c6260f982b43a226b5542b967f612ce/lights HTTP/1.1" 404 341 "-" "-"
192.168.177.57 192.168.177.6 - [19/Jan/2020:10:47:43 +0100] "GET /api/c6260f982b43a226b5542b967f612ce/lights HTTP/1.1" 404 341 "-" "-"
192.168.177.43 192.168.177.6 - [19/Jan/2020:10:47:48 +0100] "GET /api/c6260f982b43a226b5542b967f612ce/lights HTTP/1.1" 404 341 "-" "-"
192.168.177.66 192.168.177.6 - [19/Jan/2020:10:47:48 +0100] "GET /api/c6260f982b43a226b5542b967f612ce/lights HTTP/1.1" 404 341 "-" "-"
192.168.177.57 192.168.177.6 - [19/Jan/2020:10:47:48 +0100] "GET /api/c6260f982b43a226b5542b967f612ce/lights HTTP/1.1" 404 341 "-" "-"
192.168.177.43 192.168.177.6 - [19/Jan/2020:10:47:53 +0100] "GET /api/c6260f982b43a226b5542b967f612ce/lights HTTP/1.1" 404 341 "-" "-"
192.168.177.66 192.168.177.6 - [19/Jan/2020:10:47:53 +0100] "GET /api/c6260f982b43a226b5542b967f612ce/lights HTTP/1.1" 404 341 "-" "-"
192.168.177.57 192.168.177.6 - [19/Jan/2020:10:47:53 +0100] "GET /api/c6260f982b43a226b5542b967f612ce/lights HTTP/1.1" 404 341 "-" "-"
192.168.177.43 192.168.177.6 - [19/Jan/2020:10:47:58 +0100] "GET /api/c6260f982b43a226b5542b967f612ce/lights HTTP/1.1" 404 341 "-" "-"
192.168.177.66 192.168.177.6 - [19/Jan/2020:10:47:58 +0100] "GET /api/c6260f982b43a226b5542b967f612ce/lights HTTP/1.1" 404 341 "-" "-"
192.168.177.57 192.168.177.6 - [19/Jan/2020:10:47:58 +0100] "GET /api/c6260f982b43a226b5542b967f612ce/lights HTTP/1.1" 404 341 "-" "-"

marcdo70 · 2020-01-19T11:02:33Z

Ähm, das sind alles böhmische Dörfer für mich. Habe ich keine Ahnung von, sorry. LG Von meinem P30 Pro

jadze65 · 2020-01-19T12:12:24Z

Hallo,
ich sehe überhaupt kein Zugriff im lighttpd-access.log wenn ich die Gerätesuche in der Alexa App starte.
Die Firewall sollte ja keine große Rolle spiele, da es ja wohl über Port 80 gehen soll.

Auch ein Ausschalten der Firewall bringt keine Besserung.

Wenn ich das richtig verstehe, wird bei der Alexa Gerätesuche über Port 80 gesucht.
Anfrage vom Typ /api/xxxxxxxxxxxxxxx/lights werden an Port 6502 weitergeleitet.

Sind die Anfragen immer auf xx/lights ?
Müssen Geräte eines bestimmten Typs gesucht werden ?

Kenne mich mit Proxy Regeln nicht aus.
Welche Rolle spielt die Datei description.xml in der Proxy Regel ?

wernersv · 2020-01-19T12:49:42Z

Mein letzter Kommentar war auch eher für @janner2000 gedacht.
Bitte nicht falsch verstehen, aber ein "es geht nicht bei Port 6502" ohne weitere diagnostische Infos zu liefern bringt uns einer Lösung keinen Schritt näher. Daher auch die Erläuterung meiner Schritte zur weiteren Diagnose für diejenigen bei denen es nicht funktioniert.

Ich versuche es daher nochmal etwas anders zu formulieren.

Der Webserver der CCU (lighttpd) läuft auf Port 80.
Redmatic (node-red) läuft auf einem anderen Port.
Damit im Browser auf die Oberfläche von Redmatic zugegriffen werden kann, ohne den Port von Redmatic anzugeben, müssen die Anforderungen weitergeleitet werden. Das geschieht über sog. Proxy-Regeln. Das sieht dann so aus, als ob Node-Red im Webserver der CCU läuft - tut er aber nicht.

Gleiches gilt für die Amazon Node. Diese lauscht in diesem Fall dann auf Port 6502. Der Webserver der CCU soll Anfragen entsprechend auf Port 6502 weiterleiten. Dafür ist die Proxy-Regel definiert.
Wie @jadze65 das richtig erkannt hat, werden die Anfragen genau so weitergereicht.

Das Muster /api/xxxxxxxx/lights ist, wie ich das sehe die Schnittstelle, wie Lampen u.ä. Geräte erkannt werden. Das habe ich so aus dem access.log herausgelesen.

Auch die Node selbst sieht mir verdächtig danach aus, als ob alles wie eine Lampe behandelt wird.
Stört aber nicht weiter, wenn man beispielsweise ein Rollo steuern will und die Helligkeit auf einen Prozentwert setzt:

http:///description.xml oder per SSH auf der CCU selbst: http://localhost:6502/description.xml fördert folgendes zu Tage:

Die Node ist also eine Hue Lampe :-)

Doch nun zurück zum Access.log

Wenn im lighttpd-access.log nichts ankommt, dann landen die Anfragen vom Echo oder der Alexa-App nicht auf dem Webserver der CCU und der kann dann folglich auch nichts weiterleiten.

Es ist also als erstes sicherzustellen, dass die Anfrage auch auf dem Webserver landet.

Die Firewall meiner CCU ist so eingestellt, dass die Ports offen sind.
Als Portfreigaben habe ich: 80;443;1900/udp
und
IP-Adressen für den eingeschränkten Zugriff: 192.168.177.0/24.
Homematic XML-RPC API: eingeschränkt.
Remote Homematic-Script API: eingeschränkt

Wenn das bei euch so eingestellt ist, dann solltet ihr per SSH auf die CCU gehen und in der Konsole ein "tail -1000 -f /var/log/lighttpd-access.log" machen.
Man kann mit "... |grep -v " auch verschiedene Zeilen rausfiltern/entfernen.

Steht nix im access.log, dann kommt auch nix an das verarbeitet werden könnte.
Wenn die Ports blockiert sind (Firewall ist zu), dann müsste ggf. 6502 als Port in die Liste der Ausnahmen eingetragen werden. Das habe ich aber nicht probiert.

jadze65 · 2020-01-19T13:20:57Z

Wenn ich die Firewall runterfahre, sehe ich folgende Zugriffe die von meinen beiden Alexa Geräten kommen.

Das bringt mich jetzt aber auch nicht weiter.

192.168.0.21 192.168.0.59 - [19/Jan/2020:14:13:12 +0100] "POST /api HTTP/1.1" 404 9 "-" "Dalvik/2.1.0 (Linux; U; Android 5.1.1; AEORK Build/LVY48F)"
192.168.0.25 192.168.0.59 - [19/Jan/2020:14:13:12 +0100] "POST /api HTTP/1.1" 404 9 "-" "Dalvik/2.1.0 (Linux; U; Android 7.1.2; AEODN Build/NS6431)"
192.168.0.25 192.168.0.59 - [19/Jan/2020:14:13:14 +0100] "GET /upnp/basic_dev.cgi HTTP/1.1" 200 987 "-" "Dalvik/2.1.0 (Linux; U; Android 7.1.2; AEODN Build/NS6431)"
192.168.0.21 192.168.0.59 - [19/Jan/2020:14:13:17 +0100] "POST /api HTTP/1.1" 404 9 "-" "Dalvik/2.1.0 (Linux; U; Android 5.1.1; AEORK Build/LVY48F)"
192.168.0.25 192.168.0.59 - [19/Jan/2020:14:13:17 +0100] "POST /api HTTP/1.1" 404 9 "-" "Dalvik/2.1.0 (Linux; U; Android 7.1.2; AEODN Build/NS6431)"
192.168.0.21 192.168.0.59 - [19/Jan/2020:14:13:20 +0100] "GET /upnp/basic_dev.cgi HTTP/1.1" 200 987 "-" "Dalvik/2.1.0 (Linux; U; Android 5.1.1; AEORK Build/LVY48F)"

jadze65 · 2020-01-19T13:27:34Z

http://192.168.0.59:6502/description.xml zeigt mir die Hue Bridge an ???

root xmlns="urn:schemas-upnp-org:device-1-0"> <specVersion> <major>1</major> <minor>0</minor> </specVersion> <URLBase>http://192.168.0.59:6502/</URLBase> <device> <deviceType>urn:schemas-upnp-org:device:Basic:1</deviceType> <friendlyName>Philips hue (192.168.0.59)</friendlyName> <manufacturer>Royal Philips Electronics</manufacturer> <manufacturerURL>http://www.philips.com</manufacturerURL> <modelDescription>Philips hue Personal Wireless Lighting</modelDescription> <modelName>Philips hue bridge 2012</modelName> <modelNumber>1000000000000</modelNumber> <modelURL>http://www.meethue.com</modelURL> <serialNumber>93eadbeef13</serialNumber> <UDN>uuid:00112233-4455-6677-8899-748055d9fb56cc</UDN> <serviceList> <service> <serviceType>(null)</serviceType> <serviceId>(null)</serviceId> <controlURL>(null)</controlURL> <eventSubURL>(null)</eventSubURL> <SCPDURL>(null)</SCPDURL> </service> </serviceList> <presentationURL>index.html</presentationURL> <iconList> <icon> <mimetype>image/png</mimetype> <height>48</height> <width>48</width> <depth>24</depth> <url>hue_logo_0.png</url> </icon> <icon> <mimetype>image/png</mimetype> <height>120</height> <width>120</width> <depth>24</depth> <url>hue_logo_3.png</url> </icon> </iconList> </device> </root>

wernersv · 2020-01-19T13:39:17Z

Das sieht doch gut aus.
Frag mal deinen Echo nach neuen Geräten.
"Davlik" deutet auf Android hin. Du suchst also von der App aus..
Mach die Suche mal vom Rechner aus, auf der Alexa Webseite. Es kann sein, dass die App sich anders verhält. Das hatte ich nicht geprüft.
Echo und Webseite sollten durchkommen.
Für die App kannst du testweise mal das '/lights' am Ende der Regel entfernen und die CCU durchstarten.

jadze65 · 2020-01-19T14:19:03Z

Habe das Gefühl das die Gerätesuche nicht beliebig oft durchgeführt werden kann.
Egal wie ich jetzt suche, es taucht nichts mehr im access.log auf.
Mache jetzt erstmal eine Pause.

Wie ergibt sich der Inhalt der description.xml ?

Muss nach dem Ändern der Firewall Einstellungen die CCU neu gestartet starten ?

wernersv · 2020-01-19T14:34:52Z

Eine Beschränkung der Suche ist mir nicht bekannt. Die FW Änderungen sollten sofort aktiv sein.
Die description.xml muss von der Node kommen. Schau einfach mal in deren Repository. https://github.com/datech/node-red-contrib-amazon-echo/blob/master/api/hue/templates/description.xml

janner2000 · 2020-01-19T14:58:42Z

So bei mir läuft der Node auf Port 6502 einwandfrei konnte auch die description.xml Datei per wget per ssh ziehen.
Wenn ich per Alexa iPhone App Geräte suche versucht er es wie bei @jadze65. Dein Tipp per Website hat auch nicht geholfen, sowie das /lights aus der Portweiterleitung entfernen bringt nicht den Erfolg.

Darauf mal Testweise einen PI mit Node Red eingerichtet und dort läuft die Erkennung einwandfrei, nur um auszuschließen das es an meiner Hardware App oder sonstwelchen Unwägbarkeiten hängt.

Ich tippe es muss was mit den Forward Regeln zu tun haben. Bin aber leider dort nicht so bewandert. Firewall ist nach wie vor aus.

Kann es sein, weil ich das Webui per https:// und selbstsignierten Zertifikat laufen habe das der lighthttp den Port 80 nicht richtig durchreicht????

muellerjm · 2020-01-19T16:51:17Z

jepp, ich habe auch mal testweise pi/NR installiert. Alles funktioniert wunderbar. Ein anderer Rasperrymatic Neuinstallation NR und nur Amazon Echo hingegen schlägt fehl. Firewall kann es nicht sein. Zum Test alles offen wie ein Scheunentor. Evtl. komme ich ja noch dahinter. @wernersv wie troubelshoote ich am besten? Gibts ein best practice?

hobbyquaker · 2020-01-19T16:51:39Z

Muss nach dem Ändern der Firewall Einstellungen die CCU neu gestartet starten ?

Es muss nach dem Update auf die RedMatic Version die die Proxy Konfiguration mitbringt auf jeden Fall der Webserver neugestartet werden. Entweder über /etc/init.d/S50lighttpd restart oder alternativ einfach mittels Reboot.

Ein Eintrag des Ports 6502 in den CCU Firewall Einstellungen ist meines Erachtens überflüssig, die INPUT Chain erlaubt eh alles was vom Loopback kommt.

firewtm · 2020-01-19T19:36:36Z

Liegt es vielleicht daran, dass die /api/description.xml von der Proxyregel nicht erfasst wird? Wird diese über Port 6502 aufgerufen, erscheinen dort die konfigurierten Geräte. Ich habe leider nur Sonos Geräte mit Alexa zu Hause und vermute, dass es auch deshalb bei mir nicht funktioniert. Diese erkennen die Hue-Bridge v1 nicht.

wernersv · 2020-01-19T19:41:41Z

@firewtm, das hat mit den Sonos sicher nichts zu tun.
Die description.xml per Browser testweise auf Port 80 und 6502 aufrufen. Der Abruf über Port 80 erscheint im access.log. Der direkte Zugriff auf 6502 wird wenn überhaupt nur von der Node selbst protokolliert.

Nachtrag:
Die Regel greift bei /description.xml und bei /api/.*/lights.nicht bei /api/description.xml

firewtm · 2020-01-19T20:55:37Z

Manuelle Aufrufe über Port 80 erscheinen in der access.log. Bei der Suche nach neuen Geräten (App/ Browser/ Sprachbefehl) wird weiterhin nichts gefunden/ protokolliert.
Ich hatte aus der Proxyregel das /lights entfernt. Mit api/description.xml wurde mir dann das was hier zusammengebaut wird angezeigt:

https://github.com/datech/node-red-contrib-amazon-echo/blob/master/api/hue/templates/state.json

Zu den Sonosgeräten: Da habe ich schon mal was im Sonosforum zu gefunden. Das funktioniert nur mit der Bridge v2 und zugehörigen Skill. Hier wird ja meines Wissens die Bridge v1 simuliert. „Nicht Amazon“ Alexas haben anscheinend nicht die Funktion im lokalen Netz zu Discovern.
Deshalb wäre es für mich interessant, ob es schon einer außer @wernersv erfolgreich am laufen hat. Dann würde ich mir noch einen Echo Dot zulegen.

jadze65 · 2020-01-21T19:07:21Z

Komme hier nicht weiter.

Wenn ich die Firewall runterfahre sehe ich Einträge im access.log wenn ich eine Gerätessuche über meinen Echot Dot starte. Das gleiche passiert wenn ich das über die App mache.
Ob ich die Proxy Regel drin habe oder nicht, macht keinen Unterschied.
Geräte werden nicht gefunden.

http://192.168.0.59:6502/description.xml liefert immer das gleiche Ergebnis. Warum steht da immer die HUE drin ?

Vielleicht verstehe ich das ganze wenn ich auch mal einen Raspberry aufbaue.

wernersv · 2020-01-21T19:20:08Z

@jadze65, das mit der Hue ist normal. Die Node ist so implementiert. Die simuliert eine Lampe.

jadze65 · 2020-01-21T19:40:29Z

Ok, verstanden.

Ich sehe nur keine Einträge folgender Art:
"GET /api/c6260f982b43a226b5542b967f612ce/lights HTTP/1.1"

Nur

"POST /api HTTP/1.1" 404 9 "-" "Dalvik/2.1.0 (Linux; U; Android 7.1.2; AEODN Build/NS6431)"
"GET /upnp/basic_dev.cgi HTTP/1.1" 200 987 "-" "Dalvik/2.1.0 (Linux; U; Android 5.1.1; AEORK Build/LVY48F)"

wernersv · 2020-01-21T20:09:00Z

404 is the http status code. The page was nor found in this case.

The 200 was successful. From the user agent string you can see these are different clients/apps.

MaStahl84 · 2020-01-21T22:45:25Z

Ich habe einen kleinen Workaround gefunden für den Status Code 404.
d.h. die anfragen von den Echos müssen im access log sichtbar sein.

-Amazon Echo Hub in Redmatic anlegen wie beschrieben und ein Licht anlegen,
-dann in der lighttpd.conf statt "^/api/.*/lights" nur "^/api" eintragen.
-lighttpd neu starten "/etc/init.d/S50lighttpd restart"
-ACHTUNG, Rasperrymatic Oberfläche dann temporär nicht mehr verfügbar.

-Jetzt Alexa über Web suchen lassen.
-Lampen werden jetzt bei mir gefunden.
-Danach wieder in der lighttpd.conf "^/api" durch "^/api/.*/lights" ersetzten.
-lighttpd neu starten "/etc/init.d/S50lighttpd restart"
-Rasperrymatic Oberfläche wieder da.

Weiter Lampen (Nodes) werden jetzt ebenfalls gefunden.

Erklärung:
Alexa benötigt einen Benutzer um auf die Hue-Bridge zuzugreifen.
Dieser ist im Aufruf zu erkennen: "GET /api/c6260f982b43a226b5542b967f612ce/lights HTTP/1.1"

Wenn Alexa das erste mal versucht auf die simulierte Bridge zuzugreifen, gibt es noch keinen Benutzer. Hier greift ein Script direkt in der simulierten Hue-Bridge unter dem Verzeichnis "/api", der einen Benutzer erstellt. Wie wenn man auf der Hue-Bridge den Button drückt.
Da hier nichts gefunden wird, kommt der Fehler 404.
"POST /api HTTP/1.1" 404 9 "-" "Dalvik/2.1.0 (Linux; U; Android 7.1.2; AEODN Build/NS6431)"
Sobald aber einmal der Zugriff auf "/api" (registration.json) erfolgt ist und Alexa einen Benutzer hat, laufen die Anfragen mit dem Benutzer ab. Sodas die Proxy-Regel von @wernersv funktionieren, da diese jetzt passen.

muellerjm · 2020-01-22T13:23:14Z

ja, was denn? Das funktioniert tatsächlich....Danke schön. Am Di., 21. Jan. 2020 um 23:45 Uhr schrieb MaStahl84 < notifications@github.com>:

…

Ich habe einen kleinen Workaround gefunden: -Amazon Ech Hub anlegen wie beschrieben und ein Licht anlegen, -dann in der lighttpd.conf statt "^/api/.*/lights" nur "^/api" eintragen. -ACHTUNG, Rasperrymatic Oberfläche dann temporär nicht mehr verfügbar. -lighttpd neu starten "/etc/init.d/S50lighttpd restart" -Jetzt Alexa über Web suchen lassen. -Lampen werden jetzt bei mir gefunden. -Danach wieder in der lighttpd.conf "^/api/.*/lights" eintragen. Rasperrymatic Oberfläche wieder da. -lighttpd neu starten "/etc/init.d/S50lighttpd restart" Weiter Lampen werden jetzt be mir ebenfalls gefunden — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#305?email_source=notifications&email_token=AJFREXUHAO75BODOQN4LD2DQ653INA5CNFSM4KG6FTZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJRSBLQ#issuecomment-576921774>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJFREXWMD4NWZRVYQ4PCB5DQ653INANCNFSM4KG6FTZQ> .

-- Mit freundlichen Grüßen Joachim Müller

jadze65 · 2020-01-22T17:12:30Z

Wenn ich die Proxy Regel ändere und die Firewall aus mache, findet er mein Gerät.
Danach kann Proxy Regel wieder geändert werden und die Firewall wieder an.

Mit Gerät kann dann im NodeRed gearbeitet werden.

Klasse.

wernersv · 2020-01-22T18:09:02Z

Wenn ich das jetzt richtig verstanden habe, dann ist das folgendermaßen.

Forwarding von "/api/.*"ist für den ersten Aufruf der Node erforderlich. Das führt aber dann dazu, dass die CCU nicht mehr erreichbar ist.
Nach der ersten Suche kann/muss dann die Firewall Regel auf "/api/. */lights/" umgestellt werden.

Das ist alles andere als praktikabel.
Hat @hobbyquaker dazu vielleicht eine Idee?

janner2000 · 2020-01-22T19:21:03Z

Mein Problem ist damit behoben. Funktioniert alles nach der Anleitung von @MaStahl84. Supi Danke

wernersv · 2020-01-22T20:39:25Z

Ich hab mir den Code der Node und zur Hue API mal angeschaut schreibe mal zusammen, was ich bislang verstanden habe.

Alexa kommuniziert mit einer Hue Bridge.
Die Bridge liefert ihre Beschreibung mit der description.xml.
Alexa fragt dann bei /api an und erhält als Antwort einen Benutzernamen für die Kommunikation. Das ist die Zeichenkette nach /api/.

Alexa ruft dann /api/{username} oder auch /api/{username}/lights auf, worauf die Bridge mit einer Liste aller bekannten Geräte antwortet.

Damit hat Alexa dann die Informationen um die Geräte zu steuern oder deren Status abzufragen.

Der Benutzername der Node ist unveränderlich/hard-coded.

Die Proxyregel musste also lauten:
"(/api)|(/api/c6260f982b43a226b5542b967f612ce)|(/api/c6260f982b43a226b5542b967f612ce/lights)"

Das setz natürlich voraus, dass auf der CCU nichts weiter auf /api hört/angewiesen ist.

@hobbyquaker, kannst du das bestätigen?

MaStahl84 · 2020-01-22T21:37:59Z

@wernersv
Genau so habe ich das auch verstanden. Das Problem ist, wie gesagt, die Umleitung von "(/api)". Sobald ich die setzte bekomme ich beim Aufruf der Raspberrymatic nur ein blaues Bild.
Eventuell müsste man bei der Proxy-Regel noch abfragen, welches Gerät die Anfrage startet.
Eventuell kann man hier was rausziehen "Dalvik/2.1.0 (Linux; U; Android 7.1.2; AEODN Build/NS6431".
Nur mal als Idee.

wernersv · 2020-01-22T21:59:27Z

Nee. Der User
Agent String ist ungeeignet. Der unterscheidet sich ja bei jeder Geräteversion, Dot 1/2/3, Browser, App, Sonos und was es sonst noch gibt.

Ein Filter auf die IP des anfragenden Gerätes macht auch keinen Sinn, da es durchaus verschiedene Geräte in einem Netzwerk gibt.

Die einzige nsauberen Möglichkeiten sehe ich in einem externen Reverse Proxy, oder die Aktivierung einer temporären proxy Regel während der Ersteinrichtung. Das ließe sich sicher in der Node implementieren. Dazu müsste die Node die temporäre Proxy config anlegen, dem lighttpd mit dem config reload beauftragen (lighttpd-angel) und hinterher alles wieder zurückdrehen.
Theoretisch zumindest.

MaStahl84 · 2020-01-22T22:21:24Z

das mit der temp. Proxy Regel wäre etwa wie "jetzt den Button drücken".

Wenn ich die Proxyanfragen durchschaue kommt die zusammensetzung "Dalvik/2.1.0 (Linux; U; Android" mit gleichzeitgem Zugriff auf "/api" nur von einem Echo-Gerät bei mir im Netz. Somit würde man evtl. mal die Echo-Geräte abdecken. Wenn ich per App oder Browser die Suche starte, passiert das gleiche.
Aber ist halt nicht ganz so sauber.

joachimmarder · 2020-02-25T19:03:30Z

Das Problem ist, wie gesagt, die Umleitung von "(/api)". Sobald ich die setzte bekomme ich beim Aufruf der Raspberrymatic nur ein blaues Bild.
Eventuell müsste man bei der Proxy-Regel noch abfragen, welches Gerät die Anfrage startet.

Man kann den regulären Ausdruck exakt auf "/api" matchen lassen, dann sollte die Oberfläche weiter funktionieren:

"(^/description.xml)|(^/api$)|(^/api/.*/lights)"

Wenn ich die Proxy Regel ändere und die Firewall aus mache, findet er mein Gerät.

Hat jemand eine Idee, was an der Firewall anders konfiguriert sein müsste? Denn leider sehe ich die Anfragen bei mir nicht im access log.

RobiRob81 · 2020-09-01T15:37:18Z

Konnte das Problem auch lösen, wie von @MaStahl84 beschrieben.
Danke hierfür.

Gibt es generell hierfür eine generelle Lösung?

spnmlr · 2020-10-18T23:19:37Z

Alexa benötigt wie @joachimmarder schrieb, initial ein Request auf '/api'. Anschließend folgt ein Request auf '/api/xxxx'.

vi /usr/local/addons/redmatic/etc/lighttpd.conf
API hinzufügen
"(^/description.xml)|(^/api$)|(^/api/.*/lights)"
Service neu starten
/etc/init.d/S50lighttpd restart

Die Funktionsweise ist mega ungünstig gewählt und könnte in Zukunft zu Problemen führen. Da der Request nur einmalig benötigt wird (zum erstmaligen Einrichten), würde ich dies anschließend wieder entfernen.

Matten-Matten · 2021-05-04T15:08:24Z

Hallo Leute ich habe jetzt ein Subflow gebaut der das umschreiben jetzt automatisch übernimmt und ihn nach 60-120 sec zurück schreibt.

vielleicht kann das jemand nützlicher weise verwenden.

homematic-forum <<<

Gruß
Matten, Matten

hobbyquaker added the ✋help wanted Extra attention is needed label Jan 18, 2020

Sineos mentioned this issue Nov 30, 2020

Manage Palette #440

Open

Einrichtung node-red-contrib-amazon-echo #305

Einrichtung node-red-contrib-amazon-echo #305

Comments

janner2000 commented Jan 15, 2020 • edited

wernersv commented Jan 15, 2020

janner2000 commented Jan 15, 2020

MaStahl84 commented Jan 16, 2020

jadze65 commented Jan 16, 2020

muellerjm commented Jan 17, 2020

marcdo70 commented Jan 17, 2020

wernersv commented Jan 19, 2020

marcdo70 commented Jan 19, 2020 via email • edited by hobbyquaker

jadze65 commented Jan 19, 2020 • edited

wernersv commented Jan 19, 2020 • edited

jadze65 commented Jan 19, 2020 • edited

jadze65 commented Jan 19, 2020 • edited

wernersv commented Jan 19, 2020

jadze65 commented Jan 19, 2020

wernersv commented Jan 19, 2020

janner2000 commented Jan 19, 2020

muellerjm commented Jan 19, 2020

hobbyquaker commented Jan 19, 2020 • edited

firewtm commented Jan 19, 2020

wernersv commented Jan 19, 2020 • edited

firewtm commented Jan 19, 2020

jadze65 commented Jan 21, 2020

wernersv commented Jan 21, 2020

jadze65 commented Jan 21, 2020

wernersv commented Jan 21, 2020

MaStahl84 commented Jan 21, 2020 • edited

muellerjm commented Jan 22, 2020 via email

jadze65 commented Jan 22, 2020

wernersv commented Jan 22, 2020

janner2000 commented Jan 22, 2020

wernersv commented Jan 22, 2020 • edited

MaStahl84 commented Jan 22, 2020

wernersv commented Jan 22, 2020 • edited

MaStahl84 commented Jan 22, 2020

joachimmarder commented Feb 25, 2020

RobiRob81 commented Sep 1, 2020

spnmlr commented Oct 18, 2020

Matten-Matten commented May 4, 2021

janner2000 commented Jan 15, 2020 •

edited

marcdo70 commented Jan 19, 2020 via email •

edited by hobbyquaker

jadze65 commented Jan 19, 2020 •

edited

wernersv commented Jan 19, 2020 •

edited

jadze65 commented Jan 19, 2020 •

edited

jadze65 commented Jan 19, 2020 •

edited

hobbyquaker commented Jan 19, 2020 •

edited

wernersv commented Jan 19, 2020 •

edited

MaStahl84 commented Jan 21, 2020 •

edited

wernersv commented Jan 22, 2020 •

edited

wernersv commented Jan 22, 2020 •

edited