search

home-assistant / core

:house_with_garden: Open source home automation that puts local control and privacy first.
https://www.home-assistant.io
Apache License 2.0
73.46k stars 30.69k forks source link

Emulated hue devices not responding #23514

Closed aneisch closed 5 years ago

aneisch commented 5 years ago

Home Assistant release with the issue: 0.92.x

Last working Home Assistant release (if known): 0.91.x

Operating environment (Hass.io/Docker/Windows/etc.): Centos 7 Pip

Component/platform: Emulated Hue

Description of problem: Alexa reports "[device] isn't responding. Please check it's network connection and power supply"

Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):

emulated_hue:

Traceback (if applicable):

Additional information: Logs seem to display that calls to turn off devices are occurring twice, once in domain "homeassistant" and another in domain "switch"

2019-04-28 13:37:49 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event call_service[L]: service_data=entity_id=switch.kitchen_table_light_switch, service=turn_off, domain=homeassistant>
2019-04-28 13:37:49 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event call_service[L]: service_data=entity_id=['switch.kitchen_table_light_switch'], service=turn_off, domain=switch>
happyleavesaoc commented 5 years ago

Same issue. The commands work but Alexa reports that message.

zimens1 commented 5 years ago

Same issue. the commands to turn off or on work, Alexa complains that the device is not responding. turn on.... alexa says not responding, turn off -sometimes she responds okay. nothing changed on my network except for updating to hassio 92.1 - 91.4 was working perfectly. MQTT is run on a separate VM.

thebradleysanders commented 5 years ago

Yes, same issue here, nothing was changed except the update to Home Assistant 0.92 from 0.91.4 removing the devices from Alexa and re discovering did not fix the issue.

thebradleysanders commented 5 years ago

Relevant config entry also seems to be emulated_hue:

thebradleysanders commented 5 years ago

This seems to be related: https://github.com/home-assistant/home-assistant/issues/23435

tanus10 commented 5 years ago

Exactly the same issue here. Rediscovery from Alexa did not help. Since HA 0.92 something seems broken.

aneisch commented 5 years ago

Reverted to 91.1 and the issue has gone away.

aneisch commented 5 years ago

@cgtobi possible your last touch to emulated hue is causing this issue? Paulus also touched but I will refrain from tagging him 😃

cgtobi commented 5 years ago

Can you explain why tagging me is so much better than tagging Paulus?

aneisch commented 5 years ago

Because he is the creator of the project and I'm sure has 9 million things going on. That and your commit was 2nd to last. When you popped in and said "no it doesn't look like any of the changes in my commit could have caused this" I would have have happily tagged him.

Thanks for adding the label!

Petro31 commented 5 years ago

have the same issue. It appears to be intermittent on the switch domain. I have template switches and zwave switches that display this behavior (sometimes, not all the time). It does not occur on light templates or zwave lights. I'm guessing this is linked to brightness on a switch, seeing as switches don't have brightness?

It also appears to only occur on a second command. For example, if I turn on a switch the switch turns on w/o issue. Now going from the on state to any other state, the message will occur. I.E. If i say turn on lights again, the message will occur. If i say turn off lights, the message will occur. The message does not occur when going from off to on at any time.

off -> on : no message on -> on : message on -> off : message off -> off : no message

cgtobi commented 5 years ago

I have no idea how my PR would be related to such an issue. I don't use this component, so I can't really comment on it. Sorry.

aneisch commented 5 years ago

No problem, sorry to be a bother, just trying to figure out who maintains or contributes to this component.

mikesalz commented 5 years ago

I don't use Emulated Hue with Alexa, but I do use it with Logitech Harmony remotes. The last working version was 0.91.4. After that, it stopped working. For reference, here is the issue I submitted: 0.92.0 bug - Emulated Hue no longer working with Logitech Harmony remotes #23435

tanus10 commented 5 years ago

off -> on : no message on -> on : message on -> off : message off -> off : no message

I can confirm Petro31 on this. on->off always results in a complain by Alexa (Device not responding..) off->on works fine, no message.

Mind you that, the lights turn on and off fine. The problem is that Alexa complains. For the time being, I reverted to 0.91.4. No problem.

I also use emulated hue with Logitech Harmony remote. I have assigned a button to a HA script disguised as hue light via emulated hue. My setup worked fine with all versions of HA, including 0.92.x. So, it seems if it's not a switch then it's fine. I, too suspect something is wrong with switch state.

