Emulated Hue Alexa still responds "Sorry <device> appears to be malfunctioning" 0.103.0

[theres-something-wrong]

Home Assistant release with the issue: 0.103.0

Last working Home Assistant release (if known):

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

Integration: emulated hue

**Description of problem: I've been patiently waiting for this fix since emulated hue broke weeks ago. Yes, I changed it to port 80 long ago, that works fine and has been for a while now, Alexa app or web app can discover devices, that's not the problem, and yes the devices actually function, so that's not my problem. Just to make this clear. The problem is: Alexa responds with "Sorry appears to be malfunctioning" even though the requested action for the device is executed.
This only happens on SOME devices. I have other identical devices for which I won't receive the error message and instead here the confirmation chime as expected. I can't figure this out. I followed this process: Stopped my HA docker Deleted the emulated_hue_ids.json HARD/Factory reset the Echo Dot (V2). Forgot all devices from the Alexa browser based app (Forget All). Used the Alexa mobile app to reconnect my Echo Dot to my Wifi. Started HA docker, latest version 0.103.0 Using the Alexa browser based app I discovered devices, they were all found. Commanding Alexa to turn lights on/off: Dining room lights function but I get an error message. Kitchen lights function but I get a confirmation message (bing or whatever the chime noise is) These are the same GE Z-wave in-wall dimmers. Trying a third one I have I got the error message either turning on or off and the confirmation doing the opposite.

I'm sure I'm missing something because everybody says it's fixed..??

**

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

#  type: alexa
  host_ip: 192.168.xx.xx
  listen_port: 80

Traceback (if applicable):

Additional information:

[probot-home-assistant[bot]]

Hey there @NobleKangaroo, mind taking a look at this issue as its been labeled with a integration (emulated_hue) you are listed as a codeowner for? Thanks!

[JeffLIrion]

I have this issue, too. It was working for me before I upgraded, so now I'm using the 0.102.3 version of this integration as a custom component and it's working fine once again.

[theres-something-wrong]

FWIW I was previously using @NobleKangaroo 's pre-release overhauled emulated hue as a custom component before I upgraded to 0.103.0. Unfortunately that didn't work for me either, I experienced the behavior I stated above even then. I had hoped some more fixes had been implemented for 0.103.0 so I gave it a try and was disappointed it didn't fix it. I did confirm that I removed the custom components folder before updating to 0.103.0 so I should be running on the production emulated hue integration now. Point being that using the pre-release integration as a custom component didn't work for me, nor does 0.103.0. To reiterate, for me: didn't work = error message from Alexa. The devices do react to commands and I can obviously I can discover them.

[BenWoodford]

Also getting this, switches react fine but Alexa thinks they're malfunctioning

[NobleKangaroo]

Thanks @theres-something-wrong, @JeffLIrion, and @BenWoodford for reporting this. Currently my Home Assistant and other home lab stuff are offline as I'm in the process of moving but after the holidays, I'll have my full setup back together again. I still have access to my development environment for code changes once we figure out a solution to this, and can definitely push a PR as soon as we do.

