By the way, this already happens with Matter on iOS. For Apple, your Apple TV or HomePod is the hub and automations run there, not on our phone. If you have multiple of these Apple devices (i.e., a mix of 2 or more Apple TVs, homepods, homepod minis), one will be the leader, with others in standby. One of the ones in standby will take over if you reboot or lose power to the current leader. The failover is a nice feature, though Apple automations are quite simple (at least they are if you set them up by iOS Home), and can't fully replace what you can do in Hubitat or HomeAssistant for the more sophisticated user.
Itās been a while since I played with it (disasembled to test some other code that I needed multiple hubs for), so it may need a little dusting off. Wrote it for the C-7, but the C-8 made it more viable with its Zigbee improvements.
you must be a cyclist 
I donāt understand? 
The N+1 reference is a common reply to a similar question about how many bicycles a cyclist needs.
What he said!!! 
LOL, Iām in IT, so for me itās a way to either describe hardware redundancy, or a software version policy eg N-1 (meaning one version older than current).
I had no idea cyclists used it. 
This explains SO MUCH about my older brother, and my son...I always wondered why N was not enough.
I've looked at the thread below this comment and no one has verified this yet... Or refuted it, either.
Can someone post a definitive anwer? After using Apple/Google to "commission" a Matter device, is that tech still needed?
I may be interested in Matter even with additional setup steps as long as Matter support on my C-5 isn't actually just an "integration" that can talk to devices on a Google network, ya know?
If the device is Matter over Thread, then yes the Matter commissioning platform will still be required as it contains the Matter Thread Border Router (TBR).
If the device is Matter over WiFi, then I believe you could turn off the commissioning platform and Hubitat will still communicate with the device. BUT, I have not tested it personally.
One thing I notice is when I use Google to commission matter over wifi devices, then use the pairing code from Google to integrate with hubitat, if you then try to remove the device from Google it also breaks the integration with hubitat.
So somehow they are still connected after commissioning. (Google/hubitat)
Here's a question I have. I see that in the Hubitat documentation, there's now a section on writing a Matter driver. Is this actually necessary? I thought the point of Matter was to follow a standard communication interface, so I would think that the hub itself could dynamically translate.
For example, suppose you join a matter device and it reports having these two clusters:
0x0006On/Off0x0008Level Control
It seems like the hub itself should be able to see that, and dynamically treat the device as having the Hubitat Switch and SwitchLevel capabilities, with all their attributes and commands.
Am I misunderstanding something here? I get why we have to make custom z-wave drivers, since device manufacturers go wild with their messages and configurations. Is that the problem? Does Matter also allow device manufacturers to go crazy with customizations or violating the spec?
The short answer is - yes.
The longer answer is being typed by Robert at this moment .. : )
Long version incoming. 
Every device on the hub needs a driver, so just not having one isn't possible under the current model if that's what you're asking.
Or if you're asking whether it would be possible to "dynamically" generate one based on knowledge of a device's clusters, command classes, etc., then maybe, though as mentioned above, device-specific quirks may still require attention. But the hub does not support such a model as-is (though as a driver author, you may be able to more easily assemble such a driver on your own using libraries, for example).
Even if it did: would Matter be better at this than other protocols? I don't think it's been around long enough to say. But I don't think Z-Wave is as wild as suggested, and while good chunks of drivers can more or less be written in this way, some devices still require personalized attention (especially ones with lots of configuration parameters, which are necessarily device-specific beyond the way they are read and written in the first place). So ... I don't know, but I don't know that anyone does at the moment.
Also note that a driver doesn't only handle whatever device-specific quirks there may be, standardized or not; it also communicates to apps that look for devices what capabilities the device supports without the app needing to know anything about the particular device (protocol, manufacturer, etc.) -- sort of a layer of abstraction, as all the app sees are the standard commands and attributes that it's the driver's responsibility to handle.
Related to this, many devices -- of any protocol, even if otherwise "standard" -- still have specific drivers because the device itself is an unique collection of capabilities, like a motion sensor that does temperature and illuminance readings compared to a motion sensor that only does motion (meaning the same driver would not be a good fit for both, leading to the existence of a different driver for each).
FWIW, this hypothetical device would probably work with the Generic Matter Switch driver -- built-in to the platform.
Not really, I would say it is more about the settings and possibly different revisions of the z-wave command classes.
My Zooz outlet/plugs driver is universal other than the device settings. You can (and people do) use it on any Z-wave plug that follows the current standards. It works for metering or regular plugs. It has pre-programmed settings for Zooz devices, unknown devices are presented with no settings.
Also just found out this week someone has been using my Dimmer driver for an Aeotec dimmer and it has been working good.
So really other than the device specific settings you could cover the majority of Z-Wave devices with generic drivers. Typically each driver I create is for a separate "class" of device that has different capabilities. At this point I have code that covers most of the messages that devices send in. Its just a matter of piecing the right chunks together to make a driver for the specific capabilities of the device.
non-standard standards, unsystematic systems...
Surprised?
Nope.
When I wrote that, I was thinking about the several scene controllers that I've worked on drivers for. Their usage of "generic z-wave messages" has been... creative and individual.
