Skip to content
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

Seems like amazon turned off something ! #106

Closed
MattL0 opened this issue Mar 23, 2020 · 25 comments
Closed

Seems like amazon turned off something ! #106

MattL0 opened this issue Mar 23, 2020 · 25 comments

Comments

@MattL0
Copy link

MattL0 commented Mar 23, 2020

i can't discover new lights anymore. i had 21...and had to redo my setup. Tried repairing but no luck.

the situation seems to be the same on ha-bridge

@Barabba11
Copy link

Have you tried to remove Echo from Alexa account, reset Echo with buttons, import it again in Alexa account and discover again devices?

@jebril76
Copy link

jebril76 commented Mar 25, 2020

Hi and thanks for your effort.

I have the same problem.
Tested iobroker after clean new install on Windows and Ubuntu 19.10 and 18.04 installations.
Reset of Dot v2 brought no solution.
http://localhost/api/description.xml is showing all infos.
Have set DEBUG="node-ssdp:*" as global env at startup. Still no message on Journalctl.

Is it still working? What am i doing wrong?
No new registration possible.
Already registered devices worked fine befor the reset.

Amazon Echo Hub in Node-Red states online (green) and never turns to discovery (yellow) mode.

Thanks, Jebril.

@Barabba11
Copy link

Barabba11 commented Mar 25, 2020

Use wireshark to sniff the traffic, filter by ip address of Echo, try to understand the handshaking between node and echo

@datech
Copy link
Owner

datech commented Mar 27, 2020

This is quite strange. I'm still able to discover and use newly added devices on my Dot v2 and v3.

@mastix
Copy link

mastix commented Mar 28, 2020

Same thing here... no device discovery here. My raspi listens to port 80 (forwarding via iptables). I can connect to it successfully via telnet... But my dot v3 does not find anything.

I've de-registered the device from my account and added it again as new device.

I can also access the /api/description.xml file.

@MattL0
Copy link
Author

MattL0 commented Mar 28, 2020

I was able to find my device again. Don’t know what happened..

I changed my alexa account from canada to usa . Maybe that did help?

@mastix
Copy link

mastix commented Mar 28, 2020

I changed my alexa account from canada to usa . Maybe that did help?

Where did you do that? In the alexa app?

@MattL0
Copy link
Author

MattL0 commented Mar 28, 2020

No , in amazon site itself. Changed my adress to a us one, and switched my devices to us. There are surely some tutorial about this on the web

@jebril76
Copy link

Good to hear that it's working for Matt again. So it's working in general and I must be doing something wrong.

Here is what I did:

  1. I did a fresh install using Ubuntu 18.04.04 LTS doing a minimal netinstall including Openssh.
  2. I installed Iobroker according to the manual on Iobroker.net using node 10.x and user root.
  3. I installed the Alexa2 and Node-red adapters, as well as the Node-red-contrib-amazon-echo palette 0.1.10 and connected the Alexa2 adapter to a new Amazon account in the US.
  4. I reset the Dot v2 and connected it to the new account.
  5. I setup a minimal test flow. The flow connects the Echo hub on port 80 to an Echo device called "bob" which is connected to a debug node. /api/description.xml is working.
  6. No devices found.
  7. I installed tshark to sniff the traffic.
    As long as the Node-Red adapter in Iobroker is running i can see it advertise:
    <IP_of_iobroker> --> 239.255.255.250 SSDP 326 NOTIFY * HTTP/1.1
    <IP_of_iobroker> --> 239.255.255.250 SSDP 336 NOTIFY * HTTP/1.1
    <IP_of_iobroker> --> 239.255.255.250 SSDP 366 NOTIFY * HTTP/1.1
    every 10 seconds.
    Still, whatever I do, there is no sign of my Echo's Ip on the sniffed traffic.
    All that I can find, are some packets that are exchanged with an Amazon Server.
  8. I swapped out my network hardware to make sure there are no filters.
    Still no luck and out of ideas what to do next.

@Barabba11
Copy link

Great post, I hope it helps author to find the issue

@MattL0
Copy link
Author

MattL0 commented Mar 30, 2020

Yes great post ! Thanks

@datech
Copy link
Owner

datech commented Mar 30, 2020

Thanks @jebril76

Can you try the following - #66 (comment)

@jebril76
Copy link

jebril76 commented Mar 30, 2020

@datech Thanks for your effort.

I already tried that. See above.

I had my problems starting node-red as root from the shell (command not found). Thats why i set the debug mode in global env and checked Journalctl, Syslog as well as the Iobroker logs.

If it's helpful i can recreate and post logfiles.
Please let me know if you got any other idea/advice.

One more thing ... im running on a singleboard PC called Udoo x86II. It does not have a wlandevice. So it communicats via Lan (enp2s0). But that should make no difference?
Since it used to work on it for the last 6 month.

Thanks!

@datech
Copy link
Owner

