Matter Support Released

[jwetzel1492]

@bertabcd1234

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).

I assume this is what HomeKit or Alexa are doing internally when they pair to a Matter device. They don't have ability to switch out a driver. (In some cases, you can choose the representation of the device in the UI. ex: switch vs plug vs light)

@bertabcd1234

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.

LOL, I assume all the competing parties will turn this protocol into spaghetti, just like previous ones.

@bertabcd1234

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.

This is where I think a dynamic driver could be useful. We can't do it as a user driver, because we can't dynamically define capabilities, commands, and attributes. (Though folks have asked before: Dynamic Capabilities, Commands, and Attributes for Drivers) So it would have to be internal to the hub.

[jwetzel1492]

I found a comment from @mike.maxwell that gives a potential architecture that a "Matter-Everything Driver" could use:

The behavior of a method generating Commands

this has been discussed, along with preferences. While we don't have any immediate plans to implement this, we understand the need and benefit of this. This is much different than dynamic capabilities and commands, this is mostly UI work with a little back end schema to support it. True code driven dynamic capabilities requires much much more platform work. Much can be done by creating a parent stub device that's bound to the actual physical device, then via code or user preferences create …

Though having a child device for every capability would get messy in the UI. I like the "purity" of auto-discovering Matter abilities and making them available. But usability triumphs over purity.

[danabw]

@jwetzel1492

having a child device for every capability

Not my favorite approach to turn lots of things into child devices...I really like having access to Swap Apps Device when I want to move things around when doing testing/troubleshooting, replace devices. Child devices aren't supported by Swap Apps.

[BorrisTheCat]

@bertabcd1234

(though as a driver author, you may be able to more easily assemble such a driver on your own using libraries, for example).

I was having the same thought today. why can't HE create standard background library's that can be called in a custom driver?

something like @matter to tell it it's a matter driver. Then @switch and/or @dimmer or @motion and or @battery

then you just list these in the driver and that's it. You don't see the "code" if they want to protect that but standard drivers can be built easily. If there are issues then when they fix the library everyone gets the bump

[jvm33]

@jwetzel1492

Though having a child device for every capability would get messy in the UI. I like the "purity" of auto-discovering Matter abilities and making them available. But usability triumphs over purity.

Funny you mentioned this. Its basically what I've written here: GitHub - jvmahon/Hubitat-matterTools: Tools for creating Matter drivers for Hubitat in the file matterTools.MatterUniverrsalDriver.groovy

I haven't uploaded the latest updates, but notice this file here: Hubitat-matterTools/matterTools.endpointAndChildDeviceTools.groovy at main · jvmahon/Hubitat-matterTools · GitHub. In that file, the function getComponentDriverByEndpointType looks at the Matter endpoint type ID and assigns child components based on the Matter type. So, for example, an Eve Motion device gets both a Motion child and an illumination child. I actually like the use of a different child device for each type - it makes it cleaner when you are controlling a given endpoint.

I expect a "publicly usable" version will follow Hubitat's next firmware release (there are some Hubitat Matter bugs to be worked out, so I'm waiting for the next Hubitat firmware release to do a final update / code fix). I am pretty happy with the progress so far and have it working so that the same driver works with switches, dimmers, RGB bulbs, multi-endpoint switches, Eve Motion, Eve Energy (including energy usage reporting), and a few others.

[jwetzel1492]

@jvm33

I pretty happy with the progress so far and have it working so that the same driver works with switches, dimmers, RGB bulbs, multi-endpoint switches, Eve Motion, Eve Energy (including energy usage reporting), and a few others.

Bravo! I will be curious to watch how this experiment works out. (And I'll try your driver on my one Matter device.)

[bravenel]

@BorrisTheCat

why can't HE create standard background library's that can be called in a custom driver?

Priorities, priorities based on actual customer base, and custom drivers are not one... Just being real about where something like this stands.

[BorrisTheCat]

@bravenel

Just being real about where something like this stands.

yes understandable but i was thinking of it more for your sake and time sake, surly this is a good all around better approach? ie rather than you having to reinvent the wheel each time you do a driver / going back and having to fix each one when there is a issue. Surly a standard set of functions that can be called would help you and everyone else out just as a bonus.

[dJOS]

@BorrisTheCat

Surly a standard set of functions that can be called would help you and everyone else out just as a bonus.

Agreed, do the bulk of the work up front, save a ton of duplication and effort down the road.

[bravenel]

@BorrisTheCat

i was thinking of it more for your sake and time sake

@dJOS

Agreed, do the bulk of the work up front, save a ton of duplication and effort down the road.

I'll be sure to pass your suggestions on to the engineers, I'm sure they will find them inspirational and enlightening.

[dJOS]

@bravenel

I'll be sure to pass your suggestions on to the engineers, I'm sure they will find them inspirational and enlightening.

Ah Bruce, I do enjoy your sarcasm, you'd make a good Aussie ... now repeat after me "yeah, nah".

[DMurphy]

Did you succeed in getting a Tasmota Matter device added to Hubitat?

I just landed a couple of Athom ESP32-C3 plugs that have matter support. After commissioning it with Tuya Smart and putting it into sharing mode, Hubitat was unable to join it to it's fabric.

[DMurphy]

I can confirm that once the Matter device is commissioned, put into sharing mode and then joined as a Matter device to Hubitat, the old commissioning device is not longer necessary. You can remove it from the original commissioning fabric and the device will continue to function with Hubitat. Keep in mind that if you do leave the device only connected to the Hubitat fabric, you cannot then put the device back into sharing mode, at least as at 2.3.8.138, so if you ever want it to join another fabric, you will have to factory reset the device and go through full commissioning again.

[JBrown]

I have not tried the Hubitat matter integration yet, I need to get a new hub mine is a C4. I did get the esp32 to join with homekit.

[rlithgow1]

@DMurphy

You can remove it from the original commissioning fabric and the device will continue to function with Hubitat. Keep in mind that if you do leave the device only connected to the Hubitat fabric,

This is true for wifi based devices, but I think if you are using a thread device and disconnect your thread border router it will not work.

[JasonJoel]

Correct. If you remove a thread Matter from its Thread Border Router, it is effectively 'off the mesh' and incommunicado.

[DMurphy]

Right you are. I should have specified Matter of WiFi, which is my experience with it so far. I have still not managed to snag any Matter over Thread devices all the way down here in Australia.

[Hal3]

So, if you just needed another smart plug to add to your C-8 today would you get a Zigbee plug from one of the usual brands or try one of the new Matter WiFi smart plugs?

[dJOS]

Id get Zigbee or zwave just because I don’t think matter supports power monitoring ATM.

[jwetzel1492]

I just did this the other day. Went with Zigbee. I'm an early adopter, but I'm not a beta tester for a whole industry, which is how I felt the couple times I tried Matter devices.