Ha-bridge: Proof: Current HB-Bridge 5.3.0 has a problem with new Echo Gen. 2 firmware version 644580520, old one 641575220 was working

[jayjupdhig]

In my case, it's a "Echo Dot Gen 2"....

With the previous firmware version 641575220, there wasn't any problems with HA-Bridge Version 5.3.0 (and older ones), the communication between the Echo device and HA-Bridge worked for both smart home device search process AND switching them via voice.

Today i came home and said "Alexa, switch office light" (as always before and in german language)... it didn't worked, the alexa voice told me there is a problem...

In the Amazon Alexa web GUI, i saw my 5 philips hue home automation devices, emulated by ha-bridge, duplicated. 5 of them with the device type from previous Alexa firmware version (="Dimmable light") and 5 of them with the new device type from current Alexa firmware version. (="Royal Philips Electronics intelligentes Gerät" ("intelligentes Gerät" = intelligent device in english))

-> That behavior is the proof that the Echo devices are searching by themself for new (native-supported by Amazon) smart home devices in their subnet. But it does never clean/delete the whole device list before searching - just adding new ones.

After deleting/cleaning all of them (Alexa Web GUI), i started a new smart home device search process. After it was done, there was only 5 devices of the new device type "Royal Philips Electronics intelligentes Gerät" - all other ones with type "Dimmable light" are gone now.

After all that, i remembered that i sent a screenshot of Echo software version and serial numer (devices settings page on Alexa Web GUI) to my chief a few weeks ago - so i compared that old screenshot with the new software.

You can also see that it is the same device - the same serial number is the proof:

Old alexa software version, compatible with HA-Bridge 5.3.0 and some lower versions, is 641575220:

New alexa software version, incompatible with HA-Bridge 5.3.0 and some lower versions, is 644580520:

-> I think this is a full proof for that issue and logs are not helpful in that situation. You can easily reproduce that situation if you have the same software versions as i had.

But if you need some logs, just ask me...

Best regards,
Jan

[jayjupdhig]

I think there is no way (at least not an easy one!!) to make that combination work - but maybe i'm wrong? ;-)

So the problem will be fixed in the next version 5.3.1?

Or is it already fixed in the current HA-Bridge master branch?

[vco1]

@martijintro after reading your update it's not clear to me if you got it working with the new firmware version or not. I assume not, but since you write that a scan found new devices I'm a bit confused. At least for me discovery is not working at all with the latest firmware.

[bwssytems]

@martijintro It seems your scan did find the ha-bridge devices. After that happens, I have no control if the Alexa decides not to call the ha-bridge.

[neonnt]

same issues here since today. devices duplicated, after deleting and new search, all devices are found. but Alexa always told me nearly instantly there is a network issue

[wallyto]

same issue for me on ha 5.3.0. everything was working yesterday. every device fails today. also there is no mass delete in ios. you can mass delete in the web, but they still show in ios, even though i have now stopped the ha bridge. can only delete 1 by 1. amazon has really messed it up this time.

[SelmaUrban]

any home automation software based on hue api has this issue at the moment. you only need to search by new firmware number and will find some forum posts.

[tambnguyen]

Confirmed that this happened to be a few days ago, going from 5.2.2 to 5.3 with no luck.

[neonnt]

Original Hue Bridge 2 works for me like every day with Alexa and Hue Skill

[scholzmichael]

So I had exactly the same problem as @martijintro, all HA Devices shown twice (Phillips... and dimmable light). I deleted all devices and did multiple searches via my echos with multiple results. First all were shown double again, then they were not found at all (Echo Show). Then my Show rebooted by itself. I did another couple of searches via Alexa web app on my windows machine, and the 3rd try was successful, all HA-Bridge devices were back (I did not use the link button in HA-Bridge) only as dimmanble light and working again. This must have been an amazon mess. Seems that they did another change. Hope this helps others as well to get their devices working again...

[jayjupdhig]

" after reading your update it's not clear to me if you got it working with the new firmware version or not. I assume not, but since you write that a scan found new devices I'm a bit confused. At least for me discovery is not working at all with the latest firmware."

New devices they don't work, can't be switched..

[jayjupdhig]

"It seems your scan did find the ha-bridge devices. After that happens, I have no control if the Alexa decides not to call the ha-bridge."

Yes, Alexa is not able to call the ha-bridge anymore!!

[jayjupdhig]

"Original Hue Bridge 2 works for me like every day with Alexa and Hue Skill"

Yes, Amazon looks that the ORIGINAL philips hardware and software is working... other things seems to be irelevent for Amazon...

But why they provide a native hue support, with out a skill, if it's does not work? Original Philis hue users use the skill, sure...

[scholzmichael]

I can clearly state that my HA-Bridge devices were found and are working again for now. So my HA-Bridge was found, btw. running HA-Bridge on port 81...

[jayjupdhig]

"I can clearly state that my HA-Bridge devices were found and are working again for now. So my HA-Bridge was found, btw. running HA-Bridge on port 81..."

Out HA-Bridge was also running on port 81 - no problem for Gen 2 devices with old firmware. Gen 3 devices was never working with port 81, only 80.

