[RELEASE] Matter Advanced Bridge (limited device support)

Unfortunately, all of the Linptech sensors have stopped working again via the Matter Bridge. I tried on a different HE hub, and they worked for two days. As with the past 4 times, the Discover and Resubscribe do not find the endpoints/devices anymore. The other mmWave sensors and one light behave just fine. (As well, the Linptechs work functionally, showing activity in the Zemismart.) One observation is that the bridge device is stuck in IsRefresh=true, despite not having refreshed.

Any ideas would be appreciated: how to keep them from falling off, how to bring them back (hopefully without all new Device IDs that require manual switching in apps).

Thanks.

@JDC, at the moment, I don't have a clear idea what could be the reason that only the Linptech sensors misbehave ...

This is a clue. Can you first enable the Debug looggiing on the main device (the bridge), then click on the Refresh button. This is what I see in the live logs :

Summary

dev:49712024-05-29 07:59:02.596debugTuya Matter GW sendMatterEvent: sending for parsing to the child device: dw:Moes/Linptech Illuminance dni:4971-0E name:illuminance value:3422 descriptionText:Moes/Linptech Illuminance illuminance is 3422 lux

dev:49712024-05-29 07:59:02.591debugTuya Matter GW parse: descMap:[endpoint:0E, cluster:0400, attrId:0000, value:8A10, clusterInt:1024, attrInt:0] description:read attr - endpoint: 0E, cluster: 0400, attrId: 0000, value: 05108A

dev:49712024-05-29 07:59:02.285debugTuya Matter GW sendMatterEvent: sending for parsing to the child device: dw:Moes/Linptech Motion dni:4971-0D name:motion value:active descriptionText:Moes/Linptech Motion motion is active

dev:49712024-05-29 07:59:02.280debugTuya Matter GW parse: descMap:[endpoint:0D, cluster:0406, attrId:0000, value:01, clusterInt:1030, attrInt:0] description:read attr - endpoint: 0D, cluster: 0406, attrId: 0000, value: 0401

dev:49712024-05-29 07:59:01.981debugTuya Matter GW sendMatterEvent: sending for parsing to the child device: dw:Temperature Sensor dni:4971-05 name:temperature value:24.3 descriptionText:Temperature Sensor temperature is 24.25 °C

dev:49712024-05-29 07:59:01.977debugTuya Matter GW parse: descMap:[endpoint:05, cluster:0402, attrId:0000, value:0979, clusterInt:1026, attrInt:0] description:read attr - endpoint: 05, cluster: 0402, attrId: 0000, value: 017909

dev:49712024-05-29 07:59:01.673debugTuya Matter GW sendMatterEvent: sending for parsing to the child device: dw:Humidity Sensor dni:4971-06 name:humidity value:40 descriptionText:Humidity Sensor humidity is 40.0 %

dev:49712024-05-29 07:59:01.668debugTuya Matter GW parse: descMap:[endpoint:06, cluster:0405, attrId:0000, value:0FA0, clusterInt:1029, attrInt:0] description:read attr - endpoint: 06, cluster: 0405, attrId: 0000, value: 05A00F

dev:49712024-05-29 07:59:01.370debugTuya Matter GW sendMatterEvent: sending for parsing to the child device: dw:GW dni:4971-01 name:powerSourceDescription value: descriptionText:GW Power source description is

dev:49712024-05-29 07:59:01.365debugTuya Matter GW parse: descMap:[endpoint:01, cluster:002F, attrId:0002, value:, clusterInt:47, attrInt:2] description:read attr - endpoint: 01, cluster: 002F, attrId: 0002, value: 0C00

dev:49712024-05-29 07:59:01.093debugTuya Matter GW sendMatterEvent: sending for parsing to the child device: dw:GW dni:4971-01 name:powerSourceOrder value:00 descriptionText:GW Power source order is 00

dev:49712024-05-29 07:59:01.062debugTuya Matter GW parse: descMap:[endpoint:01, cluster:002F, attrId:0001, value:00, clusterInt:47, attrInt:1] description:read attr - endpoint: 01, cluster: 002F, attrId: 0001, value: 0400

dev:49712024-05-29 07:59:00.761debugTuya Matter GW sendMatterEvent: sending for parsing to the child device: dw:GW dni:4971-01 name:powerSourceStatus value:00 descriptionText:GW Power source status is 00

