Drop ZHA sensor for Analog/Multistate input clusters

[Adminiuga]

Breaking change

Yes. Drop ZHA sensors corresponding to AnalogInput and MultistateInput Zigbee clusters. Mostly seen in aqara vibration/cube devices which are pretty much stateless. So remove entities and rely on zha_events instead.

Proposed change

Drop ZHA sensors corresponding to AnalogInput and MultistateInput Zigbee clusters. The way they are used right now is stateless and zha_events is a better way of handling it.

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New integration (thank you!)
• New feature (which adds functionality to an existing integration)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Example entry for configuration.yaml:

n/a

Additional information

• This PR fixes or closes issue: fixes [BUG] Xiaomi Magic Cube battery and multistate_input errors zigpy/zha-device-handlers#372
• This PR is related to issue:
• Link to documentation pull request:

Checklist

• The code change is tested and works locally.
• Local tests pass. Your PR cannot be merged unless tests pass
• There is no commented out code in this PR.
• I have followed the development checklist
• The code has been formatted using Black (black --fast homeassistant tests)
• Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated for www.home-assistant.io

If the code communicates with devices, web services, or third-party tools:

• The manifest file has all fields filled out correctly.
  Updated and included derived files by running: python3 -m script.hassfest.
• New or updated dependencies have been added to requirements_all.txt.
  Updated by running python3 -m script.gen_requirements_all.
• Untested files have been added to .coveragerc.

The integration reached or maintains the following Integration Quality Scale:

• No score or internal
• 🥈 Silver
• 🥇 Gold
• 🏆 Platinum

[probot-home-assistant]

Hey there @dmulcahey, @Adminiuga, mind taking a look at this pull request as its been labeled with a integration (zha) you are listed as a codeowner for? Thanks!
_{^{(message by CodeOwnersMention)}}

[Shulyaka]

Ouch. I agree the cube and vibration were broken.
But what is the suggested approach for non-stateless analog input devices such as an XBee? A template_sensor + input_number + automation? We probably have much more users that use Aquara than users that need XBee analog inputs (am I alone in this category yet? ;) ), so I understand and even support the decision, but probably there could be a better approach.

[Adminiuga]

Oops, forgot about XBees. Could you open an issue in core and remind me the use case with XBee. We could try addi g those back, but only for XBees

[eurodrew555]

Hi there, I have a Nortek HUSBZB-1 which I'm using for my Zigbee devices with Home Assistant.
I have upgraded to 0.112.0 today and my Xiaomi Mi Smart Plugs no longer display any power utilisation.

This was previously provided by an _analog_input entity but based on this change it looks like that has been dropped?
I have tried subscribing to zha_event but I don't see any power utilisation events when I switch the plug on.

I have enabled debug logging for zha as per the troubleshooting guide but all I see is the on/off of the plug itself.
I normally get the power utilisation in Watts showing up pretty much immediately.

2020-07-02 22:26:43 DEBUG (MainThread) [homeassistant.components.zha.core.channels.base] [0xee76:1:0x0006]: executed 'on' command with args: '()' kwargs: '{}' result: [1, <Status.SUCCESS: 0>]
2020-07-02 22:26:59 DEBUG (MainThread) [homeassistant.components.zha.core.channels.base] [0xee76:1:0x0006]: executed 'off' command with args: '()' kwargs: '{}' result: [0, <Status.SUCCESS: 0>]

[Adminiuga]

Please open a separate issue and post "Zigbee information" for the affected xiaomi device

[MaximumSU]

This is very strange desigion - to drop some from a protocol specification complitely based only on :

Mostly seen in aqara vibration/cube devices which are pretty much stateless.

We have so many usage cases with ZigBee.... For example, i use this firmware Zigbee Configurable Firmware it has all sensors and GPIO as ZCL_CLUSTER_ID_GEN_MULTISTATE_INPUT_BASIC and ZCL_CLUSTER_ID_GEN_ANALOG_INPUT_BASIC - so what? Also XBee and many more... All of this dropped now? Why? What is the reason?

[Adminiuga]

I hear you. as mentioned in #36696 (comment) open a core issue and post a "use case" there along with zigbee information for the device you are using it with.

[MaximumSU]

along with zigbee information for the device you are using it with

What kind of information for you need? This is not a device, this is configurable firmware for cc2530 ic - it may be many options seleted, such as GPIO roles, sensors, Manufacturer ID, Model ID e.t.c. They are not fixed...

