How to integrate ZGP devices into V2 Quirks?

[konistehrad]

I've been working steadily on adding ZGP support to Zigpy for some time, and I'm now finally able to dedicate (a little) time to completing the project. Since I've been gone we've received an entirely new Quirks package, which is very cool! The current ZGP device quirks are a bespoke solution using a match classmethod, which looks remarkably like the new filter system, but with a necessary priority field allowing the quirks to be evaluated in order since our matching is sloppy; ZGP devices generally don't send make and model information down with them. (Only the SWS200 is the exception so far.) This means we also need a way to rewrite make and model after initialization as currently done in https://github.com/konistehrad/zha-device-handlers/blob/zgp/zhaquirks/greenpower/ptm215z.py#L36.

With that, what's the best way to get ZGP matching into V2 quirks? My first thought was a list like _registry_zgp next to _registry_v2, and an additional method add_to_registry_zgp, that takes both a QuirksV2RegistryEntry and an integer priority, inserted into the list and sorted. Also fields should be added to QuirksV2RegistryEntry like override_manufacturer or override_model that will do the overrides.

Please let me know what you think of this proposal and I'll get going!

[konistehrad]

Oh pinging @dmulcahey and @puddly for review. No rush of course just keeping this on the radar.

[puddly]

From what I recall, GP quirks match on supported features and IEEE prefix. This should be handled well by a normal callable.

Perhaps we can support quirk filters returning an integer (or create a new filter_weighted?) as opposed to a boolean so that quirk matching takes it into account?

As for naming the device, I think we can create a new metadata type that renames it and supply that info directly in the quirk metadata as opposed to modifying the zigpy device object directly?

[konistehrad]

Yes that's correct, but the V2 infrastructure depends on manufacturer and model information passed into add_to_registry_v2, which uses that information as part of the key into the _registry_v2 dict. We don't have that information yet, precipitating the need for an alternate method or at least an alternate storage method.