For the time being, I'm going to set up a minimal instance of Home Assistant on a RPI4 to try and replicate this and figure out what's going on because in all of my testing prior to finalizing my PR (#28317) I wasn't able to identify any issues with any of the devices I used to test, which included 4 differently-configured LIFX bulbs (one on/off light, one dimmable light, one color light, and one extended color light) and several MQTT devices flashed to Tasmota (several dual-outlet wall plugs, a few Sonoffs, and an ESP8266).

If any of you could share with me the specifics of which types or brands of devices are not functioning properly, perhaps it would help to find a common denominator. I'd be more than willing to pick up a device or two to make sure I'm covering my bases on this, but I need to know what types of devices, what they're named (in case the ID generation might be an issue), and how they're configured, to begin to figure out what's not working and why. Thank you!  

Happy Holidays,

NobleKangaroo

[BenWoodford]

Ah, it seems to be limited just to my WOL switches now, specifically when I turn them off.

So for me it may just be that because curl throws errors when I suspend a PC for some unbeknown reason, it's causing problems, maybe time-out related, idk.

Ignore me for now, all is well

EDIT: Actually maybe that's a separate issue then? curl returns fine, but does Emulated Hue not like running a shell_command? Or maybe it needs things to return very specifically? After testing, it's basically an instant return so shouldn't really be complaining about timeouts.

EDIT2: curl outputs to stderr for some odd reason, which is why it was being detected as a failure. Using -s -S fixed this.

EDIT3: Alexa doesn't like wake on lan if the PC is off, if you try to wake an already woken up PC it's absolutely fine and will do an "OK", but if you wake a sleeping PC it says it's malfunctioning. Possibly because it immediately tries to get an updated state from HASS which will hang trying to ping or something like that? Hard to say. Not sure if this is strictly an Emulated Hue error, but HASS has no error output for it.

[xernaj]

I found this happening on a template switch (which has a required state) but not a template light (optional state). Both report as a "On/off light" type.

# this template switch on emulated_hue will work but cause alexa to say "sorry <device> appears to be malfunctioning"
# switch:
#   - platform: template
#     switches:
#       downstairs_vacuum:
#         value_template: "{{ not is_state('vacuum.xiaomi_vacuum_cleaner', 'docked') }}"
#         turn_on:
#           service: vacuum.start
#           data:
#             entity_id: vacuum.xiaomi_vacuum_cleaner
#         turn_off:
#           service: vacuum.return_to_base
#           data:
#             entity_id: vacuum.xiaomi_vacuum_cleaner
# excerpt of api/pi/lights:
# "13": {
#   "manufacturername": "Home Assistant",
#   "modelid": "HASS321",
#   "name": "downstairs_vacuum",
#   "state": {
#     "mode": "homeautomation",
#     "on": false,
#     "reachable": true
#   },
#   "swversion": "123",
#   "type": "On/off light",
#   "uniqueid": "00:8c:7f:1e:8a:9a:ed:27-9e"
# },

# this template light seems to work ok, after turn on, alexa will respond "ok"
light:
  - platform: template
    lights:
      downstairs_vacuum:
        friendly_name: "Downstairs vacuum"
        turn_on:
          service: vacuum.start
          data:
            entity_id: vacuum.xiaomi_vacuum_cleaner
        turn_off:
          service: vacuum.return_to_base
          data:
            entity_id: vacuum.xiaomi_vacuum_cleaner
# excerpt of api/pi/lights:
# "10": {
#   "manufacturername": "Home Assistant",
#   "modelid": "HASS321",
#   "name": "Downstairs vacuum",
#   "state": {
#     "mode": "homeautomation",
#     "on": false,
#     "reachable": true
#   },
#   "swversion": "123",
#   "type": "On/off light",
#   "uniqueid": "00:cd:40:df:9d:c4:f0:dc-9a"
# },

[JeffLIrion]

I noticed it with my living room lights, which are Broadlink switches. I didn't dig into what other devices were affected.

- platform: broadlink
  host: !secret broadlink_ip_address
  mac: !secret broadlink_mac_address
  timeout: 15
  switches:
    living_room_light1:
      friendly_name: 'Living Room Light 1'
        command_on: 'something'
        command_off: 'something else'

[theres-something-wrong]

I have a few devices all with problems and they seem intermittent, however after some probing I suspect a timing issue with dimmable devices, read the last paragraph below.

Here is what I have:

Dimmers

4x GE in-wall Z-wave dimmers, all the same model. for one of them Alexa was consistently responding just fine this morning, for both on and off. For the other three, I got the malfunctioning response for on/off/ or a dim command. Then I went back to the first one and started getting the malfunction response but only for off and dim commands, it still seems to be OK for the on command regardless of the path I take to get there- this means turning it off manually and turn it on with Alexa or vice versa. More on this below...

I also have a GE plug-in lamp Z-wave dimmer. It worked fine a few times then I got the malfunction response for on/off/dim after trying again a few minutes later.

Fan

GE in-wall Z-wave ceiling fan control: Malfunction response no matter what.

Switches

I have two GE in-wall Z-wave switches. They seem to consistently work fine when trying them a few times over the course of 15 minutes, but I don't command them with Alexa very often.

I have a Etekcity wifi plug-in switch that I command over MQTT. This is actually nested in a group and I expose the group to emulated hue to command it by the group name. It seems to work fine.

I have a GE plug-in Z-wave switch, it too is in a group that I command by the group name, but I also expose the device itself. Commanding by either name from Alexa works fine.

Groups Groups with switches seem to work fine. A group I have called "All Lights" that includes dimmed switches receives malfunction response for off but not for ON... weird.

While testing these today I noticed a trend with the dimmers: for my kitchen lights (GE in-wall Z-Wave dimmer): I get malfunctioning for on/off/dim... However, one time I turned it on then dimmed it down to something really low manually with the switch itself, then commanded Alexa to turn it off...I received the OK response. I tried this with all the other dimmers and got the same reaction.. So I experimented by increasing the dimmer setting brightness slightly and trying again and was able to repeatedly get an "OK" from Alexa for the turn-off request until I hit a threshold brightness. So this leads me to believe there is a timing/updating issue between Alexa and HA while the light is changing dim state, here's why: My dimmers do a fade-to-off thing that takes some time to complete. I suspect that if they have to fade off from a higher brightness setting, which takes longer to achieve "off", there must be some delay in reporting the state back to HA and then on to Alexa, and in this case there is no response before some timeout so she reports "malfunction"?

Testing this theory, it should work in the opposite direction, i.e. turn on to a low dim settings. Well, not quite. The dimmers behave differently when turning on (previous setting), there isn't really a fade on, instead they just turn on instantly to the previous dim setting. Due to this I would think ON wouldn't be a problem. However, no matter what I still get the malfunction response for ON even if they turn on to a previously set low dim setting. Hmmmm. I think there is something else occurring in this scenario though: I've noticed that when I command a dimmer ON from Alexa, it turns on to the previous dim setting, then immediately steps up to 100%. So I think that 2nd step puts the dimmer in a transient state while Alexa is trying to get a response from HA? I don't recall it doing this 2nd step in the past, is this some expected result with the latest emulated_hue?

The only hole I have with this theory is that one of my in-wall dimmer switches will sometimes receive on OK response for off, regardless of dim state and also ON.

[theres-something-wrong]

Ok, I have had some luck with tweaking the Z-wave dim steps and dim step rate parameters on the HA Z-wave Node Config Options section of the Z-wave configuration page. I reduced the Z-Wave Command Dim Rate to 1 from 3, this is 10ms/step instead of the default 30ms/step. I've also increased Z-Wave Command Dim Step to 10 from 1. I suppose this means 10% per step instead of 1%, it's a scale of 1-99.

This makes the fade-to-off occur MUCH faster and I now always get an OK response from Alexa when turning off, regardless of the dim setting. However, I'm getting mixed results with dim commands, either dim from off or dim while already on. I'm also getting mixed results from ON commands. It's still doing the 2-step thing: on to previous setting then full-on.

Another problem: According to this: https://ezzwave.com/support/advanced-configuration the fan control doesn't have these parameters to adjust, however the HA Z-wave config UI presents them. If I change them, save them, then refresh, they just come back as zero, settings don't stick. Makes sense if the device doesn't support it though. Yet another problem: the plug-in dimmer is supposed to have those parameters (according to the link above) but they aren't presented in the HA Z-Wave config UI for that node.

So neither my fan or the plug-in dimmer are behaving properly. Nor are the in wall dimmers 100% of the time, but the results seem a little better.

[DaveTiff]

Hi I also have this problem, it used be for all devices but now I have upgraded to 0.103 it is only on a TP Link 110 which is a dimmable lamp. If I ask Alexa to turn lamp “Off”, the lamp command is activated with an OK message. If I ask Alexa to turn lamp “On” or to set at “20%”, the lamp command is activated but with a “Appears to be malfunctioning” message

[mamekid]

If I ask Alexa to turn lamp “Off”, the lamp command is activated with an OK message. If I ask Alexa to turn lamp “On” or to set at “20%”, the lamp command is activated but with a “Appears to be malfunctioning” message

Same problem as I got, I have also noticed that the light will not turn back on at its last dim state. I run fibaro z-wave dimmer modules connect to a HC2 Hub

[crag-r]

Also having this problem specifically on two things, Wake On Lan and RPC Shutdown Both work fine, but come back with sorry appears to be malfunctioning.

Running Emulated Hue on Port 80, only happened after updating to 0.103 from 0.102.X and having to clear out the json file then rediscover on the Alexa app.

Like one of the other posters, if I try to WOL the device whilst the device is on, I get an "OK" from Alexa so it is like it's trying to query the emulated hue for some response before the device has actually either turned on.

Code below if it helps, just standard WOL and Hassio's RPC shutdown addon

  - platform: wake_on_lan
    name: "Gaming Computer"
    mac: "74-D4-35-XX-XX-XX"
    host: 172.16.X.XX
    turn_off:
        service: hassio.addon_stdin
        data:
            addon: core_rpc_shutdown
            input: "gamingcomputer"

[irltankman]

I am experiencing this also on hass.io running 0.103.5. I am receiving the "sorry, the -DEVICE NAME- appears to be malfunctioning" error on from Echo dot's for all my devices (for switching on the device, no error when switching off the device). I have a mixture of Sonoff's and Broadlink TC2's that I am trying to control. Note: This is a huge step forward from a few weeks ago when I was unable to turn anything on, so thanks @NobleKangaroo for the fix!

[J-Hurtta]

I'm having the same issues. I'm using emulated_hue to execute Home Assistant scripts. These scripts control Philips Hue lights and one Home Assistant switch.

The scripts can be found from Alexa app and I have successfully added them. They also work correctly when executed by my Echo Dot, but Alexa still states that "Sorry, script name appears to be malfunctioning."

[crag-r]

Hi, doesn't seem to have worked for me - still getting the same device appears to be malfunctioning running 105.1.

Forgot and re-added in the Alexa app.

Any ideas?

[sakara]

Same problem here! I have a Philips Hue LightStrip and few OSRAM Smart+ zigbee E27 Bulbs and alexa repeats "device appears to be malfunctioning" every time i ask her something. I'm on 105.3.

[DaveTiff]

Mine is now working ok, no errors, Using TP-Link 110 running HA Core 0.104.3

Can adjust the brightness and turn on & off with no errors from Alexa

Re Dave

[sakara]

Mine is now working ok, no errors, Using TP-Link 110 running HA Core 0.104.3

Can adjust the brightness and turn on & off with no errors from Alexa

Re Dave

Have you changed anything in the configuration or elsewhere?

[J-Hurtta]

I'm having the same issues. I'm using emulated_hue to execute Home Assistant scripts. These scripts control Philips Hue lights and one Home Assistant switch.

The scripts can be found from Alexa app and I have successfully added them. They also work correctly when executed by my Echo Dot, but Alexa still states that "Sorry, script name appears to be malfunctioning."

I still have these exact issues with 0.105.3.

[DaveTiff]

Dont think so, I did make some changes with the Emulated Hue by adding

`emulated_hue: host_ip: 192.168.x.xx listen_port: 80 expose_by_default: false

exposed_domains:

• light

• switch

  entities: light.test_bulb: name: "Passage Light" hidden: false`

But I think it started working after one of the updates

[theres-something-wrong]

105.2

The lights are working pretty consistently (dimmable an non dimmable), although I just had one "appears to be malfunctioning" issue when turning on a dimmable the other day. My LG TV, configured as a media player, always responds with "atbm" either on or off. A group of lights also provides the same response.

So this doesn't seem to be fixed.

Also, as a tip: When using the Alexa web-based smart device discovery tool: "forget all" does not work correclty. When you re-discover you'll have many duplicate devices. You must instead individually forget each device, then re-discover to avoid this. This has probably been documented elsewhere.

[BenWoodford]

Suggestion: it seems to specifically be an issue on slow-acting devices, or ones that throw a warning/error unnecessarily. Maybe we could get an option such as emulated_hue_ignore_errors to assume all is fine?

[ol3k]

same here, still problems with latest version

Home Assistant 0.108.1

[Siytek]

+1 happens with all of my lights (Tasmota flashed)

[joogps]

Same here too. Devices are working and responding fine, but Alexa still announces they are malfunctioning.

[simpat1zq]

Ive got the same problem. One of the lights are an LED strip using ESPHome. The others are zigbee2mqtt bulbs.

[jquatier]

It's pretty broken still, so I switched to nabu casa for better alexa and google home support. Works better than ever.

[joogps]

For me, the communication works perfectly. The only problem is the way Alexa is responding to it. I'll take a look at the integration and see how I can help.

[pmd5700]

I'm having the same issue. Has there been any development on this?

[mamekid]

I gave up on hue emulation in HA, installed node red. and everything just works.

[jef-pearlman]

Also still experiencing this in 0.111.1 (and since I started using emulated_hue a few months ago). Any chance of reopening the issue? Specifically, about half the time I control a light through Alexa and emulated_hue, Alexa says "Sorry, [name of light] is not responding." The light appears to always successfully change; it just also gives an error. If I try the same light multiple times in a row, sometimes it will give the error and sometimes not.

I also realized that the error message is different than the one in this issue, so I'm going to open a new issue. Thanks! [Edits to add details and note the different message.]

[cemilbrowne]

+1 definitely not fixed.

I'm getting this behaviour across a broad range of devices (lifx/tasmota/hue) on 0.113.1

[kvermilion]

I'm having this problem on 0.111.4, despite following the instructions in the documentation Has there been a change which should fix this since 0.111.4? If so, I can upgrade.

[bitglue]

I'm also having this problem with 2021.1.1. I haven't narrowed down the exact cause, but I have a lot of Jasco dimmers and switches, and notice the problem most consistently with light groups. Alexa responds the device may be "malfunctioning", though it does actually work. Given the number of other reports I'm reopening the issue, and I'll see if I can narrow down a cause.

[JeffLIrion]

I use lights_all_dimmable: True in my emulated Hue config and it's been working fine for me for at least a few HA versions (probably ever since that config option was added).

[bitglue]

I think lights_all_dimmable is aimed at a different problem than what I had in mind. lights_all_dimmable was introduced when HA stopped reporting all lights as dimmable -- if Alexa had detected them as dimmable before, they would have issues if they stopped being dimmable.

I was thinking about https://github.com/home-assistant/core/pull/35307 and thinking the delay there wasn't sufficient, but going over this issue again with fresh eyes and a cup of coffee it looks like emulated_hue has since had several more modifications, that delay is no longer there, and the history of this issue is more muddled.

There's nothing more useless than a thread of every problem that ever happened with emulated_hue, so I'm going to unrepopen this and open a new issue once I figure out specifically what's broken. My apologies for the noise.

[LP0815]

I have also the same problem that Alexa does the action, e.g. "put lights on" but afterwards she also says that "lights appears to be malfunctioning" (in German: "Licht scheint nicht richtig zu funktionieren"). I am using the newest version of Home Assistant Core and OS.

[simphide]

Same here - problems seems to still exist

[eporsche]

I have that issue with the media player as dimmable bulb.

[FSFirenze]

Reporting a similar issue here. Running both HomeAssistant and zwave2mqtt on RasberryPI4 and Docker containers.

I am able to use the Emulated Hue to drive my fans and set their speed, so that part is good. I do have an annoyance though, which is that Alexa answers to my command “Alexa, Set Master Fan on Low” saying “Master Fan appears to be malfunctioning”, however she is able to turn on the fan at the right speed.

Do you have any recommendation on how to avoid this annoyance?

Note that a similar request is posted here https://community.home-assistant.io/t/getting-a-fan-to-work-with-alexa-using-emulated-hue/55460/20 and that I received this answer so far: "Your switches don’t have a state, they need to have an on/off state that reports immediately if you don’t want that response from alexa"

Thanks

My fan switches are a GE 14287/ZW4002 and an Enbrighten 55258/ZW4002. My yaml configuration as follows:

‘# Amazon Echo thru Emulated Hue emulated_hue: host_ip: 192.168.0.103 listen_port: 80 off_maps_to_on_domains:

• script
• scene expose_by_default: false entities: switch.in_wall_paddle_switch_500s: name: “Camilla Fan” hidden: false fan.in_wall_fan_speed_control_500s: name: “Master Fan” hidden: false fan.in_wall_fan_speed_control_500s_2: name: “Living Fan” hidden: false’