dev:49712024-05-29 07:59:00.759debugTuya Matter GW parse: descMap:[endpoint:01, cluster:002F, attrId:0000, value:00, clusterInt:47, attrInt:0] description:read attr - endpoint: 01, cluster: 002F, attrId: 0000, value: 0400

dev:49712024-05-29 07:59:00.731debugTuya Matter GW sendToDevice (List): ([he rattrs [{"ep":"0x01","cluster":"0x002F","attr":"0x0000"}], he rattrs [{"ep":"0x01","cluster":"0x002F","attr":"0x0001"}], he rattrs [{"ep":"0x01","cluster":"0x002F","attr":"0x0002"}], he rattrs [{"ep":"0x06","cluster":"0x0405","attr":"0x0000"}], he rattrs [{"ep":"0x05","cluster":"0x0402","attr":"0x0000"}], he rattrs [{"ep":"0x0D","cluster":"0x0406","attr":"0x0000"}], he rattrs [{"ep":"0x0E","cluster":"0x0400","attr":"0x0000"}]])

dev:49712024-05-29 07:59:00.704debugTuya Matter GW refresh(): cmdsList = [he rattrs [{"ep":"0x01","cluster":"0x002F","attr":"0x0000"}], he rattrs [{"ep":"0x01","cluster":"0x002F","attr":"0x0001"}], he rattrs [{"ep":"0x01","cluster":"0x002F","attr":"0x0002"}], he rattrs [{"ep":"0x06","cluster":"0x0405","attr":"0x0000"}], he rattrs [{"ep":"0x05","cluster":"0x0402","attr":"0x0000"}], he rattrs [{"ep":"0x0D","cluster":"0x0406","attr":"0x0000"}], he rattrs [{"ep":"0x0E","cluster":"0x0400","attr":"0x0000"}]]

dev:49712024-05-29 07:59:00.693warnTuya Matter GW getSubscribeCmdList(): cluster 0x001D is not in the SupportedMatterClusters list!

dev:49712024-05-29 07:59:00.690debugTuya Matter GW getSubscribeCmdList(): stateSubscriptionsList = [[0, 29, 3], [1, 47, 0], [1, 47, 1], [1, 47, 2], [6, 1029, 0], [5, 1026, 0], [13, 1030, 0], [14, 1024, 0]]

dev:49712024-05-29 07:59:00.674infoTuya Matter GW refresh() ...

If you refresh (F5) the bridge web page after 10 seconds, the 'isRefresh' state should return to false. Is it your case?

IsRefresh returns to false after Discovery. Otherwise, it stays as true after the next manual refresh.

I have one Linptech sensor that behaves well via the Matter Bridge, and 6 that disappear. The one behaving sensor also happens to be the only Linptech that paired only with the Zemismart. The other 6 were connected to HE before the Zemismart. (For fun, I attempted to migrate 3 Linptechs back to HE, but they drop off. The drop-off timing is interesting: with the new mmWave driver, these 3 lost pairing and start blinking as soon as I hit "Save Preferences". Multiple pairings for each, and drops every time I saved the preferences.) Because these 6 Linptechs seem unusable, I'm going to experiment: I ordered more Linptech that I will pair first with the Zemismart, to see if they behave as well as the other "non-HE" one.

Quite the saga.

After two weeks, the experiment is going well. All Linptech are new (never paired with HE) and have stayed connected to the Zemismart. Because of the Hubitat issue (initializations), I resubscribe each night and perhaps one other random intraday time per week (heavy initialization day). So far, so good.

1 Like

I'm having an issue trying to bring my SwitchBot Hub 2 in via the matter bridge. It will not connect after multiple attempts. Even tried connecting it with Alexa first and then bringing it over, still won't pair. I do have one bot paired with SwitchBot Hub because I know most of the Matter bridges require you have at least 1 child device paired. Using the matter pairing code issued from the SwitchBot app. Am I doing something wrong?

Thanks again for the new driver!:+1:

Hi @Hubmanity79 ,

You need to use the new QR code generated from Alexa :

1 Like

@kkossev,
Received a firmware update for the Zemismart M1 bridge.

Also, just wondering when will support for Matter 1.3 be available?

1 Like

I see some errors when running the Discovery process in Debug mode, but let's hope that nothing from the existing functionality is broken after this Tuya update.

This update has not yet been rolled out to the other ' Tuya Smart Wired Gateway Pro.

I haven't read about any manufacturer that has implemented Matter 1.3 yet.
It seems like only HomeAssistant is 1.3 ready ..

1 Like

FYI: Yesterday my Aquara hub M3 arived.
Paired it over Matter, and was discovered as "device".
Manualy set it to the Advanced Bridge driver, and all seems to work just fine.

2 Likes

@kkossev,
Just wondering if your Zemismart bridge is all good since the firmware upgrade?
Everything seems okay for me, but for some reason I am unable to pair the Zemismart back to the Aqara M3 hub after accidentally deleting all matter devices from Google .

I can add other matter devices to Aqara M3, but fail to add Zemismart bridge after numerous attempts.

It gets stuck on step 4 and never completes

I have never tried bridging the Tuya hubs to the Aqara hub.

1 Like

@kkossev
I have recently noticed that the "initializeCtr" counter on the Zemismart bridge increases everytime the "ping" or "refresh" command is used.

(I have re-installed the driver and reset the device, but still same issue)

image

Logs

The Hue Bridge and Aqara M3 bridge do not have this issue.

Most probably, Tuya changed something that breaks the backward compatibility with the previous version... : ) This could be also a possible reason for the Zemismart Brdige issues with the Aqara hub?

Have you tried to discover the bridged devices again manually? All existing devices should be preserved.

1 Like

Yes, most likely, as I started having these issues after the firmware upgrade.

Going through the process of adding the hub, and discovering devices etc. is okay and normal.

Only issue now is the counter increasing due to the periodic polling, unable to add to Aqara-Hub-M3 and the currently known issues random communication loss...

Zemi Smart - counter increase due to polling, random connection issues
Hue - no issues
Aqara M3 - comm issues after loss of internet or router reboot

I will probably add some automations in Home Assistant to test Zemismart to see if it has the random connection issues (I guess you can't do much until HE fix this issue that you reported ages ago..)

Is the counter increasing, even after re-discovering the Zemismart M1 bridged devices?

Unfortunately, yes.
I have removed Zemismart M1 bridge from HE for now.

When you have the time, send me in a DM the complete logs when you click on the Discover button. Obviously something in the last Tuya Bridge firmware update is breaking the backward compatibility, hopefully we can find it and patch it.

1 Like

Excellent work @kkossev! I was able to easily pair my Aqara E1 and get my Aqara U100 lock into habitat using your code.

What would be needed to be able to lock/unlock the U100? Does something need to be done by Hubitat? Aqara?

1 Like

Currently, there are no Matter locks known to work in Hubitat. In this custom driver I was able to successfully receive the locked/unlocked status, but the lock/unlock commands sent to the bridge return unknown error.

When HE releases ann inbuilt driver for native Matter locks, I should be able to make it work also for bridged locks in this driver.

2 Likes

@kkossev - Very nice work! I purchased an Aqara M3 Hub during the recent Amazon Prime Day sale, as it was on sale for $42 off its normal price. I have tended to avoid Aqara devices, due their history of having issues with standard Zigbee HA networks. I due have an Aqara Vibration sensor and a Temp/Humid sensor that I tested with Home Assistant a while back. So, I figured why not pick up the M3 hub and see just how well the Aqara platform works, especially as a Matter Bridge.

I was able to quickly pair both Aqara Zigbee sensors to the M3 Hub, and then connected the M3 hub to Apple Home via Matter (not the HomeKit integration.) That went smoothly, so I then shared the M3 Hub from Apple Home to Home Assistant via Matter. Again, that went very smoothly.

This afternoon, I loaded up your Matter Advanced Bridge integration on my C8-Pro HE hub. I was then able to share the M3 hub via Apple Home as a Matter device. Hubitat promptly discovered the device, however it assigned it a Driver Type of "Device". I manually changed the driver type to your Matter Advanced Bridge driver, and then clicked "Discover All". The Aqara Temp/Humid device showed up as three Hubitat devices - Temperature, Humidity, and Battery. The Aqara Vibration sensor showed up as a Motion sensor. I did not see a "Battery" device created for the Aqara Vibration sensor. Not sure if that is to be expected or not? I do see a battery level in Apple Home and in Home Assistant for the Vibration sensor.

I just wanted to say Thank You! Your work on this integration is very much appreciated, and is working well thus far!

4 Likes