Core: Zigbee switch (Peanut Smart Plug) “missing” after HA .93 update

[jasonalsing]

Home Assistant release with the issue:

.93.0

Last working Home Assistant release (if known):
.92.2

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

Homeassistant via Docker
ZHA via HUSBZB-1 USB Combo zigbee/zwave
Component/platform:

ZHA

Description of problem:
I have two of these Securfi "Peanut" Smart Plugs:

Both of them stopped reporting the "switch" entity after .93 update. Other entities for the device are reported and working, eg binary_sensor responds to status when the plug is switched on and off via the physical button on the device.

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

zha:
    usb_path: /dev/ttyUSB1
    database_path: /config/zigbee.db

Traceback (if applicable):

Additional information:
I have tried some basic troubleshooting: Remove/Re-add device, Re-set device, remove working device in .92.1/upgrade/re-add device in .93, remove device, remove zigbee.db, add device back, etc. Nothing is having any effect.

I posted on the HA Forums here as well another user confirming the issue with the same device.

Here is before (.92.1) and after (.93.0) of the device in the ZHA Config.

[dmulcahey]

I see the issue... don’t have a good idea for a permanent fix yet. For now, you can use the config to override the device type. In the device config under zha in configuration.yml set it to switch for the ieee of the device. Ex:

  device_config:
    00:0d:6f:00:0a:76:ec:9e-1:
      type: switch

[ghost]

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

_This is a automatic comment generated by codeowners-mention to help ensure issues and pull requests are seen by the right people._

[jasonalsing]

I believe this is what you mean:

zha:
    usb_path: /dev/ttyUSB1
    database_path: /config/zigbee.db
    device_config:
      00:0d:6f:00:0a:76:da:d7:
        type: switch
      00:0d:6f:00:04:a8:60:6f:
        type: switch

but unfortunately this didn't seem to help.

[dmulcahey]

Did you restart and re-add it? I just checked mine and that’s working for me...

[jasonalsing]

I just did "remove device" from ZHA config section, then pressed the reset button on the device, and "added" the device in HA. It was discovered with this output:

[0x0000:zdo] ZDO request 0x0036: [60, <Bool.false: 0>]
Device 0x1ea8 (00:0d:6f:00:04:a8:60:6f) joined the network
Device 00:0d:6f:00:04:a8:60:6f changed id (0x9148 => 0x1ea8)
Considering <class 'zigpy.quirks.smartthings.SmartthingsMultiPurposeSensor'>
Fail because device_type mismatch on at least one endpoint
Considering <class 'zigpy.quirks.kof.CeilingFan'>
Fail because device_type mismatch on at least one endpoint
Considering <class 'zigpy.quirks.keen.KeenTemperatureHumiditySensor'>
Fail because device_type mismatch on at least one endpoint
Considering <class 'zigpy.quirks.ikea.TradfriPlug'>
Fail because endpoint list mismatch: dict_keys([1, 2, 242]) {1}
Considering <class 'zhaquirks.centralite.3130.CentraLite3130'>
Fail because device_type mismatch on at least one endpoint
Considering <class 'zhaquirks.centralite.3300S.CentraLite3300S'>
Fail because endpoint list mismatch: dict_keys([1, 2]) {1}
Considering <class 'zhaquirks.centralite.3305S.CentraLite3305S'>
Fail because endpoint list mismatch: dict_keys([1, 2]) {1}
Considering <class 'zhaquirks.centralite.3310S.CentraLite3310S'>
Fail because device_type mismatch on at least one endpoint
Considering <class 'zhaquirks.centralite.3315S.CentraLite3315S'>
Fail because endpoint list mismatch: dict_keys([1, 2]) {1}
Considering <class 'zhaquirks.centralite.3320.CentraLite3320'>
Fail because endpoint list mismatch: dict_keys([1, 2]) {1}
Considering <class 'zhaquirks.centralite.3321S.CentraLite3321S'>
Fail because endpoint list mismatch: dict_keys([1, 2]) {1}
Considering <class 'zhaquirks.centralite.ias.CentraLiteIASSensor'>
Fail because endpoint list mismatch: dict_keys([1, 2]) {1}
Considering <class 'zhaquirks.centralite.motion.CentraLiteMotionSensor'>
Fail because endpoint list mismatch: dict_keys([1, 2]) {1}
Considering <class 'zhaquirks.gledopto.gls007z.GLS007Z'>
Fail because endpoint list mismatch: dict_keys([12, 11, 13]) {1}
Considering <class 'zhaquirks.gledopto.soposhgu10.SoposhGU10'>
Fail because endpoint list mismatch: dict_keys([11, 13]) {1}
Considering <class 'zhaquirks.hivehome.mot003V0.MOT003'>
Fail because endpoint list mismatch: dict_keys([6]) {1}
Considering <class 'zhaquirks.hivehome.mot003V6.MOT003'>
Fail because endpoint list mismatch: dict_keys([6]) {1}
Considering <class 'zhaquirks.innr.rs228t.RS228T'>
Fail because endpoint list mismatch: dict_keys([1, 242]) {1}
Considering <class 'zhaquirks.netvox.z308e3ed.Z308E3ED'>
Fail because device_type mismatch on at least one endpoint
Considering <class 'zhaquirks.osram.a19rgbw.LIGHTIFYA19RGBW'>
Fail because endpoint list mismatch: dict_keys([3]) {1}
Considering <class 'zhaquirks.osram.a19twhite.A19TunableWhite'>
Fail because endpoint list mismatch: dict_keys([3]) {1}
Considering <class 'zhaquirks.osram.flexrgbw.FlexRGBW'>
Fail because endpoint list mismatch: dict_keys([3]) {1}
Considering <class 'zhaquirks.osram.lightifyx4.LightifyX4'>
Fail because endpoint list mismatch: dict_keys([1, 2, 3, 4, 5, 6]) {1}
Considering <class 'zhaquirks.philips.rwl021.PhilipsRWL021'>
Fail because endpoint list mismatch: dict_keys([1, 2]) {1}
Considering <class 'zhaquirks.samjin.button.SamjinButton'>
Fail because device_type mismatch on at least one endpoint
Considering <class 'zhaquirks.samjin.button2.SamjinButton'>
Fail because device_type mismatch on at least one endpoint
Considering <class 'zhaquirks.sinope.thermostat.SinopeTechnologiesThermostat'>
Fail because endpoint list mismatch: dict_keys([1, 196]) {1}
Considering <class 'zhaquirks.smartthings.motionv4.SmartThingsMotionV4'>
Fail because device_type mismatch on at least one endpoint
Considering <class 'zhaquirks.smartthings.multiv4.SmartThingsMultiV4'>
Fail because device_type mismatch on at least one endpoint
Considering <class 'zhaquirks.smartthings.tag_v4.SmartThingsTagV4'>
Fail because device_type mismatch on at least one endpoint
Considering <class 'zhaquirks.visonic.mct340e.MCT340E'>
Fail because device_type mismatch on at least one endpoint
Considering <class 'zhaquirks.xiaomi.aqara.cube_aqgl01.CubeAQGL01'>
Fail because endpoint list mismatch: dict_keys([1, 2, 3]) {1}
Considering <class 'zhaquirks.xiaomi.aqara.magnet_aq2.MagnetAQ2'>
Fail because device_type mismatch on at least one endpoint
Considering <class 'zhaquirks.xiaomi.aqara.motion_aq2.MotionAQ2'>
Fail because device_type mismatch on at least one endpoint
Considering <class 'zhaquirks.xiaomi.aqara.motion_aq2b.MotionAQ2'>
Fail because device_type mismatch on at least one endpoint
Considering <class 'zhaquirks.xiaomi.aqara.remote_b286acn01.RemoteB286ACN01'>
Fail because endpoint list mismatch: dict_keys([1, 2, 3]) {1}
Considering <class 'zhaquirks.xiaomi.aqara.sensor_swit.SwitchAQ3V2'>
Fail because device_type mismatch on at least one endpoint
Considering <class 'zhaquirks.xiaomi.aqara.sensor_switch_aq3.SwitchAQ3'>
Fail because device_type mismatch on at least one endpoint
Considering <class 'zhaquirks.xiaomi.aqara.switch_aq2.SwitchAQ2'>
Fail because device_type mismatch on at least one endpoint
Considering <class 'zhaquirks.xiaomi.aqara.vibration_aq1.VibrationAQ1'>
Fail because endpoint list mismatch: dict_keys([1, 2]) {1}
Considering <class 'zhaquirks.xiaomi.aqara.weather.Weather'>
Fail because device_type mismatch on at least one endpoint
Considering <class 'zhaquirks.xiaomi.aqara.wleak_aq1.LeakAQ1'>
Fail because device_type mismatch on at least one endpoint
Considering <class 'zhaquirks.xiaomi.mija.motion.Motion'>
Fail because device_type mismatch on at least one endpoint
Considering <class 'zhaquirks.xiaomi.mija.sensor_ht.Weather'>
Fail because endpoint list mismatch: dict_keys([1, 2, 3]) {1}
Considering <class 'zhaquirks.xiaomi.mija.sensor_magnet.Magnet'>
Fail because device_type mismatch on at least one endpoint
Considering <class 'zhaquirks.xiaomi.mija.sensor_switch.MijaButton'>
Fail because device_type mismatch on at least one endpoint
Considering <class 'zhaquirks.xiaomi.mija.smoke.MijiaHoneywellSmokeDetectorSensor'>
Fail because device_type mismatch on at least one endpoint
[0x1ea8:zdo] ZDO request 0x0013: [7848, 00:0d:6f:00:04:a8:60:6f, 142]
skipping discovery for previously discovered device: 00:0d:6f:00:04:a8:60:6f - is rejoin: True
Securifi Ltd. None: started configuration
node descriptor: [<Status.SUCCESS: 0>, 7848, <NodeDescriptor byte1=1 byte2=64 mac_capability_flags=142 manufacturer_code=4098 maximum_buffer_size=82 maximum_incoming_transfer_size=82 server_mask=0 maximum_outgoing_transfer_size=82 descriptor_capability_field=0>]
Securifi Ltd. None: channel: zdo-Securifi Ltd. None_ZDO async_configure stage succeeded
0x9148:1:0x0000: finished channel configuration
0x9148:1:0x0006: bound  'on_off' cluster: Status.SUCCESS
0x9148:1:0x0006: reporting 'on_off' attr on 'on_off' cluster: 0/900/1: Result: '[[<ConfigureReportingResponseRecord status=0 direction=0 attrid=0>]]'
0x9148:1:0x0006: finished channel configuration
Securifi Ltd. None: channel: on_off-0x9148:1:0x0006 async_configure stage succeeded
0x9148:1:0x0b04: bound  'electrical_measurement' cluster: Status.SUCCESS
0x9148:1:0x0b04: reporting 'active_power' attr on 'electrical_measurement' cluster: 30/900/1: Result: '[[<ConfigureReportingResponseRecord status=0 direction=0 attrid=0>]]'
0x9148:1:0x0b04: finished channel configuration
Securifi Ltd. None: channel: electrical_measurement-0x9148:1:0x0b04 async_configure stage succeeded
initializing channel: basic from_cache: False
Securifi Ltd. None: channel: basic-0x9148:1:0x0000 async_configure stage succeeded
0x9148:1:0x0001: bound  'power' cluster: Status.SUCCESS
0x9148:1:0x0001: reporting 'battery_voltage' attr on 'power' cluster: 30/900/1: Result: '[[<ConfigureReportingResponseRecord status=134 direction=0 attrid=32>]]'
0x9148:1:0x0001: reporting 'battery_percentage_remaining' attr on 'power' cluster: 30/900/1: Result: '[[<ConfigureReportingResponseRecord status=134 direction=0 attrid=33>]]'
0x9148:1:0x0001: finished channel configuration
Securifi Ltd. None: channel: power-0x9148:1:0x0001 async_configure stage succeeded
Securifi Ltd. None: completed configuration
Securifi Ltd. None: stored in registry: ZhaDeviceEntry(name='Securifi Ltd. None', ieee='00:0d:6f:00:04:a8:60:6f', power_source=1, manufacturer_code=4098, last_seen=1558301048.13219)
[0x1ea8:zdo] Unexpected ZDO reply 0x8021: [<Status.SUCCESS: 0>]
0x9148:1:0x0b04 async_update
Data remains after deserializing ZCL frame
[0x1ea8:1:0x0006] Unexpected ZCL reply 0x000b: [11, <Status.SOFTWARE_FAILURE: 193>]

[dmulcahey]

If you don’t restart HA the config change won’t take.

[jasonalsing]

I did restart HA as well.

[Adminiuga]

IMO you do need to have -1 suffix for the device_config section key:

zha:
    usb_path: /dev/ttyUSB1
    database_path: /config/zigbee.db
    device_config:
      00:0d:6f:00:0a:76:da:d7-1:
        type: switch
      00:0d:6f:00:04:a8:60:6f-1:
        type: switch

[dmulcahey]

@Adminiuga good catch... I didn’t realize he changed what I posted. Thanks for the assist!

[dmulcahey]

@jasonalsing that -1 denotes the endpoint and it is required. Sorry that wasn’t clear in my info above. We need better documentation for these things...

[jasonalsing]

Thanks guys, that did the trick. I did not realize the -1 was part of the entry (I thought you had a range of ieee or something) I didn't even see any information about device_config on the zha components page.

Side question: now the binary_sensor is "not available" I don't actually use this anyways, but is there just no way to have the multiple sensors on this device right now?

[Adminiuga]

Not ATM, But you still should be receiving ZHA events for the "remote" part of the device. Make sure homeassistant.core logging is set to debug level if you want to confirm.

[r1cht3r]

:+1: this workaround did the trick for my Peanut plugs after upgrading to 0.93.1.

