I need to know what is the child device driver type- should be some of the HE inbuilt Generic Component drivers - like this :
Thank you for the report! I could easily patch this in the custom driver, but lets first check with @moncho1138 whether there is not a problem in the Hubitat 2.0 Android beta app, as it may affect also other drivers.
The setLevel command is specified in the Hubitat developers documentation to expect arguments of a type integer (or BigDecimal), while here the Hubitat 2.0 Android beta app is passing a String.
1 Like
Starting today, my Linptech sensors have stopped reporting via the Zemismart bridge. I've resubscribed, refreshed, rediscovered, and even Load All Defaults. They do not appear in the logs at all.
I removed and re-added one Linptech to the Zemismart and then re-discovered in the driver. The endpoints increased by 3, but no child devices were created. Then, oddly a different Linptech is showing as active, as well as yet another Linptech reporting illuminance (which has never happened before).
Any help would be appreciated.
Hi JDC,
It seems as Tuya is making changes in their Matter GW, but there is no way to detect that - they are not increasing the GW firmware version .. : (
I paired my Moes/Linptech sensor to the Tuya GW this morning (as a new device) and it showed up as a motion and illuminance sensor, so it is working as expected here.
What you can do is to use the two new child devices and delete (REMOVE DEVICE button) the old one. Although, it shouldn't be like this, the old device IDs should be retained... 
@iEnam do you remember whether the Linptech illuminance sensor was exposed before?
1 Like
Illuminance was not exposed before and this was the reason why I've recently removed Moes/Linptech sensors from the Zemismart bride and paired directly to HE to make use of the illuminance.
Now that illuminance is supported, I will move the devices back to Zemismart bridge tonight.
Also, I have already setup duplicate automations in Aqara app for my lighting automations for high-availibity (instead of a seperate HE hub) as the M3 hub now supports Hue Bridge and Zemismart bridge and the above means that I can also use the Moes/Linptech sensors in Aqara automations as well.
1 Like
Even after re-adding two Linotech sensors to the Zemismart and re-discovering in the HE driver, the HE behavior is flaky. Oddly enough, the illuminance child appeared for one Linptech that was already there … not for either re-added device and not for the other 5 Linptech already there. One re-added sensor showed a new HE motion child. The other did not, and its existing motion child does not work (i.e. reflect motion changes visible in the SmartLife app).
In short, my situation is jacked and inconsistent, so I advise caution and incremental changes.
1 Like
Hmm, strange.
I would advise removing the old devices and re-discovering in HE driver.
You could also try re-discover again to sync it up with the SmartLife app.
I have remotely removed two directly connected Linptech sensors earlier from HE hub and added to Smartlife/Zemismart hub then discovered in Zemismart bridge, and all working okay.
Edit: screenshots taken at different times, hence Moes Livingroom status in different in app and HE.
Glad it's working. I'm going to remove/re-add them from the Zemismart and then re-discover in HE. Hopefully that will restore things to a working order.
Check in SmartLife app if there are any pending firmware updates for the Linptech sensors?
Thanks @kkossev and @iEnam. I removed and re-added all Linptech from the Zemismart and HE. (They created new fingerprint numbers and children in the driver.) Since Tuya updated its Matter handling, I tried another mmWave that previously failed to discover via Matter/bridge. Happy to say that TS0601_IJXVKHD0 is now available this way.
2 Likes
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!
@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
