Think I will wait on Amazon to get it.
Does this stop the subscription altogether? Trying to prevent the noisy illuminance spam from even reaching HE.
Thanks for the work on this ... the driver has been working very well.
Unfortunately, disabling the child device does not stop the subscription in the current Matter Bridge code. I have had this on the TODO list for quite a long time now.
@kkossev - If I get a matter-enabled SwitchBot hub, can I work with you on adding support for the SwitchBot Door Lock which is now compatible with the SwitchBot Hub 2?
@brad sure, I will be glad to accept PR and work with other developers on improving and extending this package!
Actually I already have a PR from a GitHub user @dds82 on the same topic :
but this PR is on hold for quite a long time now, because of a major problem with the Matter locks support in HE - so far, no one had success with the lock/unlock commands. These commands return unknown/untracable error.... Only the subscription to the lock state is working OK.
Do you have any success with the Matter locks commands in your tests so far?
Hi K,
My first try of this app and I'm using an Aqara M3. There are no ZigBee or other devices on the M3 but I have paired my Philips Hue system to it using Matter. Was a bit of a battle as the instructions are so awful but it's now there and working. This has created about 40 devices visible in the Aqara app and they seem to works OK. I kind of of expected that if I then paired the M3 hub to HE that these devices would become available there too but they haven't so that assumption seems wrong.
Within Matter Advanced Bridge it says 1 endpoints is that as expected? I'll try and add some locally attached hardware to the M3 to see if that gets some showing but I don't have many devices to hand as I'm mostly MQTT now.
* Status : **clear**
* deviceCount : **0**
* endpointsCount : **1**
* healthStatus : **online**
* initializeCtr : **2**
* nodeLabel : **Aqara Hub M3**
* productName : **Aqara Hub M3**
* rebootCount : **2**
* softwareVersionString : **4.1.4**
* rtt : **184**
I did try with HomeAssistant a bit and all my Hue Matter devices now show there and I thought I had only paired the M3 hub but it is just possible at some stage I paired the Hue hub directly so that's not really helpful.
I just wanted to check that Matter paired devices to M3 (or any bridge) shouldn't onwardly pair M3 to HE by default (or at all)., even when both sides of the bridge are Matter.
Cheers Kevin
It seems that Aqara hub does not expose via the Matter Bridge protocol devices, which are not paired directly to the Aqara hub. I am almost sure, that in Home Assistant you have imported the Hue devices directly - the Hue bridge is detected automatically and it is just a few clicks away from importing everything in HA..
If you pair a Zigbee device directly to the Aqara hub and then re-discover the M3 hub in the HE driver, the 'deviceCount' should not be zero.
Of course, you can import the Philips Hue devices directly to Hubitat via the Matter Bridge. It is working very stable on my setup, although I continue to use the CoCoHue direct integration in all my automations.
Makes sense .. and I really don't know why I would want or had tried two 'cascaded' bridges like that - it just doubles the points of failure.
I had this vision of some multi protocol bridge that would bi-directionally convert between xyz and Matter. For me this would benefit in IP/Matter including my C-Bus lighting system or even MQTT/Matter possibly.
So no issue and I can totally understand that constraining the permutations makes things so much easier and more reliable.
K
Successfully tested the ThirdReality Matter bridge with a TR switch, contact, and water leak sensors.
From a practical point of view, this device is typically not needed for Hubitat users, as all ThirdReality Zigbee products have built-in HE system drivers.
Correctly reports status for ThirdReality smart blinds connected via the ThirdReality Matter bridge.
Thank you for the feedback!
There is a small bug in the ThirdReality Matter bridge - the device's battery voltage is reported in Volts, while according to the Matter specifications, the unit should be in hundreds of volts. Surely @ThirdReality will fix this in a future firmware update.
So in your case, the battery voltage should be 5.8 Volts?
This driver could also be improved in the future, replacing the numerical '00' / '01' values of some of the attributes with better descriptive texts.
I think that is right about not exposing devices that are not directly paired to the Aqara hub. I was also reading that few if any matter devices are directly supported by the M3 yet and Aquara have not yet taken the kind of approach Hubitat has of supporting device function types across the board, (e.g. any matter switch).
If true, hopefully that will change and improve.
Yes, several YouTubers criticised Aqara for not working with Matter devices (WiFi or Thread) made by companies other than Aqara.
This was changed very recently and broke on their reddit page (https://www.reddit.com/r/Aqara/comments/1cpi1aw/official_ama_aqara_m3_thirdparty_device_support/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button&sort=new). The M3 hub now supports all third party Matter devices (WiFi and Thread) and Matter bridges.
That's a piece of very good news!
Hopefully, Aqara (and Hubitat, too!) will add support for Matter locks, my experience with the Nuki 4.0 lock commissioned via Apple Home is very discouraging ... : (
Indeed it is good news. I am expecting one later today as it happens because I imagined they would have to support matter more fully.
I presume a firmware update will be needed, but that should not be a problem,
@kkossev,
I get the error below when trying to adjust the light levels on Hubitat 2.0 Android beta app.
Logs
dev:34322024-05-17 09:54:23.283 AMerrorgroovy.lang.MissingMethodException: No signature of method: user_driver_kkossev_Matter_Advanced_Bridge_1512.componentSetLevel() is applicable for argument types: (com.hubitat.app.DeviceWrapper, java.lang.String) values: [Toilet #21, 62] Possible solutions: componentSetLevel(com.hubitat.app.DeviceWrapper, java.math.BigDecimal), componentSetLevel(com.hubitat.app.DeviceWrapper, java.math.BigDecimal, java.math.BigDecimal), componentSetCode(com.hubitat.app.DeviceWrapper, java.math.BigDecimal, java.lang.String), componentSetHue(com.hubitat.app.DeviceWrapper, java.math.BigDecimal) on line 73 (method componentSetLevel)
dev:34322024-05-17 09:54:18.491 AMerrorgroovy.lang.MissingMethodException: No signature of method: user_driver_kkossev_Matter_Advanced_Bridge_1512.componentSetLevel() is applicable for argument types: (com.hubitat.app.DeviceWrapper, java.lang.String) values: [Toilet #21, 68] Possible solutions: componentSetLevel(com.hubitat.app.DeviceWrapper, java.math.BigDecimal), componentSetLevel(com.hubitat.app.DeviceWrapper, java.math.BigDecimal, java.math.BigDecimal), componentSetCode(com.hubitat.app.DeviceWrapper, java.math.BigDecimal, java.lang.String), componentSetHue(com.hubitat.app.DeviceWrapper, java.math.BigDecimal) on line 73 (method componentSetLevel)
dev:34322024-05-17 09:54:09.757 AMerrorgroovy.lang.MissingMethodException: No signature of method: user_driver_kkossev_Matter_Advanced_Bridge_1512.componentSetLevel() is applicable for argument types: (com.hubitat.app.DeviceWrapper, java.lang.String) values: [Toilet #21, 60] Possible solutions: componentSetLevel(com.hubitat.app.DeviceWrapper, java.math.BigDecimal), componentSetLevel(com.hubitat.app.DeviceWrapper, java.math.BigDecimal, java.math.BigDecimal), componentSetCode(com.hubitat.app.DeviceWrapper, java.math.BigDecimal, java.lang.String), componentSetHue(com.hubitat.app.DeviceWrapper, java.math.BigDecimal) on line 73 (method componentSetLevel)
Is this exception generated from the child device?
Which is the component driver used for it?