-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Einrichtung node-red-contrib-amazon-echo #305
Comments
Der Port 1880 ist offenbar nodered selbst. Funktioniert redmatic ohne die alexa node? |
Funktioniert alles wunderbar. |
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. |
Habe das gleiche Problem wie @janner2000. Aktuelles Redmatic auf ccu3. @wernersv Auf welcher Plattform läuft es bei dir ? |
Hallo, bei mir auch das Gleiche. Keine Chance. Auch nicht nach einer Neuinstallation |
Bei mir auch das gleiche Problem, Port 6502 online aber keine Geräte gefunden |
Meine Firmwareversion: 3.47.22.20191130 (Raspberrymatic)
Wenn bei Port 1880 ein Connection Refused kommt, dann ist node-red nicht gestartet. Im Flow sollte "Amazon Echo Hub" im Status online sein
Hier das error log direkt nach dem reboot:
Portnummer 8183 ist Homematic ReGa und hat nichts mit Redmatic zu tun. Das tritt bei mir auch ohne Redmatic auf. Successful Discover:
Es sind 3 identische Anfragen zu sehen, welche vermutlich von meinen 3 Echo Dot Geräten stammen. Schalte ich die Proxy-Regel aus, so bekommen die Requests einen 404 als Antwort.
|
Ähm, das sind alles böhmische Dörfer für mich.
Habe ich keine Ahnung von, sorry.
LG
Von meinem P30 Pro
|
Hallo, Auch ein Ausschalten der Firewall bringt keine Besserung. Wenn ich das richtig verstehe, wird bei der Alexa Gerätesuche über Port 80 gesucht. Sind die Anfragen immer auf xx/lights ? Kenne mich mit Proxy Regeln nicht aus. |
Mein letzter Kommentar war auch eher für @janner2000 gedacht. Ich versuche es daher nochmal etwas anders zu formulieren. Der Webserver der CCU (lighttpd) läuft auf Port 80. 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. 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. http:///description.xml oder per SSH auf der CCU selbst: http://localhost:6502/description.xml fördert folgendes zu Tage: 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. 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. Steht nix im access.log, dann kommt auch nix an das verarbeitet werden könnte. |
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)" |
http://192.168.0.59:6502/description.xml zeigt mir die Hue Bridge an ???
|
Das sieht doch gut aus. |
Habe das Gefühl das die Gerätesuche nicht beliebig oft durchgeführt werden kann. Wie ergibt sich der Inhalt der description.xml ? Muss nach dem Ändern der Firewall Einstellungen die CCU neu gestartet starten ? |
Eine Beschränkung der Suche ist mir nicht bekannt. Die FW Änderungen sollten sofort aktiv sein. |
So bei mir läuft der Node auf Port 6502 einwandfrei konnte auch die description.xml Datei per wget per ssh ziehen. 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???? |
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? |
Es muss nach dem Update auf die RedMatic Version die die Proxy Konfiguration mitbringt auf jeden Fall der Webserver neugestartet werden. Entweder über 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. |
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. |
@firewtm, das hat mit den Sonos sicher nichts zu tun. Nachtrag: |
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. 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. |
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. 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. |
@jadze65, das mit der Hue ist normal. Die Node ist so implementiert. Die simuliert eine Lampe. |
Ok, verstanden. Ich sehe nur keine Einträge folgender Art: Nur "POST /api HTTP/1.1" 404 9 "-" "Dalvik/2.1.0 (Linux; U; Android 7.1.2; AEODN Build/NS6431)" |
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. |
Ich habe einen kleinen Workaround gefunden für den Status Code 404. -Amazon Echo Hub in Redmatic anlegen wie beschrieben und ein Licht anlegen, -Jetzt Alexa über Web suchen lassen. Weiter Lampen (Nodes) werden jetzt ebenfalls gefunden. Erklärung: 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. |
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
|
Wenn ich die Proxy Regel ändere und die Firewall aus mache, findet er mein Gerät. Mit Gerät kann dann im NodeRed gearbeitet werden. Klasse. |
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. Das ist alles andere als praktikabel. |
Mein Problem ist damit behoben. Funktioniert alles nach der Anleitung von @MaStahl84. Supi Danke |
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. 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: Das setz natürlich voraus, dass auf der CCU nichts weiter auf /api hört/angewiesen ist. @hobbyquaker, kannst du das bestätigen? |
@wernersv |
Nee. Der User 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. |
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. |
Man kann den regulären Ausdruck exakt auf "/api" matchen lassen, dann sollte die Oberfläche weiter funktionieren:
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. |
Konnte das Problem auch lösen, wie von @MaStahl84 beschrieben. Gibt es generell hierfür eine generelle Lösung? |
Alexa benötigt wie @joachimmarder schrieb, initial ein Request auf '/api'. Anschließend folgt ein Request auf '/api/xxxx'.
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. |
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ß |
@wernersv
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
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
The text was updated successfully, but these errors were encountered: