Add events for LevelControl, Color and OnOff

[elupus]

• Add LevelControl, On/Off, Color events

Depends on home-assistant/core#157853 for support in HA

[elupus]

Just noticed that #419 exists too. I think this is simpler and stands on the main standardized clusters.

[codecov]

Codecov Report

❌ Patch coverage is 96.55172% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 97.17%. Comparing base (3da3ed9) to head (cc1c9d6).

Files with missing lines	Patch %	Lines
zha/application/platforms/event/__init__.py	96.55%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##              dev     #594      +/-   ##
==========================================
- Coverage   97.17%   97.17%   -0.01%     
==========================================
  Files          57       57              
  Lines       10538    10566      +28     
==========================================
+ Hits        10240    10267      +27     
- Misses        298      299       +1     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[elupus]

Btw. I've explicitly avoided some fixed structure here. Tried to keep the original cluster commands as is. Currently HA has very few devices classes for events, so the structure of the event data there has not given correct structure.

Given the above situation, inventing some in-between structure that isn't 1 to 1 mapped to zigbee spec seem pointless and only adds complexity.

[elupus]

So rebased on the new cluster rework. Must say it looks much cleaner and less complicated.

[Hedda]

Any updates on this? PR for initial event support for zha in Home Assistant depends on it -> home-assistant/core#157853

Also related to #419

It was btw mentioned in this other pull request that adding that event entity support pull request first "is the way to go":

• Replace cluster handlers with entity attributes #657

[elupus]

I wonder the same

[Hedda]

For reference, see #864 which implements the base platforms from #594 but is opt-in only for now to get ZGP devices working

[elupus]

Will see if i get some time to rebase it.

[Hedda]

Is this work to implement a "Base IR platform" also affect how this should be architected and implemented?

• Base IR platform #867

@elupus Should this pull request maybe also be rebased if and when #864 and #867 has been merged?

[elupus]

Rebased with a lil-help from a friend. Much cleaner and simpler now. Nice work again on the removal of cluster handlers. I've not yet tested this thou, so must remain draft until tested, but the main ideas could be reviewed if wanted.

[elupus]

Working well with the updated HA change. Seem to be an issue with hiding on/off cluster somewhere on my rotary dimmer (_TZ3000_ixla93vd). But i suspect that is a bug in the quirks. It has On/Off clusters both on server side and client side.

[puddly]

Thanks for rebasing!

Right now, my main concern with generic discovery is that the emitted events are exposing low-level ZCL functionality rather than user-understandable button names: they all are cluster operations. Devices can emit move_with_on_off with different rates per button (and then a generic stop), or use move_to_level, or bare on, or on then off, and so on. These are all device-specific because no two devices expose events the same way...

This is an annoying situation because spec-complaint ZCL discovery and user-friendliness really don't intersect 😅. ZHA already exposes this information via zha_event and (for quirked devices) automation triggers + blueprints, which is even less user-friendly. Automation triggers help because they map specific events to human-readable button names but there is no grouping like there is with event entities.

The only alternative is per-device quirks to map these to buttons, which is what we do now. I was thinking of maybe amending the quirks automation triggers method to also create event entities, since those are "vetted" and already do button mapping?

@TheJulianJES what are your thoughts?

[elupus]

Just small comment.
They are not really device specific. They are standardised, sure some (many maybe) bad devices exists, but there is a spec on behaviour. Which is more than there is for standard events in HA.

My though is that, we should map to "standardized" HA events where they exists. But in absence, we should show the original events that it is possible to read a spec on how they are expected to work.

These are proper events with proper translations which can be automated on, in comparison to the global device event emitter that is hard to match and see.

[puddly]

I don't think it's a matter of non-compliance in this case. Server clusters have attributes that indicate support for commands and such. But a client cluster is entirely open ended: the device is free to send any command with any command parameters (i.e. different move rates for different directions or even buttons).