Alexa suddenly started saying "device not responding" - Change to port 80 and search again in Alexa

[Dr-IK]

… Since a couple of days. "device not responding" (Gerät antwortet nicht) . I used always port 8080, ...

Thank you guys, Changed to port 80. Works again

I had to change habridge.service sudo nano /etc/systemd/system/habridge.service and habridge.config sudo nano /home/pi/habridge/data/habridge.config

Originally posted by @mondieumathieu in https://github.com/bwssytems/ha-bridge/issues/1125#issuecomment-528993961

Changing port to 80 this way, deleting devices in Alexa and searching for devices in Alexa again, works fine!

[woodworker50613]

I just noticed that problem and changing it works. The only thing that doesn't work is statuses on the alexa app for those light devices do not work. Any idea how to fix that?

[rsedlmeier]

Can anyone tell why this suddenly happens? I ran it on port 8989 for 1,5 years now w/o any issues. Something must have changed.

At my machine port 80 is used for apache2.

[kr0815]

I have the same problem here

changing it to port 80 is not that easy, because i need 80 for something else

Strange thing: in the alexa web page, i have all devices now twice

• as a philips hue device
• as a lux light device

on my phone / alexa app, i don´t have them twice

any other suggestions than changing to port 80?

[blacktiger333]

same problem for me, machine port 80 is used for apache2. Any other suggestions than changing to port 80?

[scooty2019]

i have the same problem

[dinkybluebug]

I got this working at the beginning of the week and now it’s stopped again. I’m running on port 80 already. Very frustrating.

[quadhammer]

Same problem. Duplicate devices of say, 'computer' ( Dimmable Light) , and 'computer' (Royal Philips Electronics smart device).

Also some device names seem to have been reserved. I used to use 'lights', but it won't show up when discovering anymore, despite the rest of the devices being found. 'Bed Time' seems to be another one.

OK, I seem to have discovered one difference. Most devices with a Unique Id (used for Hue responses) of say: 00:57:68:4E:D3:78CDFCF5-78DEFCE5 show up. However, the ones with just a blank AA: BB: CC: DD: EE: FF-XX don't seem to.

It is not consistent though.

[jcf6288]

I unchecked every box in the Bridge Control tab and it discovered my devices. I am also on Port 80

[doogie-at]

Changing port to 80 solved the problem for me, but hopefully that's only a temporary solution, as I need the port for other services

[dinkybluebug]

I was running on port 80 and it stopped. It’s still on 80. Any ideas on how to get this running again?

[Emmpunkt]

Any News on this? I have the same problem running on port 81. Port 80 is in use. Location Germany, Dot 1 & 2

[joekmd]

Same problem with Alexa not working bec of the change to port 80. In my case I already have apache setup on port 80 for other things, so config'd a reverse proxy and Alexa is working again. This allows for ha-bridge to be on port 8080.

To setup a reverse proxy follow the instructions in the section "Run ha-bridge alongside web server already on port 80" on the ha-bridge site: https://github.com/bwssytems/ha-bridge