[jr3us]

I agree that the workaround did work to bring my peanut plugs back in control in Home Assistant.

However, I have lost the ability to control them from my Amazon echo.

Trying to rediscover them in alexa will not bring them back either.

I thought maybe this might be related to https://github.com/home-assistant/home-assistant/issues/23514
however after copying hue_api.py from the commit did not change the functionality. I am not able to discover the peanut plugs after this.

I don't know how to tell if this is a problem in zha and defining the peanut specifically as a switch, or if emulated hue is not working correctly. They were working fine using HA .92 and before in both HA and amazon echo being able to communicate with them.
Regards

[jr3us]

additional info: I went back to version 92.2 and am now able to see the 2 peanut plugs on the amazon echo, and can control them as before.

[Adminiuga]

hm, I don't think emulated hue is related in anyway to zha entities.
You need to enable debug logging and post logs here, reproducing the problem. I don't have a peanut plug, but I'm overriding my Osram Plug making it a light and I still can control it with alexa.

[jr3us]

How would I enable debugging for the zha module?
Could it have something to do with having to explicitly force it to being a switch as shown above?

Thanks

[JSkier21]

Thank you for the workaround, just got two of these and switching now works. If only the firmware update didn't need an Almond hub to update for power consumption readings.

[jr3us]

@JSkier21 , do you use an amazon echo, and if so do your peanut plugs work with the echo?

I am having troubles with them and echo when using emulated hue.

[JSkier21]

@jr3us, I'm not using the hue bridge emulated component with Hue hub (Zigbee USB and also test a bit with deconz).

Probably a whole other can of worms there, if the Hue hub doesn't recognize the peanut plug as a switch, that's an issue with Hue hub.

[jr3us]

@Adminiuga, @dmulcahey : the workaround above to explicitly specify the peanut as a switch, appears to cause problems with the emulated hue module, and ( I think ) the echo can't see the peanut switch as a switch using emulated hue since it had to be defined.

[Adminiuga]

@jr3us have you tried exposing the swtich entity specifically through emulated hue configuration?

[Adminiuga]

does emulated_hue gives you anything in the debug log to hint the issue? I'm not quite following why this fails, as emulated hue does not interacts with zha directly and the switch entity is there in the state machine.

[jr3us]

I haven't explicitly exposed the peanut in the emulated hue section, and I have nothing else explicitly exposed there either.

After I got the peanut reestablished in HA, I tried to add the peanut switch to the echo in their menus, and watched the logs on home assistant as I did so, and there were no entries in the logs regarding the peanut.

I did run across something in the issue https://github.com/home-assistant/home-assistant/issues/23435. as follows:

this comment from @dshokouhi below is dated 4/26/19,
@mikesalz try to define a turn_on and turn_off action those values are actually required and maybe why nothing is happening. Its possible HA became stricter here and since there are no values nothing happened.

https://www.home-assistant.io/components/light.template/#turn_on

Information in the link above indicates that an explicit turn on and turn off needs to be added when using this.

I am thinking this really needs to be fixed in zha so that it is presented correctly as a switch to HA rather than having to do all the work arounds above. These work arounds were not needed in prior versions.

If i can help, let me know.

Regards

[dspille]

The peanut switch is showing up in my Alexa app since I explicitly exposed the device. It is acting strange though. It allows me to power on the device with Alexa, but then it becomes nonresponsive in the Alexa app. If I toggle the switch back off using HA, the device becomes responsive again in the Alexa app. I can then turn on the peanut switch with the Alexa app again, but it becomes nonresponsive again, etc.