datech commented Mar 30, 2020

It has to work with WiFi and LAN if the SSDP traffic is allowed.

Where did you sniff for the SSDP traffic? On which device? Can you try to sniff on a device which is different from the single-board PC, but still on the same broadcast domain?

So, the node-red-contrib-amazon-echo was working and just stopped to response or what was the event which caused this situation?

@jebril76
Copy link

jebril76 commented Mar 30, 2020

@datech
I managed to reinstall node-red to run it localy from this manual: https://nodered.org/docs/getting-started/local

In the logs (same device) i still can't find my echos ip.
The only thing that looks similar is this:
node-ssdp:server Setting LOCATION header "<iobroker_ip>:80/description.xml" on message ID b54279203766079e +1ms
node-ssdp:server Sending a message to 239.255.255.250:1900 +0ms

If needed i can post the full log.

Thanks for your help.

It used to work on the device. I probably did some updates like node-red-contrib-amazon-echo v0.1.9 to 0.1.10 and other security updates without registering new devices. Next time i tried it wasn't working. Sorry that this isn't helpful.

Will setup a new device (raspi) to sniff the traffic.

@MattL0
Copy link
Author

MattL0 commented Apr 2, 2020

Lot of fun there : bwssytems/ha-bridge#1192

@datech
Copy link
Owner

datech commented Apr 3, 2020

@jebril76 can you try the following #104 (comment)

@jebril76
Copy link

jebril76 commented Apr 5, 2020

Thanks for your help.

I have installed sniffer on a other device. -> Same results.

Reinstalled a raspberry with a ready made image from https://www.iobroker.net/#de/download (Version from 19-11-27)
Installed Alexa2.0, node-red and node-red-contrib-amazon-echo@0.1.9

After all this last thing to try befor giving up is.
Test the whole setup at a friends home.

Thanks a lot for your effort.

@jebril76
Copy link

jebril76 commented Apr 6, 2020

Ok, finally a partial success!

Got it working with the raspberry installation described in my last post.

But only when using WLAN.
Working state: Lan-Cable not connected ifconfig wlan0 up
Not working state: Lan-Cable connected ifconfig wlan0 down
In not working state i still see /apt/description.xml and /description.xml

Hope that helps to find the issue.

@datech
Copy link
Owner

datech commented Apr 6, 2020

@jebril76 Can you also confirm that multicast and UDP traffic on port 1900 are not blocked/filtered by any firewall on non-working interfaces?

It is ok to access /description.xml, which means that the HTTP API is ok. It looks like the issue is only related to the device discovery and SSDP.

@jebril76
Copy link

jebril76 commented Apr 7, 2020

@datech I'm not quiet sure on how to do that.

ifconfig states <up, Broadcast, Running, Multicast> for eth0 and wlan0
iptables -L --> all 3 chains are empty
nmap -sU -p1900 localhost --> 1900/udp open|filtered upnp
nmap -sS -p1900 localhost --> 1900/tcp closed upnp

Anything else i can test for you?

@datech
Copy link
Owner

datech commented Apr 7, 2020

@jebril76

Alexa might not work if you have multiple interfaces assigned to your Pi. It is because by default SSDP and HTTP API are running on 0.0.0.0, which is all available interfaces, and it might confuse Alexa, which is the correct IP.

It looks like an issue on your network setup rather than in the module functionality. So, I believe you have to try to find what is the difference in the configuration of WiFi and Lan interfaces.

@Barabba11
Copy link

Also I?m not suggesting to use WiFi on Raspberry cause it logs all the available networks constantly, means usage of your SD card and shorter life. I've disabled it at all, I don't see any reason if I connect it with cable.
For more infos about how to minimize to zero the writes in SD ask

@jebril76
Copy link

@datech I think you're right. I run IoBroker on an Udoo x86 II. That device used to run without any problems and it has no wifi onboard, so it's not an ip-conflict. I only installed it on a Raspberry to check, if i get the same results as on the Udoo. That was the case, until i configured and enabled Wifi on the raspberry. So i guess it must be some limitation with my network.

What confuses me is, every package that is transmitted into my wlan has to be delivered to my accesspoint via lan. So what ever limitation/filter there is on my lan, it should also apply to the packets delivered via Wifi.

@Barabba11 Thanks for your advice. I just set the raspberry up for testing (using a SSD).

Thanks a lot for your help.

@datech datech closed this as completed Apr 10, 2020
@jebril76
Copy link

jebril76 commented May 10, 2020

@datech, @Barabba11: My problem was indeed within my lan-network. There was a Teg1008 8-Port Switch plugged between my WLan-Accesspoint and the device running Node-Red. This device wasn't able to handle multicasts. So the multicast pakages from the Alexadevices never reached the SmartHome-Device. My simple solution is to bypass that switch when detecting new devices. After detection i plug the switch back in again. Mayby this can help others. Thanks again!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants