I’ve added the SwitchBot Hub 2 to Matter in the Apple Home app. However, there’s a 4-5 second delay from when I tap on my iPhone to when the SwitchBot Curtain 3 starts moving. Is this normal, or does it seem slow? I’d prefer not to integrate it with my Hubitat Hub until I can resolve this delay. Any advice?
I noticed the same thing with a button I tried bringing into homekit with my Hub Mini Matter. Took a few seconds to respond, the api integration is much faster. But I did notice that temperature updates are much faster.
I came to this thread though because I picked up the new SwitchBot Meter Pro unit that displays its internal sensor and a secondary one. It created a child device for it but it doesn't display the temperature correctly, Just shows 32 which isnt correct for indoors or outdoors lol. It also shows no humidity like my other sensors. Guessing cause its "new" just not supported yet.
Hello @kkossev I was just wondering something. I have been using some of your drivers to get the Aqara devices into HE. I have used your driver to get an FP1E into HE and it works great. I have also used your advanced matter bridge to get an FP1E and it works great, pretty much just as fast as the strait zigbee pairing driver you put out. My real question is, and you might not know this, but why can't we bridge the FP2 from an Aqara M3 hub to HE?
I am using the Replica driver for ST that @Bloodtick_Jones created, which once again is awesome but slow in getting the FP2 into HE which means that I can get halfway across a room before it triggers the lights on.
How fast is the SmartThings mobile app indicating motion?
I honestly don't use HubiThings that much anymore beyond TVs and a Refrigerator, but I remember it was as fast as the ST app indicating change. So curious if 'any' protocol would help other than direct integration into Hubitat.
Thats the funny part. I wouldn't really know. I started using smarthings after using getting my Lutron Caseta up and working. And then after getting the first occ sensor for Lutron and saying this is way to expensive for what it does I started looking around and found Hubitat. Then I removed everything from ST and the only reason I opened it back up is for this replica app to get the FP2's into HE. I replaced the FP1E in my bedroom to with the FP2 using this app to go through ST and there is a big difference in the time it takes to register presence. I can get half way through the room instead of a step inside the door after the switch. It very well can be a difference in the sensors which nobody but Aqara can do anything about. And don't get me wrong, your ReplicaApp is really the only thing I have found so far that gets me the seperate zone information. If it winds up being a device thing then I will probably get one of my zooz motion sensors right by the door back in play to activate lights right when I get into the room. Mostly cause they are cheap, can be powered, and I have a bunch laying around after getting the FP1E's and FP2's
Aqara FP2 is not exposed to other Matter controllers via Aqara Matter gateways. Currently, Aqara only exposes Zigbee devices (not all models, though).
Aqara FP2 uses encrypted WiFi communication. Although the encryption key is known, creating a driver for Hubitat that will communicate directly to the FP2 device (without the Aqara hub) will be challenging and time-consuming, as this is not my area of expertise.
I just tried out the Matter Advanced Bridge for my Hue integration.
When first add the Hue bridge, Hubitat assignes the Genetic Matter Bridge, and discovers child devices. I then change the type to Advanced Matter Bridge, hit Initialize > Discover All.
After discovery, I see a lot of new child devices, all called something like "Bridge#YYY Device#XX". Also the old child devices created with the Genetic Matter Bridge driver no longer responds, but are still there.
Am I doing something wrong, since I'm not getting device names in, and old devices from the Genetic Bridge are not matched/cleaned up?
This custom driver uses a different algorithm for detecting the Matter bridges chid devices and different naming scheme. So, switching between the two drivers is not very smooth.I must admit that the inbuilt Generic Matter Bridge driver extracts the Hue bridge device names better.
If you are experimenting and don’t have the chid devices already in use in many automations, you can use the ‘Load All Defaults’ button to clean up all the child devices, and then run a ‘Discover all’ again.
Update: just checked that Load All Defaults doesn’t remove the child devices.
If you click on the ‘Command’ button, in the live logs page you should see the name of the command that deleted the child devices . Copy and paste this command name in the parameters field and execute it .
Additional note - it is better to use the Hue Bridge native API integrations (the new 2.4.0.x platform inbuilt integration, or CoCoHue app), as these provide more functionalities when compared to Matter.
Thanks for that . I found the command (removeAllDevices) and discovered devices again, but still same issue with device naming. Have 70 devices in Hue, so quite some work to figure out which device is which bulp
Was actually using CoCoHue before (for several years), but I have been having serious issues in the connection with one of my two hubs over the last week, so thought I would give Matter a try. But can see that the device support (with Generic Matter Bridge) is quite limited compared to CoCoHue as you say. I wanted to see if i could get better device representation with Matter Advanced Bridge, but will probably look more into getting CoCoHue up and running again.
Finally, after seeking help in the Tuya forum, they have updated my device configuration (I had to provide my device ID), and now the humidity level is displaying the correct value in both HA and HE and no longer stuck at 40% like during the beta testing!
Yeah, let's hope so!
I am still stuck on Firmware v1.11.0 (the version you have was pulled), and I am waiting for them to release the next firmware update.
I have added a new Hub 2 to HE via the bridge.
I'm now at a crossroads , trying not to screw up.
I have 2 blinds on a hub mini and I want to move them over so I can go local and get off the API.
Do I just delete the blinds from the hub mini and re-add them to the Hub 2 via the SB app?
Is it that easy or is there a manual setup of the blind children, no SB app, to the new Hub 2 Matter device somehow.
I'm not totally clear on the workings of the Matter bridge.
Another Matter Newb question.
I have logs set to off in the prefs but I keep getting updates on every change.
dev:23212025-12-30 14:28:03.746infoBridge#2320 Device#02 humidity is 46.0 %
dev:23222025-12-30 14:26:57.896infoBridge#2320 Device#03 temperature is 21.4 °C
I got the blinds working fine from the Hub 2.
I then deleted the Hub Mini and lost the connections to my blinds as removing them from the Mini removed them from everywhere; device count 0 now.
I did a Discover All and they came back as children but they don't work.
Not sure if I even need the SB app and devices in the app anymore?
Once this is working I'm local and can delete the cloud stuff?
Bit confused as to the building blocks here.
I thought once the Hub 2 was joined to HE I was now free of all the SB software.
dev:23242025-12-31 12:01:57.866errororg.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast object 'null' with class 'null' to class 'int'. Try 'java.lang.Integer' instead on line 280 (method close)
dev:23242025-12-31 12:01:57.855infoBridge#2320 Device#03 setting target position 100% (current position is null) dev:23232025-12-31 12:52:11.411
error
org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast object 'null' with class 'null' to class 'int'. Try 'java.lang.Integer' instead on line 280 (method setPosition) dev:23232025-12-31 12:53:16.592
error
java.lang.NullPointerException: Cannot invoke method minus() on null object on line 358 (method startPositionChange)