[jr3us]

Did you explicitly declare the device in the switch section, or emulated hue section, or something else?

One of the things mentionedin the #23435 issue regarding specifically declaring it as a switch, is that there is no turn_on section and no turn_off section. According to the light template, they are required. A mention was made in the emulated hue thread above that those 2 items were needed to get the echo to work with the device. ( NOT a peanut in that thread, but I think that is a hint as to what is wrong with echo, emulated hue, peanut, zha.... ). Way above my paygrade tho.. :-)

[dspille]

I added the peanut switch to the zha section, but I also added it to customize subsection of the homeassistant section to add the emulated_hue_hidden: false statement. I have expose_by_default: false in the emulated_hue section. I do think you may be onto something. Not sure what changed since the last release that caused this.

[jr3us]

@dmulcahey made a comment at the beginning of this thread that he thought he knew what was wrong regarding the initial peanut problem, and had to have a think about the real fix. I suspicion that the real fix will also take care of the echo/alexa problem.

[dmulcahey]

There will be a PR with the real fix this week.

[jr3us]

Cool! Will it be in time for v.94.0? :-)

[Adminiuga]

really fixing and a bit breaking? :D

[dmulcahey]

@jr3us no

@Adminiuga you’re going to ruin the surprise! :)

[dspille]

I can confirm the PR resolved my issue with the switch missing. The configuration override in the zha section of the configuration.yaml is no longer needed.

I am still seeing the following issue however:

The peanut switch is showing up in my Alexa app since I explicitly exposed the device. It is acting strange though. It allows me to power on the device with Alexa, but then it becomes nonresponsive in the Alexa app. If I toggle the switch back off using HA, the device becomes responsive again in the Alexa app. I can then turn on the peanut switch with the Alexa app again, but it becomes nonresponsive again, etc.

[jr3us]

@dspille , are you running the dev version of HA, or did your patch your current version?

[dspille]

I patched my current version (93.2)

[Adminiuga]

there was https://github.com/home-assistant/home-assistant/issues/23514 related to emulated_hue. I'd try upgrading to 0.94 or getting emulating_hue from 0.94 as a custom_component.

I'm still not sold this is a zha issue. The way ZHA overrides devices and initializes the entities, HA or HUE has no way of knowing that entity was supposed to be a binary_sensor, but now it is a switch. When ZHA overrides the devices as a switch, HA sees is as a switch and nothing else.

[dspille]

@Adminiuga You're right; 0.94 solved the emulated hue issue I was having on the peanut switch. Thanks!

[jr3us]

@Adminiuga : what files would I need to add to .94 to get the current mods from the dev instance?

Also, will the peanut need to be removed and re-added again?

Thanks in advance!

[dspille]

@jr3us Not sure if it's the best way to do it, but I pulled the entire zha folder from the dev instance and placed it in my custom_components folder under my config. I did remove and re-add my switches, but I'm not certain I needed to do that.

[HtownTexans]

Thank you for the workaround, just got two of these and switching now works. If only the firmware update didn't need an Almond hub to update for power consumption readings.

It'd be a shame if you accidently ordered one from amazon updated your plug and then had to return it because it magically stopped working ;).

[jr3us]

@Adminiuga , @dmulcahey , I have updated to .94.4 HA, and I am still having the same problems above. I had to do the workaround adding the specific switch declaration in the zha section, and also, amazon echo does not see the peanut plugs.

Should I open a new issue?

[davecozz]

Same as @jr3us. I upgraded to 94.4 and even tried removing and re-adding the Peanut plugs in zha, but they do not show up as switches unless I add them in my configuration.yml.

[dspille]

24370, which includes the zha fix for the peanut switch, is currently only in the dev version of HA (not in 0.94). 0.94 solved the emulated hue issue, but not the zha issue. You can try downloading the zha folder from the dev version of HA to your custom_components folder to get the zha fix for the peanut switch.

[jr3us]

Any ideas when #24370 will be in the released version? .95?

I'm hesitant to copy the dev version into the custom folder and have rewound back to 92.2

thanks

[dmulcahey]

.95

[Adminiuga]

June 19th beta starts, June 26th 0.95 release

[davecozz]

Can confirm that 0.95 fixes this issue. Thanks! :+1:

[jr3us]

Looks good to me also! Thanks @Adminiuga and @dmulcahey !