[scholzmichael]

no problem for Gen 2 devices with old firmware. Gen 3 devices was never working with port 81, only 80.

Ok, don't have 3rd generation, only 2 echos 1st gen, 3 dots 2nd gen, show 1st gen, and 2 fireHD10 tablets.

[neonnt]

so is there a working Port for someone? HA-Bridge is running on Port 8080 right now

[jayjupdhig]

"HA-Bridge is running on Port 8080 right now"

Version 644580520 works correctly with ha-bridge http port 8080?

[jayjupdhig]

"Ok, don't have 3rd generation"

It's off-topic, just for information

[neonnt]

Port 8080 was working until last week without any issues

[jayjupdhig]

On our system, port 81 was also working until last Alexa update. (With Smart Home Devices name before update: "Dimmale Light")

Question: Does it work now with HA-Bridge http Port 80 and:

• HA-Bridge v5.3.0
• Echo Firmware v644580520 -> which shows the devices newly as "Royal Philips Electronics intelligentes Gerät" and NOT as "Dimmale Light" anymore. (!!)

[jayjupdhig]

_"On our system, port 81 was also working until last Alexa update."_
So version 641575220...

[wallyto]

Yes. Port 80 works! I was setup also on 8080. And switched last night to 80 in the ha configure. Note that you need to verify that on startup, habridge does not get a permission denied error for port 80. I am running on raspberry, so implemented autobind setup to enable it. Now everything is good

[jayjupdhig]

Thank you very much. One question more: What device type is it on your HA-Bridge side? Just a "switch"? (You will see it on "Bridge Devices" page)

[wallyto]

On bridge devices i don.t have it set to any particular device. The filter inputs are blank for me.

[jayjupdhig]

Thank you very much!! :-)

[ds82]

Can confirm that switching to port 80 solved this for me, too (using nginx on port 80 as proxy).

[jayjupdhig]

"Can confirm that switching to port 80 solved this for me, too (using nginx on port 80 as proxy)."

Thank you too!!

"Note that you need to verify that on startup, habridge does not get a permission denied error for port 80"

We never saw that problem, but our problem is that on our port 80 a web gui app is running.

Set up a reverse proxy, that routes the ha-bridge-relevant urls on (e.g.) apache port 80 in background to habridge (whatever which port), seems to be a lil bit complicated. (I don't known which mod_proxy rules i had to configure)

To bypass that problem, we are using a virtual lan adapter ("type macvlan") which acts as a bridge to the physical lan adapter! ;-)

So the virtual lan adapter has it own port 80 with ha-bridge, the phys. lan adpter has its own port with apache.

But be careful with that, you need to ensure that apache will not bind to 0.0.0.0:80, that will result in a conflict because apache want to bind its service port to the virtual lan adapter ip too...

[sub0ne]

Does your Alexa App status change when you change a devices on/off state via browser for e.g.? Does the status change replicate to the app? Somehow, when I close the app, bulb is on, and turn it off via web page. After restarting the app it still says bulb is on and first updates it's status when I change some bulb settings.

[neonnt]

Port 80 is working for me, more or less. sometimes no connection and i had to delete all devices on the web app and also on the iPhone app

[jayjupdhig]

What's the "Alexa App"? Do you mean the software that communicates with HA-Bridge, for using Alexa?

[SelmaUrban]

Amazon Alexa:
https://play.google.com/store/apps/details?id=com.amazon.dee.app

[jayjupdhig]

Oh thx, i always use the web app only..

[jayjupdhig]

With port 80 for gen. 2 devices, it works for me too...

Now i think both device generations (2 & 1, maybe 1 too?) are working with the same ha-bridge config (port 80 etc.) so there are not special configurations required anymore for each device type..

[InRong]

Strangely enough, due to these issues, I deleted my devices, but it would not rediscover them.

I tried v5.3.0 and v5.2.1, neither of them worked. However I reverted to version 4.2.1 as I had it on the pi, and all my devices are back again, and working.... I had been running v5.2.1 when this all started, but grabbed v5.3.0 to try to solve it.

Is there something different in the discovery response between v4 and v5?

Just checked, and for me v5.3.0 does not work, I will have to remain reverted to v4.2.1. This is running on port 80. Before the updates v5.2.1 was working fine although this was on port 8080. I made the switch as I needed to move to a newer pi, and because of the details listed in here.

I have echo dots, one v2 and one v3, so I am not sure which one is being master when I use the app to discover.

[vco1]

@InRong I can't confirm this. Tried with 4.2.1, 4.5.6, and 5.3.0 and with neither version any devices are discovered. That's both through the Alexa app as via the Alexa website.

[SchmuFoo]

"Can confirm that switching to port 80 solved this for me, too (using nginx on port 80 as proxy)."

Thank you too!!

"Note that you need to verify that on startup, habridge does not get a permission denied error for port 80"

We never saw that problem, but our problem is that on our port 80 a web gui app is running.

