Echo <-> HS Bridge ohne zusätzlichen Internettraffic

[Hotstepper13]

Grüß euch,

wie habt ihr eigentlich das Thema mit den Port 1900 auf der Synology DiskStation mit Docker gelöst? Kann den Port nirgends deaktivieren, darum findet meine Echo die Bridge leider nicht. :/

Schöne Grüße, Christian

Sorry, da kann ich dir leider nicht helfen da ich die Bridge auf einem kleinen raspberry pi betreibe. Da läuft noch ein Raspbian drauf und die Anwendung ist "nativ" also ohne docker oder so installiert. Funktioniert ziemlich reibungslos.

[boardman]

Die description.xml hast du per pn...

>Alle Echo DoT´s die ich so im Haus haben ignorieren die bridge. Ich habe ein Echo Update in verdacht das irgendwann mal durchkam.
na das passt ja - ich kann dir auch sagen wann .. hab ja nur das Echo dat gehabt das über Nacht im September den Dienst eingestellt ghatte...
Nun hab ich noch ein Studio - aber verhälts ich analog...

Würde ja darauf hindeuten dass dei description.xml nicht mehr passend ist.? und es deswegen danach nicht weiter geht....

in der IOS App - wenn ich auf Phillips HUE klicke kann ich nur "Geräte" Suchen" es kommt weder die Frage nach BT noch kann ich die Version wählen... ist das bei dir im Android?

[boardman]

Ich habe gerade mal mit dem Phillips HUE Discover probiert, da sehe ich dass der dann auf Port 80 des Routers weiter zugreifen will - kann das sein dass hier mittlerweile auch was auf Port 80 läuft? der ist auf dem Raspi anderweitig belegt... ich muss doch mal Wireshark rausholen

[Hotstepper13]

Ich habe gerade mal mit dem Phillips HUE Discover probiert, da sehe ich dass der dann auf Port 80 des Routers weiter zugreifen will - kann das sein dass hier mittlerweile auch was auf Port 80 läuft? der ist auf dem Raspi anderweitig belegt... ich muss doch mal Wireshark rausholen

Ja, die Hue Bridge läuft per default auf port 80.

Der gesamte prozess läuft aber anders. Als erstes kommt ein UDP Broadcast mit der Suchanfrage, dann antwortet die Bridge an den Fragesteller und übermittelt die Adresse für die description.xml. Sobald die abgerufen wird läuft der Rest auch. Wie schon per PM mitgeteilt habe ich einen potentiellen BUG gefunden und mittlerweile auch gefixt. Das discovery läuft bei mir mit einem Generation 1 Echo wunderbar. Eben war das ding fehlerhaft und die DOTs haben das versucht, mit denen hat es nicht geklappt (weiß der Teufel warum).

Ich versuche gerade ein neues Release zu erzeugen, kämpfe aber ein wenig mit Travis.

[boardman]

damit es nicht verloren geht:
https://forum.fhem.de/index.php/topi...html#msg889455

[boardman]

und das hier verweist auf Port 80
https://www.loxforum.com/forum/germa...439#post214439

[boardman]

so hier steht es mal schwarz auf weiß -Port 80 - könntest du das eventuell umbauen?
https://forum.iobroker.net/post/344226


Hallo, Amazon horcht mittlerweile nur noch auf Port 80 nach neuen Geräten. Die restlichen Informationen sind, so doof wie es klingt in der "Anleitung" des Programmierers für den Node den du benutzt:
https://github.com/datech/node-red-contrib-amazon-echo/wiki/Troubleshooting
Wahrscheinlich läuft bei dir etwas schon auf Port 80, weswegen dieser hier nicht genutzt werden kann. Kannst du denn einen anderen Port nehmen? Startet dann der Node? Falls ja, würde ich dann einfach die Iptable umbiegen wie hier genannt:

	sudo iptables -I INPUT 1 -p tcp --dport 80 -j ACCEPT
	sudo iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8090
	sudo /etc/init.d/iptables-persistent save
	sudo /etc/init.d/iptables-persistent reload

Die Befehle müssen bei dir nicht zwangsweise funktionieren. Das kommt auf deine Distribution an. In diesem Beispiel musst du dann im Node den Port 8090 eintragen.

[Hotstepper13]

Port 80 braucht root rechte um gebunden zu werden.

Wenn ich den code richtig im Kopf habe, kannst du den Port in der Konfiguration selbst anpassen:

"bridgeConfig": {
  "ip": "10.18.96.34",
  "port": 80
},

Die ip natürlich noch ersetzen. Dann muss ich schauen wie man mit supervisor eine anwendung als root laufen lassen kann.
Dann brauchste auch nix mit iptables oder so zu machen.

