Alexa says <device>isn't responding. Please check it's network connection and power supply. But device turns on

[ssd65]

I had to up to 5.3.1RC1 'cos Alexa wan't discovering any devices.
5.3.1RC1 fixed that.

However I am still getting that "isn't responding. Please check it's network connection and power supply" (though the device turns on/off successfully) at random times and for random devices. But like 70% of the time she does this annoying thing and I have to cut in and tell her to shut up. I am running on port 80 in a docker container with the --net=host sw.

I don't understand why things that worked almost perfectly for so many, many years can have so many, many issues recently.

Ohh well, it was a good run. Amazon probably is silently shutting this down.

[bwssytems]

Working still on RC1 and there are some things that need to be worked on.

[magicmil]

Exactly the same problem here for already some month. Also with 5.3.1RC1.
Was working flawlessly some month before.

[ChristianGreiner]

+1 Have the same problem

[ssd65]

Ok, my problem seems to have gone away. I did not make any changes.

Perhaps could have been an update by Amazon?
I'm using echo shows if that helps.

[Home-Control9000]

Same problem here. Only on ON commands. OFF commands no problem. Devices will turn on/off
I have a Amazonj Alexa V3.
ha-bridge-5.3.0

[Home-Control9000]

My problem is solved with this setting in device properties:

On with First Dim (If the device is not on in the ha-bridge state, it will send on instead of the dim.)

On all 'ON' commands set this to 'true'
The 'OFF' where no problem so i didn't change these.

[magicmil]

"On with First Dim ..." = "true" did not solve my problem. I turned it back to false.

For me
"No State (Do not update state for device)" = "false"
solved all problems :-)

[SchmuFoo]

Same Behavior here since a few weeks

"No State [..]" and "On with First Dom [..]" didn't fixed it here

[sanderlv]

Is there any update on this? Maybe someone has found another thing that might help? I have scenes I call via habridge in homeassistant, but they always respond back with " isn't responding, please check it's network connection or power supply". But it always works!

[arnieSkyNet]

I have this often too, always with the same device entry strangely. I've even deleted the device and added it back in, but it always comes back and then, after a few days might disappear for quite some time, and then randomly appear again.

So I've developed a mask algorithm in my brain "Alexa did not just say that"

All humour aside, I would like to know what's causing this.

[sanderlv]

Same mask here, but it keeps being annoying

[RobotNot]

New HA-Bridge user here. Awesome project. I'm experiencing the "isn't responding but works" problem, but only for SOME emulated devices. Here are my observations.

In all cases, I use HA-Bridge 5.4.1 to send a single HTTP CGI call to PowerHome2, which has a local web server (port 81) on the same Win10 PC as HA-Bridge (port 80). Device Name and Target Item are the only fields I populate; all others are at default.

The calls launch PH2 macros, most of which just send a single X10 command to load a preset scene in the legacy lighting system (Lightolier Compose). These typically complete within 2.5 seconds, including sending their completion status back to PH2 which forwards them on to HA-Bridge (green toast in HA-Bridge web interface when using test buttons). Alexa doesn't complain about these, and the state of the emulated devices is properly updated in the Alexa app for Android, too.

Alexa only gives the "isn't responding" complaint for PH2 macros that contain more than one X10 command (for instance, launching multiple scenes in different rooms). She issues this complaint while the macro is still in progress (obviously already responding), before it completes normally. Depending on the macro, these longer sequences can take 5 - 30 seconds to complete before HA-Bridge pops the green toast of success. On the Android side, the Alexa app may display the true on/off state of the emulated device, or it may report "Device is unresponsive". In the latter case, tapping on it in the app will clear the message.

Clearly, Alexa is being impatient on the receipt of ack/status from HA-Bridge for the longer macros. I don't know what her standard timeout period is, or how to override it. Sure, I could break the macros down into multiple shorter ones and perhaps have HA-Bridge call those sequentially, but that's more work on both the back-end PH2 system and in HA-Bridge. I'm hoping to bolt HA-Bridge onto PH2 mostly as-is.

I have tried setting Bridge Devices "No State (Do not update state for device)" = True, but this causes Alexa to complain EVERY time, even for the short one-command macros.

I have also tried adjusting Bridge Control "UPNP Send Delay", but with no change in system behavior.

I have 5 Echos in my system: Spot (2017), Plus (2nd Gen 2018), Dot (3rd Gen 2018), Show5 (1st Gen 2019), Studio (2019)

Is there a way to overcome this problem with a better configuration of the existing tools? Or is it something that might be addressed in a future release of HA-Bridge and/or Alexa?

[sanderlv]

It's all so unclear. and so annoying.

Now trying this a while:

[sanderlv]

Any update? I keep bumping on this topic because I keep getting this messages from Alexa.

[sanderlv]

No update?

[RobotNot]

I worked around the issue on my end by nesting commands to PowerHome.

At the suggestion of the developer of that system, I used a function that takes the original command and submits it to the job execution queue of PH and immediately returns, which completely eliminates any delay of acknowledgement back to Alexa. Problem solved.

[sanderlv]

Good for you! Buy how could this help us?

[RobotNot]

My post on JAN 8, 2024 could help others (as I was helped) by the realization that while while Alexa's very short timeout period is beyond our control and perhaps that of HA-Bridge, a potential solution might be found in optimizing the configuration of the thing that is being controlled. In my case, that thing was PowerHome2, itself a bridge (master controller) for all other IoT in the home. By configuring PH2 to respond immediately back to the calling system (HA-Bridge), HA-Bridge was then able to respond quickly back to Alexa, avoiding her impatient back-sass.

So, for others experiencing this issue that don't already have a good home automation management platform, consider adding one. PH2 has been around for a while, harking from the days before Zigbee, Alexa, and Hue. But to this day, it's far more capable than most others on the market, and is still very affordable.

[sanderlv]

That can't be my issue. I have homeassistant. Only some entities have the issue while others dont...

[RobotNot]

That can't be my issue. I have homeassistant. Only some entities have the issue while others dont...

Carefully read my comment above from MAR 14, 2023. My situation was similar to yours in that only some entities were not responding quickly enough.

I don't have experience with Home Assistant, although I do recognize that it is both very popular and capable. It wouldn't surprise me if it is not as capable as PH2 in certain regards, but I would still look under the covers to see if you can configure the same type of solution that I did.

[ssd65]

I'm currently using homeseer.
So If I tweak the http calls that should fix it?

Alternatively if homeseer doesn't support that, I could fix it by simply adding some sort of "http proxy" between homeseer and the ha-bridge that will help immediately fire back a response?

[RobotNot]

I'm currently using homeseer. So If I tweak the http calls that should fix it?

Alternatively if homeseer doesn't support that, I could fix it by simply adding some sort of "http proxy" between homeseer and the ha-bridge that will help immediately fire back a response?

Perhaps. The key for me was to make sure the success message sent back to HA-Bridge happens very quickly, even though completion of the commands sent from HA-Bridge takes much longer. Good luck!