(I put together the apache reverse proxy config for ha-bridge back in 2017: https://github.com/bwssytems/ha-bridge/issues/349#issuecomment-271156062)

Good luck!

[doogie-at]

perfect, thank you. I wondered if it would be possible to reroute the API traffic from port 80 to some other, and that's exactly the way. works like a charm for me, let's hope that it will continue to

thanks!

On Sat, 14 Sep 2019 at 13:55, JoeK notifications@github.com wrote:

Same problem with Alexa not working bec of the change to port 80. In my case I already have apache setup on port 80 for other things, so config'd a reverse proxy and Alexa is working again.

To setup a reverse proxy following the instructions in the section "Run ha-bridge alongside web server already on port 80" on the ha-bridge site: https://github.com/bwssytems/ha-bridge

(I put together the apache reverse proxy code for ha-bridge back in 2017: #349 (comment) https://github.com/bwssytems/ha-bridge/issues/349#issuecomment-271156062 )

Good luck!

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/bwssytems/ha-bridge/issues/1133?email_source=notifications&email_token=ACE3MCPK745HR2G7INXNEW3QJTGLRA5CNFSM4IWHMYRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6W2K5Y#issuecomment-531473783, or mute the thread https://github.com/notifications/unsubscribe-auth/ACE3MCK4V6U5TBYCKHQGIY3QJTGLRANCNFSM4IWHMYRA .

[NibblyPig]

Same issue here as of last night.

Is it the webserver port that needs changing to 80 (currently 8081, domoticz is 8080), or the upnp port (current 50000)? I'm running an IIS webserver so changing to 80 will not be so easy. Possibly I can do it in my router though, not sure.

[paulv888]

Thank you guys, it just started happening for me as well and port 80 fixed it for me as well. Had to move it to another VM where port 80 was available, delete all and re-discover.

For me it just started happening after making a bunch of changes. Added a 4K stick and started testing if I was having a TV name conflict. I do notice the devices a suddenly listed as "Royal Philips.." instead of "Philips Hue" before.

[pforrmi]

Changed to Port 80 works for me, too. But now alexa finding the devices doubled. Any suggestions?

[ronluna]

I can confirm that alexa did change something very recently.

Alexa is now discovering devices as "Royal Philips Electronics smart device" and the requests being sent from alexa to ha-bridge are formatted differently.

/api/iMAF3NZTuPfnhnXHaBoU1GbJD1E99SjAOiaRCTOg/lights/8

GET /api/iMAF3NZTuPfnhnXHaBoU1GbJD1E99SjAOiaRCTOg/lights/8 HTTP/1.1" 404 276 "-" "Dalvik/2.1.0 (Linux; U; Android 5.1.1; AEOBC Build/LVY48F)"

[jimirocks]

Facing the same issue, currently can't bind to 80 directly with ha-bridge. Setup nginx location proxy on default server however didn't help :-(. Do you guys have any ideas?

[vco1]

HA-Bridge is running on port 80, but still no luck. Did I miss something?

[NibblyPig]

I set up a reverse proxy in IIS and this did the job. I also contacted amazon via feedback option who said I should use phone/chat support to talk to them. I don't have the patience right now to sit there while they tell me to turn it off and on again though but perhaps someone else does. They did say if I did this the tech team would be looped into the messages though.

[ronluna]

I set up a reverse proxy in IIS and this did the job. I also contacted amazon via feedback option who said I should use phone/chat support to talk to them. I don't have the patience right now to sit there while they tell me to turn it off and on again though but perhaps someone else does. They did say if I did this the tech team would be looped into the messages though.

So @NibblyPig is HA-Bridge working fine with Alexa after you setup the reverse proxy on IIS?

[NibblyPig]

So @NibblyPig is HA-Bridge working fine with Alexa after you setup the reverse proxy on IIS?

Yup. Although all I actually did was realise nothing was working a couple of days ago, googled recent ha-bridge/alexa changes, saw this thread, then set up a reverse proxy on port 80 for /api/ and then deleted all the devices and re-added them. Since it worked I assume that was the fix but I didn't do any kind of testing, perhaps removing the devices & re-adding them alone would have fixed it, I don't know.

[ronluna]

So @NibblyPig is HA-Bridge working fine with Alexa after you setup the reverse proxy on IIS?

Yup. Although all I actually did was realise nothing was working a couple of days ago, googled recent ha-bridge/alexa changes, saw this thread, then set up a reverse proxy on port 80 for /api/ and then deleted all the devices and re-added them. Since it worked I assume that was the fix but I didn't do any kind of testing, perhaps removing the devices & re-adding them alone would have fixed it, I don't know.

That's what I've done. remove all devices and re-discover them. Alexa can find them just fine and they get added but when trying to control any of the devices Alexa says that the device is not responding and when trying to manually control it it says that the device is malfunctioning.

perhaps your alexa has not been upgraded? Seems like this issue is brand new ...

[Emmpunkt]

@ronluna In my case, i had everything doubled. I had to delete the philips hue devices manually and keep the royal philips. The hue devices are not working and give the error you mentioned. But evertime alexa searches again, i have to delete the hue´s.

I had to change to port 80, cause i couldn´t figure out how to do the reverse proxy with nginx...

[ronluna]

you are correct. it's working now

[pforrmi]

@ronluna In my case, i had everything doubled. I had to delete the philips hue devices manually and keep the royal philips. The hue devices are not working and give the error you mentioned. But evertime alexa searches again, i have to delete the hue´s.

I had to change to port 80, cause i couldn´t figure out how to do the reverse proxy with nginx...

Got the same issue...

[gorstj]

Like many in last week major issues with Alexa and HA-Bridge. ("provider having trouble....."

I have noted two issues:

There are two copies of every device - one is "connected via - Hue Bub" when I look at the settings tab of the device in the Alexa app. The other is connected via "Lounge" which happens to be the name of my Harmony Hub. The one which is connected via "lounge" is the device that works.

Sometimes changing No State (Do not update state for device) to false makes a previously not functioning device work. However sometimes this settings reverts back to true.

[gorstj]

There are two copies of every device - one is "connected via - Hue Bub" when I look at the settings tab of the device in the Alexa app. The other is connected via "Lounge" which happens to be the name of my Harmony Hub. The one which is connected via "lounge" is the device that works.

I have deleted all the 'Connected via Hue Hub' duplicated devices and Alexa voice control now works.

Interestingly, if I turn off my Harmony Hub (which is named 'Lounge') then all the devices still work even though they are "connected via Lounge".

I do not know where the "connected via Lounge" is coming from (unless it is referring to one of my Echo Dot v2 which is named Lounge). I have a mixture of V2 dots and Echo v1.

[tuicemen]

It appears the forget all option in the Alexa app doesn't work in all cases. This was my case, as proof I stopped all Bridges from workig and did a forget all then rediscover. Alexa found all devices I had just told the app to forget. This was impossible as HA-Bridge wasn't running. Doing a forget of each device separately in the Alexa app worked. A rediscover with the bridge still shut down found nothing. Restarting the bridge then having alexa discover devices found all my devices. This issue may also be the reason users are seeing devices reported as twice as a forget all doesn't work.

[kosuodhmwa]

Maybe Port 80 will work, but there is a problem if you will bind the alexa webserver port to another (2nd) IP address: https://github.com/bwssytems/ha-bridge/issues/1135

[csek06]

I'm running this on unraid. Unraid utilizes their GUI for port 80 and I don't wish to change that. Is there a known workaround fix?

[NibblyPig]

As mentioned above, a reverse proxy will let you keep running other things on port 80.

[csek06]

As mentioned above, a reverse proxy will let you keep running other things on port 80.

Won't this require the proxy be running on port 80? I refuse to change my unraid GUI port.

[NibblyPig]

Reverse proxy will take incoming HTTP commands to a particular destination and redirect them to another destination. Instructions are on the documentation page, but it targets anything going to http://localhost/api/* and redirects it to http://localhost:8080/api/* (or wherever you're hosting habridge, 8081 in my case since domoticz is 8080). It doesn't interfere with anything else on the webserver provided it doesn't clash with /api

[csek06]

Reverse proxy will take incoming HTTP commands to a particular destination and redirect them to another destination. Instructions are on the documentation page, but it targets anything going to http://localhost/api/* and redirects it to http://localhost:8080/api/* (or wherever you're hosting habridge, 8081 in my case since domoticz is 8080). It doesn't interfere with anything else on the webserver provided it doesn't clash with /api

Based on the above it is listening on port 80. Correct? Thus would require the change of unraid's default GUI port?

[NibblyPig]

I don't know what unraid is but if you run it through whatever webserver you have (or setup a webserver and run it through that) then you should be able to apply a reverse proxy at a higher level.

If you can't do that then you're out of luck.

[dpatelli]

Ran across this open incident while searching for a solution to the same issue with Hue emulator (AlexaBridge) for MH at the beginning of the month. It would seem that just about every emulator was having the same issues during discovery.

I solved the issue by capturing the discovery packets from an offical hue bridge and comparing to what the emulator was sending. Found that the Hue was more fields in the payload and now seems only to want to use port 80. I modified the AlexaBridge emulator to send the same data payload format and now I'm able to use Alexa voice commands again.

For my tests I only had one device enabled. Here is the payload that the official Hue sent: {"1":{"state":{"on": false,"bri": 128,"alert": "select","mode": "homeautomation","reachable": true},"swupdate": {"state": "readytoinstall","lastinstall": null},"type": "Dimmable light","name": "Lamp","modelid": "LWB014","manufacturername": "Philips","productname": "Hue white lamp","capabilities": {"certified": true,"control": {"mindimlevel": 5000,"maxlumen": 840},"streaming": {"renderer": false,"proxy": false}},"config": {"archetype": "classicbulb","function": "functional","direction": "omnidirectional"},"uniqueid": "00:17:88:01:04:00:3d:96-0b","swversion": "1.23.0_r20156","swconfigid": "321D79EA","productid": "Philips-LWB014-1-A19DLv4"}} (This was for a dimmable only light bulb that I purchased with the Hue to allow me to compare the packets)

Hope this helps Dan

[jimirocks]

My issue was empty array in "dimUrl": [] in devices config. I completely removed the key and using reverse proxy to ensure port 80 it works just fine again.

[gohamstergo]

Just received an official stance from Amazon. Basically, they say: suck it, dont care.

"Thanks for contacting Alexa technical support.

We have an update from our technical team regarding the port 80 smart home devices- philips hue bridge are not working,

Our technical team checked and see that this is not an Amazon device and we never advertised that port would be available and the port shouldn't have been open in the first place."

[roybrew]

Well, that is a nice "kaka" response. 

On Wednesday, November 6, 2019, 7:06:07 PM EST, gohamstergo <notifications@github.com> wrote:  

Just received an official stance from Amazon. Basically, they say: suck it, dont care.

"Thanks for contacting Alexa technical support.

We have an update from our technical team regarding the port 80 smart home devices- philips hue bridge are not working,

Our technical team checked and see that this is not an Amazon device and we never advertised that port would be available and the port shouldn't have been open in the first place."

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[Mitchelll010]

It appears the forget all option in the Alexa app doesn't work in all cases. This was my case, as proof I stopped all Bridges from workig and did a forget all then rediscover. Alexa found all devices I had just told the app to forget. This was impossible as HA-Bridge wasn't running. Doing a forget of each device separately in the Alexa app worked. A rediscover with the bridge still shut down found nothing. Restarting the bridge then having alexa discover devices found all my devices. This issue may also be the reason users are seeing devices reported as twice as a forget all doesn't work.

This worked! nice one!

[spencerryan]

It appears the forget all option in the Alexa app doesn't work in all cases. This was my case, as proof I stopped all Bridges from workig and did a forget all then rediscover. Alexa found all devices I had just told the app to forget. This was impossible as HA-Bridge wasn't running. Doing a forget of each device separately in the Alexa app worked. A rediscover with the bridge still shut down found nothing. Restarting the bridge then having alexa discover devices found all my devices. This issue may also be the reason users are seeing devices reported as twice as a forget all doesn't work.

I also can confirm that "forget all" doesn't. Removing them one at a time in the web UI or the app seems fine.

[Zokathra]

Came back to this recently as I reinstalled my webserver and couldn't for the life of my remember how I set up the reverse proxy in IIS. So for me again in the future and others, to set up the reverse proxy in IIS:

• Install the Application Request Routing extension ( https://www.iis.net/downloads/microsoft/application-request-routing )
• Click on your site that's currently using port 80, go to URL Rewrite
• Add an inbound rule, put api/(.*) into the Pattern box
• Put http://localhost:8080/api/{R:1} (for example) into the Rewrite URL: box.
• Test it works by going to localhost/api/test (should display a page of JSON data).

If you add a Request Blocking Rule as well you can prevent public traffic hitting it by locking it down by IP or whatever, if your port 80 is hosted publicly.