Expanding v2 quirks to support Green Power

[konistehrad]

Hi @puddly, hoping to bend your ear here about how to get ZGP support in the new quirks structure. We're up against a few awkward constraints when supporting ZGP devices, namely:

• ZGP devices provide no information about their capabilities.
• ZGP devices provide extremely limited information about their identities. Some examples:
  • The SWS200, as a battery-powered device, sends its model ID.
  • The EnOcean PTM215Z and PTM215ZE use fixed ZGP ID prefixes to do their matching.
  • The Moes self-powered switch device has a completely mutable device ID, and sends almost no information about itself, other than it's a switch and it supports encryption.

As a result, in the original PR, I implemented a match class method that ran as much custom code as it needed to do the match, and assigned all devices match priority, from the SWS200 "this is definitely the one" to the Moes "IDEK man" catch-all.

With all that as context, I'm hoping to work with you to architect something a little saner and cleaner than the original PR. If you could give me some pointers on how I might structure green power device matching given these constraints, I'd really appreciate it.

[puddly]

I think we can just mirror the matching logic you originally wrote and create a GreenPowerQuirkBuilder that does the matching. Green power devices don't have a model or manufacturer so we won't be able to match them with the usual QuirkBuilder anyways.

[konistehrad]

Ok cool makes sense. I’m going to start with a first pass at the ZGP controller itself soon, and once I’m in a position to I’ll start working on the alternate quirk builder.