Auf einem Raspberry der nur intern erreichbar ist, sollte das kein Problem sein.

Hier ist ne anleitung wie man mit supervisor prozesse als root starten kann -> https://serverfault.com/questions/86...rocess-as-root

[boardman]

habs erst mal mit sudo als root getestet... leider kein Erfolg...
kann es sein des Port 50000 auch nicht mehr passt?

08:54:17.158 [Thread-1] DEBUG c.h.alexa.network.upnp.UpnpServer - Found potential Alexa Discovery Request
08:54:17.158 [Thread-1] INFO c.h.alexa.network.upnp.UpnpServer - DiscoveryResponse needed for 192.168.11.60:50000
08:54:17.163 [Thread-1] DEBUG c.h.alexa.network.UDPSender - Initialized UDP Sender with address 192.168.11.60 and port 50000
08:54:17.163 [Thread-1] DEBUG c.h.alexa.network.UDPSender - Prepare to send message. iaddress: 192.168.11.60
08:54:17.164 [Thread-1] DEBUG c.h.alexa.network.UDPSender - Send packet to 192.168.11.60:50000: HTTP/1.1 200 OK
HOST: 239.255.255.250:1900
CACHE-CONTROL: max-age=100
EXT:
LOCATION: http://192.168.11.2:80/description.xml
SERVER: Linux/3.14.0 UPnP/1.0 IpBridge/1.15.0
hue-bridgeid: B827EBFFFEBC51BC
ST: upnp:rootdevice
USN: uuid:2f402f80-da50-11e1-9b23-b827ebbc51bc::upnp:rootdevice


08:54:17.165 [Thread-1] DEBUG c.h.alexa.network.UDPSender - Prepare to send message. iaddress: 192.168.11.60
08:54:17.166 [Thread-1] DEBUG c.h.alexa.network.UDPSender - Send packet to 192.168.11.60:50000: HTTP/1.1 200 OK
HOST: 239.255.255.250:1900
CACHE-CONTROL: max-age=100
EXT:
LOCATION: http://192.168.11.2:80/description.xml
SERVER: Linux/3.14.0 UPnP/1.0 IpBridge/1.15.0
hue-bridgeid: B827EBFFFEBC51BC
ST: uuid:2f402f80-da50-11e1-9b23-b827ebbc51bc
USN: uuid:2f402f80-da50-11e1-9b23-b827ebbc51bc


08:54:17.167 [Thread-1] DEBUG c.h.alexa.network.UDPSender - Prepare to send message. iaddress: 192.168.11.60
08:54:17.167 [Thread-1] DEBUG c.h.alexa.network.UDPSender - Send packet to 192.168.11.60:50000: HTTP/1.1 200 OK
HOST: 239.255.255.250:1900
CACHE-CONTROL: max-age=100
EXT:
LOCATION: http://192.168.11.2:80/description.xml
SERVER: Linux/3.14.0 UPnP/1.0 IpBridge/1.15.0
hue-bridgeid: B827EBFFFEBC51BC
ST: urn:schemas-upnp-org:device:basic:1
USN: uuid:2f402f80-da50-11e1-9b23-b827ebbc51bc

[Hotstepper13]

Der port 50000 ist der port von dem die anfrage erhalten wurde. Das ist eigentlichen upnp standard. Du hatest noch irgendwas von der länge der bridgeid geschrieben, vielleicht ist da noch was drin.

[boardman]

veraaltet

[boardman]

SOOOO!!!
es geht doch Node Red hat es hinbekommen...
lies das mal bitte bei Gelegenheit durch - ich versteh nicht alles insbesondere der Verweia aufs SSDP eventuell ist hier noch ein Bug drin?
die Dot bis V3 sollten zumindest alle gehen - vielleicht kannst du es ja bei dir nachstellen?
https://github.com/datech/node-red-c...roubleshooting
https://github.com/datech/node-red-c...echo/issues/89
https://github.com/datech/node-red-c...cho/issues/104
https://github.com/datech/node-red-c...echo/issues/66 - SSDP
https://github.com/datech/node-red-c...-echo/issues/5

Hab nun ne Proxi Lösung auch da geht es nicht auf die beiden Webseiten komme ich drauf ohne Problem - schein für mich was beim Broadcast/Handshake zu sein?

[Hotstepper13]

Ich hab mich heute auch nochmal hingesetzt und geschaut. Ich musste die API ein wenig umbauen aber ich habe es hier nun mit meinem Echo DOT am laufen.
Ich denke ich baue heute noch ein neues Release, muss den code noch ein wenig aufräumen und habe noch eine Herausforderung mit Sonderzeichen in den Device Namen.

[boardman]

.

[boardman]

.