I little worried that since Alexa-Homeassistant integration has a paid solution, Homeassistant Cloud, its free alternative, emulated hue component may receive lesser/lighter/slower attention. Probably me worrying too much.

related issue back in January (unsolved): https://github.com/home-assistant/home-assistant/issues/20250

and a discussion: https://community.home-assistant.io/t/emulated-hue-0-92-1-item-isnt-responding-please-check-network-connection-etc/113650

merlin051 commented 5 years ago

Same issue here, worked fine before upgrade and still exists in 92.2

mikesalz commented 5 years ago

I also use emulated hue with Logitech Harmony remote. I have assigned a button to a HA script disguised as hue light via emulated hue. My setup worked fine with all versions of HA, including 0.92.x. So, it seems if it's not a switch then it's fine. I, too suspect something is wrong with switch state.

@tanus10 In my setup, there is definitely an issue using Logitech Harmony with Emulated Hue lights. I have two separate remotes, which both have multiple buttons that each turn on separate template lights via Emulated Hue. None of them work after HA 0.92. I have tried 0.92.0, 0.92.1, and 0.92.2. It never works. But as soon as I revert back to 0.91.4, everything is perfect.

nirkons commented 5 years ago

off -> on : no message on -> on : message on -> off : message off -> off : no message

I can confirm Petro31 on this. on->off always results in a complain by Alexa (Device not responding..) off->on works fine, no message.

Mind you that, the lights turn on and off fine. The problem is that Alexa complains. For the time being, I reverted to 0.91.4. No problem.

I also use emulated hue with Logitech Harmony remote. I have assigned a button to a HA script disguised as hue light via emulated hue. My setup worked fine with all versions of HA, including 0.92.x. So, it seems if it's not a switch then it's fine. I, too suspect something is wrong with switch state.

I little worried that since Alexa-Homeassistant integration has a paid solution, Homeassistant Cloud, its free alternative, emulated hue component may receive lesser/lighter/slower attention. Probably me worrying too much.

related issue back in January (unsolved):

20250

and a discussion: https://community.home-assistant.io/t/emulated-hue-0-92-1-item-isnt-responding-please-check-network-connection-etc/113650

exact same thing as my issue as well. I hope someone can fix it soon :( how do I revert HassOS to 91.4?

PlaidShirt commented 5 years ago

I'm also having this issue after updating from 0.91.4 to 0.92.2. Alexa commands all function correctly but Alexa reports that the device did not respond about half the time (even though the device did).

wpmjones commented 5 years ago

Just confirming that I also have the same problem. Upgraded to 92 and now Alexa says "Device not responding" even though the device did respond.

point-4ward commented 5 years ago

And me, same symptoms as everyone else.

A chap/chapette on reddit worked out it seems to occur only on things that aren't dimmable, which in my case is everything as I only expose input_booleans and switches.

sbruggeman commented 5 years ago

Same problem here. Running in a docker container. This worked fine up until .91.4. After upgrading to .92.x I experience this problem. Alexa tells me that the device is not responding but the command is always successful. Its difficult to reproduce reliably as it seems to only happen about 25% of the time I ask Alexa to do something.

Reverting back to .91.4 and the behavior goes away. It seems likely the issue was introduced in this PR but I don't understand what is going on there well enough to identify it. (https://github.com/home-assistant/home-assistant/pull/19590)

JeffLIrion commented 5 years ago

Same issue here. As a temporary fix, I'm using the version of hue_api.py from before https://github.com/home-assistant/home-assistant/pull/19590 in a custom component.

point-4ward commented 5 years ago

Presuming that is working for you @JeffLIrion, #19590 does seem to have introduced this - @techfreek , any ideas please?

techfreek commented 5 years ago

I haven't seen this, but I've been looking over my changes and noticed a couple places where I inadvertently changed behavior. https://github.com/home-assistant/home-assistant/pull/19590/commits/2afbcac8cd369391d4e124575c96563237f48aca#diff-cdd50787bea695de272e058d2f1a96e3R420 and https://github.com/home-assistant/home-assistant/pull/19590/commits/2afbcac8cd369391d4e124575c96563237f48aca#diff-cdd50787bea695de272e058d2f1a96e3R421

I'm going to have to think about both of those and see if I missed anything else

JeffLIrion commented 5 years ago

@mf-social yeah, the reverted hue_api.py is working correctly.

Thanks for looking into this, @techfreek!

techfreek commented 5 years ago

I still haven't been able to repro this. I've been trying to write tests all night to repro this. I have a few theories that someone may be able to help me confirm:

point-4ward commented 5 years ago 
I still haven't been able to repro this...

Not trying to teach you to suck eggs, but have you tried exposing an input_boolean for the purpose of testing? And if so, are you saying that your Alexa isn't chirping out the error when you switch it on?

Because that being the case then it reproduces every time for me in that scenario, so hopefully we can work out why it is different between our setups and hopefully that will lead us to the solution 😉

nirkons commented 5 years ago

For me it's the exact opposite, when you tell Alexa to turn on something she complains but when you turn it off she doesn't, this happens with switches (broadlink)

point-4ward commented 5 years ago

That's not the opposite, that's exactly what we're reporting 😉

As stated above it appears to be when you turn on anything that isn't dimmable, such as a switch or an input_boolean.

merlin051 commented 5 years ago

When using hue emulation she turns things on fine the majority of the time.

When turning off she complains the device is not responding but turns it off anyway.

However, it's not every time, if I turn it on and leave it on for a while, when turning it off I get the device not responding message, yet the device actually turns off.

When turning on/off in rapid succession she doesn't complain and works fine.

I'm using a Sonoff (tasmota) with MQTT (mosquito).

Just ran a bunch of on/off commands via Alexa and there was one occasion of her complaining when turning the device on - device still turned on, this is the first time I've encountered this.

Interesting all of the devices show as 'the device is not responding' on the Alexa App.

Hope this helps

nimeyy commented 5 years ago

I mentioned this already on the home assistant forum. The problem seems to be that switches and input_booleans are report as type “Dimmable light”. Also the attributes for brightness, hue and saturation are provided even that they arn’t support. If you instead report “On/Off light” as type and don’t provide the attributes , the error doesn’t occur.

You can give it a try by using this version as custom_components: http://www.mediafire.com/file/adttclvxa4ro2xb/emulated_hue.zip/file

DeviousPenguin commented 5 years ago

I'm also experiencing this issue, no error when devices are turned on, but when I turn them off I get the 'connection error' message from the Echo.

None of my devices are dimmable, I'm only using off and on.

tjedmunds commented 5 years ago

This might be relevant to finding the issue ... something I noticed is that the URL http://hassio:8300/api/pi/lights would return a ‘bri’ (brightness?) value of null for switches that had this problem. And it seemed somewhat sporadic. I have since reverted to 91.4 and brightness never seems to be null in the above response. If Alexa is getting a null back for these devices 'she' probably thinks the command didn't work when in fact it did.

techfreek commented 5 years ago

This might be relevant to finding the issue ... something I noticed is that the URL http://hassio:8300/api/pi/lights would return a ‘bri’ (brightness?) value of null for switches that had this problem. And it seemed somewhat sporadic. I have since reverted to 91.4 and brightness never seems to be null in the above response. If Alexa is getting a null back for these devices 'she' probably thinks the command didn't work when in fact it did.

That's really helpful. I'm looking closely, and if your light domain is in the off_maps_to_on_domains, we might be able to return null here: https://github.com/home-assistant/home-assistant/blob/a55da2955c17717e1b08bd6b207fc2485f7dfcbf/homeassistant/components/emulated_hue/hue_api.py#L456

I don't have an Alexa, and I'm in the process of moving so I can't test more than unit tests, but that might do it. This code https://github.com/home-assistant/home-assistant/blob/a55da2955c17717e1b08bd6b207fc2485f7dfcbf/homeassistant/components/emulated_hue/hue_api.py#L523-L526 probably should also made more robust to make sure it can't return null

tjedmunds commented 5 years ago

The only 2 domains I have in 'off_maps_to_on_domains' are 'script' and 'scene'. Perhaps it's a timing issue where the response is built before HA returns the new brightness state to the component? That might explain the somewhat sporadic behavior but I'm not familiar with HA code. Maybe someday.

parellell commented 5 years ago

I've just tried dedenting the following lines as a workaround for the problem in .92.x because it corrects the None values that seem to result from having undimmable lights exposed (e.g. a light: controlling an on/off switch:)

https://github.com/home-assistant/home-assistant/blob/d4ae73ce38ff2ba79e21507af12a685710936bac/homeassistant/components/emulated_hue/hue_api.py#L502-L513

These were previously only executing when there was a cached state, but after dedenting by 1 level they now run on every call to get_entity_state. This 'fixes' the issue in my case, and may explain why the error didn't occur on every command from Alexa - but it may not be appropriate for all entity types that this component handles, which is why I haven't created a PR. (I'm not that familiar with this code yet!)

tshark on port 8300 also shows more sensible values in the json payload:

0.92.2 unmodified: {"bri": null, "hue": null, "on": true, "reachable": true, "sat": null}

with my change: {"bri": 255, "hue": 0, "on": true, "reachable": true, "sat": 0}

point-4ward commented 5 years ago

I don't use off_maps_to_on in my setup if that changes or reaffirms anything anyone is saying.

parellell commented 5 years ago

I don't use off_maps_to_on in my setup if that changes or reaffirms anything anyone is saying.

Yes that does reaffirm my view, as I also don't use it but I was still affected by the issue. My lights look like this:

light:
  - platform: switch
    name: "Office Light"
    entity_id: switch.office_light
  - platform: switch
    name: "Bedroom Light"
    entity_id: switch.bedroom_light
  - platform: switch
    name: "Lounge Light"
    entity_id: switch.lounge_light

and switches are on/off 433Mhz RF:

- platform: rpi_rf
    gpio: 17
    switches:
      office_light:
        code_on: xxxxxx
        code_off: xxxxxx
        signal_repetitions: 20
happyleavesaoc commented 5 years ago

FWIW, I use

emulated_hue:
  expose_by_default: false
  off_maps_to_on_domains:
    - script

... and scripts are the entities giving me this bug.

mtwheatley commented 5 years ago

Is this bug going to get fixed?

techfreek commented 5 years ago

Based purely on the null in the response, I put this together: https://github.com/techfreek/home-assistant/commit/a1c57b25f79638f6b533e80dd76cccc914f03f86. I'm trying to pack to move, so I can't test this right now, but if this fixes the issue, I'll open a PR.

parellell commented 5 years ago

@techfreek - your a1c57b2 commit applied on top 0.92.2 install fixes the issue for me. No error from Alexa and json looks fine. Thanks!

{"modelid": "HASS123", "name": "Office Light", "state": {"bri": 0, "hue": 0, "on": true, "reachable": true, "sat": 0}, "swversion": "123", "type": "Dimmable light", "uniqueid": "light.office_light"}

MisterWil commented 5 years ago

I can also confirm that applying the a1c57b2 commit from @techfreek on top of 0.92.2 fixed the issue for me.

MisterWil commented 5 years ago

Issue #13296 from March 2018 talks about not reporting switches and non-dimmable lights with a brightness, and PR #18749 was submitted to address it but never pulled in. In the issue they talk about how switches and lights should be reported as different types so as to not include a dimmer option in Alexa.

There is also issue #20250 from January 2019 which is very similar to this issue which could also be closed once this is fixed.

It might be that a proper fix to this issue would be to detect that a light entity doesn't have a brightness attribute and report the type as On/off light. At the same time, we should also return something like the type On/Off plug-in unit if the entity is a switch.

mikenabhan commented 5 years ago

So I want to try to be helpful here. I switched to using the Alexa smart home api via haaska on lambda to try to fix this issue but it doesn’t actually appear to be a problem with emulated hue component. The issue is persisting with haaska and directly with the smarthome api. Is there an underlying issue in the Alexa component?

MisterWil commented 5 years ago

Spent some time messing around with the emulated_hue component today and it seems like Alexa just really doesn't like not having a brightness value, even if the device type is "On/Off light". I don't think there's any getting away from including it.

Kanga-Who commented 5 years ago

I can also confirm that the code changes posted in a1c57b2 fixes the issue.

Can this now be merged and rolled out @techfreek?

techfreek commented 5 years ago

PR #23909 was opened this morning with this fix.

JeffLIrion commented 5 years ago

https://github.com/home-assistant/home-assistant/commit/a1c57b25f79638f6b533e80dd76cccc914f03f86 works for me, too. Thanks, @techfreek!