Set up a reverse proxy, that routes the ha-bridge-relevant urls on (e.g.) apache port 80 in background to habridge (whatever which port), seems to be a lil bit complicated. (I don't known which mod_proxy rules i had to configure)

Falls Ihr ebenfalls den HA-Bridge Port nicht ändern wollt, hier mein Vorgehen was ich eben erarbeitet habe (bevor ich den Thread hier gefunden habe..)

Beim tcpdump sah ich, dass Alexa seit kurzem seine Requests immer an Port 80 und /api schickt aber ein HTTP 404 bekommt. Letzteres zwar richtigerweise da meine HA-Bridge halt auf Port 8080 läuft, aber doof für Alexa .-)

Des Rätzels Lösung um es wieder ans laufen zu bekommen:

In der ..

/etc/apache2/sites-enabled/000-default.conf

.. ProxyPass einbauen..

ProxyPass /api http://localhost:8080/api nocanon
ProxyPassReverse /api http://localhost:8080/api
ProxyRequests Off Allow
EncodedSlashes NoDecode <Proxy http://localhost:8080/api*>
Order deny,allow
Allow from all
</Proxy>

.. und halt die Module auf der Bash laden und den Apache Restarten

a2enmod proxy
a2enmod proxy_http
a2enmod headers

tcpdump -A -s 10240 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)' | egrep --line-buffered "^........(GET |HTTP\/|POST |HEAD )|^[A-Za-
z0-9-]+: " | sed -r 's/^........(GET |HTTP\/|POST |HEAD )/\n\1/g'

[jmar83]

Vielen Dank!!

Dies scheint die bessere Lösung zu sein, als die HA-Bridge an einen separate IP zu binden (2. IP auf dem phys-Adapter, eigener phys. Adapter (bei uns mit VirtualBox einfach eine zweite "eth1" neben "eth0" - grosser Vorteil zu einem 2.. Kabel!! ;-)) oder ein neuer virtueller Netzwerkadpter (Typ "macvlan" oder "macvtap"), der eine "Bridge" macht auf eth0..

Mit solchen Sachen hat die aktuelle HA-Bridge-Version ein Problem. Wenn man deren "Web Server Port" an die 2. IP bindet (statt 0.0.0.0), dann gibt ein Request auf die zweite IP auf http://192.168.168.169/ eine XML-Response zurück wo irgendwo dann wieder die primäre IP (des primären Netzwerk-Adapters) drin steht: https://github.com/bwssytems/ha-bridge/issues/1135

Also mit einer 2. IP an eth0 habe ich es noch nicht versucht, und einen "macvlan"- oder "macvtap"-Adapter kann man nicht einrichten wenn man eine Linux-Guest-VM unter einem VirtualBox-Windows host betreibt... daher war die in VirtualBox zusätzlich hinzugefügte sekundäre Nertwerkkarte eth1 (für VirtualBox-Guests ebenfalls ebenfalls eine Bridge zum phys. Adapter des Virtualisierungs-Host-Systenms wie die primäre eth0) meine bevorzugte Lösung.

Aber eben, der Request auf http://192.168.1.169/description.xml gibt dann letzendlich eine Response mit der eth0-IP zurück UND vielleicht auch mancher Request auf http://192.168.1.169/api... (???)

In dieser Hinsicht ist von mir aus gesehen was buggy - ich frage mich warum sowas NICHT gehen sollte? (Obwohl die Reverse-Proxy-Lösung ganz elegant ist!!)

[jmar83]

Here is it english, translated with deepl, i'm a lil bit tired, im sorry! ;-)

Thank you very much.

This seems to be the better solution than to bind the HA bridge to a separate IP (2nd IP on the phys adapter, your own phys. Adapter (with VirtualBox simply a second "eth1" next to "eth0" - big advantage to a 2nd IP on the phys-Adapter, own phys. Cable!!! ;-)) or a new virtual network adapter (type "macvlan" or "macvtap"), which makes a "bridge" on eth0...

The current HA-Bridge version has a problem with such things. If you bind their "Web Server Port" to the 2nd IP (instead of 0.0.0.0), then a request to the second IP on http://192.168.168.169/ returns an XML response where somewhere then again the primary IP (of the primary network adapter) is in it: #1135

So with a 2nd IP on eth0 I haven't tried it yet, and you can't set up a "macvlan" or "macvtap" adapter when running a Linux guest VM under a VirtualBox Windows host... so the added secondary nertwerk card in VirtualBox was eth1 (for VirtualBox guests it was also a bridge to the phys. Adapter of the virtualization host system like the primary eth0) my preferred solution.

But the request at http://192.168.1.169/description.xml will finally return a response with the eth0-IP AND perhaps some requests at http://192.168.1.169/api... (???)

In this respect, I see what buggy is - I wonder why something like this should NOT work? (Although the reverse proxy solution is quite elegant!!)

Translated with www.DeepL.com/Translator

[bwssytems]

Please use this setting described in the README....

https://github.com/bwssytems/ha-bridge#use-upnp-address-interface

[jayjupdhig]

https://github.com/bwssytems/ha-bridge/issues/1135

[jayjupdhig]

Issue with different alexa software/firmware versions (the thread's original topic) is solved.

[jayjupdhig]

So closed...