[Adminiuga]

Document your specific use case where it relies on multistate input cluster. Post "zigbee information" from ZHA device card. Enable debug log and submit log for attribute reports when change is reported on the cluster.

[MaximumSU]

OK, i understand your position, but i d't like such workflow. I better stay at zha from 111.4 in my "custom-folder", it is more reliable. Who knows, what is happen next. May be sometheing else will be "dropeed" without of serious reason, and i will need to refactor my working system again... Thank's, no.

[dmulcahey]

@MaximumSU These were dropped because the only use cases we knew of were textual displays that I used to build the functionality for the Xiaomi cube, switches and vibration sensors. They were removed because they weren’t really valid uses for the clusters. We aren’t saying that we won’t support this we’re just asking for real documented use cases... I’m not sure why this is so hard to understand or why you seem to be so offended by it.

[Shulyaka]

@MaximumSU Here is an example:
I use an XBee3 device to control my humidifier. Digital IO pins are connected to relays to start/stop a pump and open/close individual zones, while analog input pins are used to monitor water pressure and temperature; they are connected directly to the analog sensors. The analog inputs used to be represented as sensor entities in HA constantly updated by the XBee, but now the sensors are unavailable.

[MaximumSU]

@dmulcahey

These were dropped because the only use cases we knew

Are you sure, you know all usage cases of all ZigBee clusters now and in future?

They were removed because they weren’t really valid uses for the clusters.

OK, but what about the valid uses? Even, if you d't know about it? Why not remove it from Xiaomi cube qiurks only, as it is not valid there (about it you know exactly!)?

we’re just asking for real documented use cases

They are may be many, you realy whant to know all? As i think, one is enough. I showed an example: Zigbee Configurable Firmware - it sends the GPIO inputs as ZCL_CLUSTER_ID_GEN_MULTISTATE_INPUT_BASIC and Analog inputs as ZCL_CLUSTER_ID_GEN_ANALOG_INPUT_BASIC, external sensors - as ZCL_CLUSTER_ID_GEN_ANALOG_INPUT_BASIC etc.

I’m not sure why this is so hard to understand or why you seem to be so offended by it

It is not hard, and I'm not offended by it. This is another. I understand, when something not realized, and somebody ask to realize it, but i do not understand, when something was realized, used by somebody and in one moment was "dropped" because developer don't know, that somebody uses it functionality (what was realized before). If something was reailized and published for all - it must stay untoched (it may be dropped only if it is very serious reazon for it), because somebody may relay on it, use it in some workflow and it may be critical - we tell about home (and not only home) automations, not about some "game". This is my point of view.

There is very bad trend here - devs "break" their components one-by-one. Under "break" i mean, that some component was work during the years and then in one moment it "break" - developer symply remove some option, what was used by some people. Now i have two such components, and they are main components from 3 in my system! Second one is Xiaomi Aqara - they removed yaml, switch to GUI and also "removed" all options, that was in yaml configuration. The issue is rised, but so what? Systems completely not working, people nervous and they have no any warranty, that dev will fix it. May be yes, may be no, may be he will tell: "this is my decision, i think so, if you not like it - you may do it by yourself"...
If we telling about me - it is not a problem, i'm IT specialist and the technical engineere, i can copy last version in custom folder, i can refactor the system, if it is need, but if we telling about some not very scilled user - this is the huge problem for him. But i'm also do not like repair the broken system. There is more interesting things in the world.

So, at the moment i stay on 0.111.4 and thinking, what to do in this situation. I think, i will move all my critical components to the custom folder not to have such kind of "surprizes" in the future. Then i will try to upgrade to 0.112. If it will be success - OK, no - i will stay on 0.111.4 Too much "breakin changes" in every reliaze for me. I'm tired.

[Adminiuga]

I don't quite understand the complaint. there's beta period, all changes are posted. Issues raised during beta are addressed, but after all you are correct: it's an open source software and you are free to use it as you'd like

[Adminiuga]

elling about some not very scilled user - this is the huge problem for him.

I doubt "not a very skilled" user would flash a CC2531 with Zigbee configurable firmware to notice the Multistate cluster is gone. Even with XBees, I only know two users who would miss that cluster.

There is more interesting things in the world.

Totally agree here. And supporting ZHA is not really one of them.