2021 Tuya XZ-WSD01 Smart Brightness Thermometer

This device behaves rather inconsistently, it was working just fine for 2 days, but today it started self-resetting again... after a lot of trials this is the code that seems to be working (at least for me) at the moment:

https://raw.githubusercontent.com/kkossev/Hubitat/main/Drivers/Moes_ZSS-ZK-THL_TS0222/Moes_ZSS-ZK-THL_TS0222.groovy

@andrew.j.habgood @lusciouslukey @tony4mikki @snell if you have a chance to test it, please let me know your results.

thanks @kkossev, ive got two of the zss-zk-thl units setup on my desk here and have them connected with a hubitat c6, ive just set them to use your drive and ill see how they go.

Previously 1 of the units was connected using the Xiaomi Aqara Mijia Sensors and Switches by wayoftheweb. The unit just stopped reporting using that driver and appeared to lock up showing 0 for temp and 0 for humidity.

Sitting on my desk this morning ive seen that same uni reset a number of times .

Not really sure about the quality of these devices.

Ill see how both go with your driver and give feedback here

Thanks again

Thank you @benwiseman for the feedback!

Digging further, I read a lot of similar complaints about Moes ZSS-TK-THL device resetting itself when paired to zigbee hubs different than Tuya. There is a long discussion on this topic in github, where some much more clever guys are trying to reverse-engineer the communication protocol between the sensor and the original Tuya hub, where this device is working without any problems!. Seems like there is some kind of specific configuration or specific replies from the hub to the device, that are implemented in the Tuya hubs only. When this sensor is paired to anything else, after a certain period of time not receiving the expected responses from the zigbee coordinator - the unit resets itself. The visual effect is that the illuminance shown on the E0ink display is 0, but the device sends once also zero values for the temperature and the humidity.

So, Moes ZSS-TK-THL is 'semi-working' with Hubitat at the moment... :frowning: The only workaround that I am able to implement is to filter the zero readings after the reboots (that's the 'Filter zero readings' option in the driver). But visually the device will show 0 brightness, unit the emvironment illuminance is changed and the device refreshes the E-ink display... which is rather unpleasant.

ahh good to know smarter people than i are working on it. Thanks for your labour and smarts

1 Like

Hey, I have been otherwise occupied, however, just installed one now to test for you:

dev:3902021-09-07 12:49:56.826 infoT,H Plus L  illuminance changed to 110
dev:3902021-09-07 12:49:56.821 debugdescription: read attr - raw: 34120104000A000021BF4F, dni: 3412, endpoint: 01, cluster: 0400, size: 0A, attrId: 0000, encoding: 21, command: 0A, value: BF4F
dev:3902021-09-07 12:41:50.308 infoT,H Plus L  illuminance changed to 131
dev:3902021-09-07 12:41:50.304 debugdescription: read attr - raw: 34120104000A000021B652, dni: 3412, endpoint: 01, cluster: 0400, size: 0A, attrId: 0000, encoding: 21, command: 0A, value: B652
dev:3902021-09-07 12:40:58.272 infoT,H Plus L  illuminance changed to 165
dev:3902021-09-07 12:40:58.262 debugdescription: read attr - raw: 34120104000A000021A056, dni: 3412, endpoint: 01, cluster: 0400, size: 0A, attrId: 0000, encoding: 21, command: 0A, value: A056
dev:3902021-09-07 12:33:51.713 infoT,H Plus L  temperature changed to 25.7°C
dev:3902021-09-07 12:33:51.662 debugdescription: read attr - raw: 34120204020A0000290D0A, dni: 3412, endpoint: 02, cluster: 0402, size: 0A, attrId: 0000, encoding: 29, command: 0A, value: 0D0A
dev:3902021-09-07 12:32:46.234 infoT,H Plus L  illuminance changed to 145
dev:3902021-09-07 12:32:46.231 debugdescription: read attr - raw: 34120104000A0000216F54, dni: 3412, endpoint: 01, cluster: 0400, size: 0A, attrId: 0000, encoding: 21, command: 0A, value: 6F54
dev:3902021-09-07 12:32:44.679 infoT,H Plus L  illuminance changed to 121
dev:3902021-09-07 12:32:44.669 debugdescription: read attr - raw: 34120104000A0000215D51, dni: 3412, endpoint: 01, cluster: 0400, size: 0A, attrId: 0000, encoding: 21, command: 0A, value: 5D51
dev:3902021-09-07 12:25:19.132 infoT,H Plus L  illuminance changed to 145
dev:3902021-09-07 12:25:19.128 debugdescription: read attr - raw: 34120104000A0000216F54, dni: 3412, endpoint: 01, cluster: 0400, size: 0A, attrId: 0000, encoding: 21, command: 0A, value: 6F54
dev:3902021-09-07 12:25:11.243 infoT,H Plus L  illuminance changed to 113
dev:3902021-09-07 12:25:11.239 debugdescription: read attr - raw: 34120104000A0000213450, dni: 3412, endpoint: 01, cluster: 0400, size: 0A, attrId: 0000, encoding: 21, command: 0A, value: 3450
dev:3902021-09-07 12:24:17.097 infoT,H Plus L  temperature changed to 26.0°C
dev:3902021-09-07 12:24:17.013 debugdescription: read attr - raw: 34120204020A0000292C0A, dni: 3412, endpoint: 02, cluster: 0402, size: 0A, attrId: 0000, encoding: 29, command: 0A, value: 2C0A
dev:3902021-09-07 12:20:28.116 debugrefreshing Moes ZSS-ZK-THL battery status
dev:3902021-09-07 12:20:17.918 infoT,H Plus L  illuminance changed to 139
dev:3902021-09-07 12:20:17.914 debugdescription: read attr - raw: 34120104000A000021B753, dni: 3412, endpoint: 01, cluster: 0400, size: 0A, attrId: 0000, encoding: 21, command: 0A, value: B753
dev:3902021-09-07 12:20:16.339 infoT,H Plus L  illuminance changed to 107
dev:3902021-09-07 12:20:16.336 debugdescription: read attr - raw: 34120104000A000021474F, dni: 3412, endpoint: 01, cluster: 0400, size: 0A, attrId: 0000, encoding: 21, command: 0A, value: 474F
dev:3902021-09-07 12:20:13.187 infoT,H Plus L  illuminance changed to 146
dev:3902021-09-07 12:20:13.183 debugdescription: read attr - raw: 34120104000A0000218D54, dni: 3412, endpoint: 01, cluster: 0400, size: 0A, attrId: 0000, encoding: 21, command: 0A, value: 8D54
dev:3902021-09-07 12:20:04.521 infoT,H Plus L  illuminance changed to 119
dev:3902021-09-07 12:20:04.508 debugdescription: read attr - raw: 34120104000A0000211451, dni: 3412, endpoint: 01, cluster: 0400, size: 0A, attrId: 0000, encoding: 21, command: 0A, value: 1451
dev:3902021-09-07 12:18:48.109 debugrefreshing Moes ZSS-ZK-THL battery status
dev:3902021-09-07 12:18:06.853 debugrefreshing Moes ZSS-ZK-THL battery status
dev:3902021-09-07 12:18:03.841 debugrefreshing Moes ZSS-ZK-THL battery status
dev:3902021-09-07 12:18:03.835 debugsendZigbeeCommands(cmd=[zdo bind 3412 0x01 0x01 0x0400 {0C4314FFFE58A259} {}, delay 1186, zdo bind 3412 0x01 0x01 0x0402 {0C4314FFFE58A259} {}, delay 1187, zdo bind 3412 0x01 0x01 0x0405 {0C4314FFFE58A259} {}, delay 1189, zdo bind 3412 0x02 0x01 0x0400 {0C4314FFFE58A259} {}, delay 1186, zdo bind 3412 0x02 0x01 0x0402 {0C4314FFFE58A259} {}, delay 1187, zdo bind 3412 0x02 0x01 0x0405 {0C4314FFFE58A259} {}, delay 1189, he raw 0x3412 1 0x01 0x0400 {10 00 00 00 00}, delay 2000, he raw 0x3412 1 0x01 0x0402 {10 00 00 00 00}, delay 2000, he raw 0x3412 1 0x01 0x0405 {10 00 00 00 00}, delay 2000])
dev:3902021-09-07 12:18:03.828 debugConfiguring Moes ZSS-ZK-THL Reporting and Bindings
dev:3902021-09-07 12:18:03.827 debugupdated
dev:3902021-09-07 12:18:00.504 debugrefreshing Moes ZSS-ZK-THL battery status
dev:3902021-09-07 12:18:00.498 debugsendZigbeeCommands(cmd=[zdo bind 3412 0x01 0x01 0x0400 {0C4314FFFE58A259} {}, delay 1186, zdo bind 3412 0x01 0x01 0x0402 {0C4314FFFE58A259} {}, delay 1187, zdo bind 3412 0x01 0x01 0x0405 {0C4314FFFE58A259} {}, delay 1189, zdo bind 3412 0x02 0x01 0x0400 {0C4314FFFE58A259} {}, delay 1186, zdo bind 3412 0x02 0x01 0x0402 {0C4314FFFE58A259} {}, delay 1187, zdo bind 3412 0x02 0x01 0x0405 {0C4314FFFE58A259} {}, delay 1189, he raw 0x3412 1 0x01 0x0400 {10 00 00 00 00}, delay 2000, he raw 0x3412 1 0x01 0x0402 {10 00 00 00 00}, delay 2000, he raw 0x3412 1 0x01 0x0405 {10 00 00 00 00}, delay 2000])
dev:3902021-09-07 12:18:00.492 debugConfiguring Moes ZSS-ZK-THL Reporting and Bindings
dev:3902021-09-07 12:17:51.472 debugrefreshing Moes ZSS-ZK-THL battery status
dev:3902021-09-07 12:17:51.457 debugsendZigbeeCommands(cmd=[zdo bind 3412 0x01 0x01 0x0400 {0C4314FFFE58A259} {}, delay 1186, zdo bind 3412 0x01 0x01 0x0402 {0C4314FFFE58A259} {}, delay 1187, zdo bind 3412 0x01 0x01 0x0405 {0C4314FFFE58A259} {}, delay 1189, zdo bind 3412 0x02 0x01 0x0400 {0C4314FFFE58A259} {}, delay 1186, zdo bind 3412 0x02 0x01 0x0402 {0C4314FFFE58A259} {}, delay 1187, zdo bind 3412 0x02 0x01 0x0405 {0C4314FFFE58A259} {}, delay 1189, he raw 0x3412 1 0x01 0x0400 {10 00 00 00 00}, delay 2000, he raw 0x3412 1 0x01 0x0402 {10 00 00 00 00}, delay 2000, he raw 0x3412 1 0x01 0x0405 {10 00 00 00 00}, delay 2000])
dev:3902021-09-07 12:17:51.443 debugConfiguring Moes ZSS-ZK-THL Reporting and Bindings
dev:3902021-09-07 12:17:51.441 debugupdated
dev:3902021-09-07 12:17:04.735 infoZigbee parsed:[raw:34120204020A0000290D0A, dni:3412, endpoint:02, cluster:0402, size:0A, attrId:0000, encoding:29, command:0A, value:0A0D, clusterInt:1026, attrInt:0]
dev:3902021-09-07 12:10:23.285 infofingerprint profileId:"0104", endpointId:"01", inClusters:"0000,0001,0400", outClusters:"0019,000A", model:"TS0222", manufacturer:"_TYZB01_kvwjujy9" 
dev:3902021-09-07 12:10:23.270 infofingerprint profileId:"0104", endpointId:"01", inClusters:"0000,0001,0400", outClusters:"0019,000A", model:"TS0222", manufacturer:"_TYZB01_kvwjujy9" 
dev:3902021-09-07 12:10:23.267 infofingerprint profileId:"0104", endpointId:"01", inClusters:"0000,0001,0400", outClusters:"0019,000A", model:"TS0222", manufacturer:"_TYZB01_kvwjujy9" 
dev:3902021-09-07 12:10:23.182 traceZCL version:03
dev:3902021-09-07 12:10:23.174 traceSoftware Build Id:unknown
dev:3902021-09-07 12:10:23.173 traceModel:TS0222
dev:3902021-09-07 12:10:23.171 traceManufacturer:_TYZB01_kvwjujy9
dev:3902021-09-07 12:10:23.148 traceZCL version:03
dev:3902021-09-07 12:10:23.142 traceSoftware Build Id:unknown
dev:3902021-09-07 12:10:23.141 traceModel:TS0222
dev:3902021-09-07 12:10:23.139 traceManufacturer:_TYZB01_kvwjujy9
dev:3902021-09-07 12:10:23.137 traceZCL version:03
dev:3902021-09-07 12:10:23.131 traceSoftware Build Id:unknown
dev:3902021-09-07 12:10:23.130 traceModel:TS0222
dev:3902021-09-07 12:10:23.128 traceManufacturer:_TYZB01_kvwjujy9
dev:3902021-09-07 12:10:22.988 infoZigbee parsed:[raw:34120204050A0000213418, dni:3412, endpoint:02, cluster:0405, size:0A, attrId:0000, encoding:21, command:0A, value:1834, clusterInt:1029, attrInt:0]
dev:3902021-09-07 12:10:21.054 debuggetting info for unknown Zigbee device...
dev:3902021-09-07 12:10:07.912 debuggetting info for unknown Zigbee device...
dev:3902021-09-07 12:10:07.199 debuggetting info for unknown Zigbee device...
dev:3902021-09-07 12:10:05.185 debugconfigure() called...
dev:3902021-09-07 12:09:37.212 infoZigbee parsed:[raw:34120204050A000021931A, dni:3412, endpoint:02, cluster:0405, size:0A, attrId:0000, encoding:21, command:0A, value:1A93, clusterInt:1029, attrInt:0]
dev:3902021-09-07 12:09:27.146 infoZigbee parsed:[raw:34120204050A000021181D, dni:3412, endpoint:02, cluster:0405, size:0A, attrId:0000, encoding:21, command:0A, value:1D18, clusterInt:1029, attrInt:0]
dev:3902021-09-07 12:09:27.028 infoZigbee parsed:[raw:34120204020A0000292E0A, dni:3412, endpoint:02, cluster:0402, size:0A, attrId:0000, encoding:29, command:0A, value:0A2E, clusterInt:1026, attrInt:0]
dev:3902021-09-07 12:09:20.961 infoZigbee parsed:[raw:34120104000A0000213254, dni:3412, endpoint:01, cluster:0400, size:0A, attrId:0000, encoding:21, command:0A, value:5432, clusterInt:1024, attrInt:0]
dev:3902021-09-07 12:09:18.222 infoZigbee parsed:[raw:34120104000A0000217134, dni:3412, endpoint:01, cluster:0400, size:0A, attrId:0000, encoding:21, command:0A, value:3471, clusterInt:1024, attrInt:0]
dev:3902021-09-07 12:09:15.980 infoZigbee parsed:[raw:catchall: 0000 8005 00 00 0040 00 3412 00 00 0000 00 00 D9001234020102, profileId:0000, clusterId:8005, clusterInt:32773, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:3412, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[D9, 00, 12, 34, 02, 01, 02]]
dev:3902021-09-07 12:09:15.859 infoZigbee parsed:[raw:34120104000A0000213B55, dni:3412, endpoint:01, cluster:0400, size:0A, attrId:0000, encoding:21, command:0A, value:553B, clusterInt:1024, attrInt:0]
dev:3902021-09-07 12:09:13.390 infofingerprint profileId:"0104", endpointId:"01", inClusters:"0000,0001,0400", outClusters:"0019,000A", model:"TS0222", manufacturer:"_TYZB01_kvwjujy9" 
dev:3902021-09-07 12:09:13.276 traceZCL version:03
dev:3902021-09-07 12:09:13.268 traceSoftware Build Id:unknown
dev:3902021-09-07 12:09:13.266 traceModel:TS0222
dev:3902021-09-07 12:09:13.265 traceManufacturer:_TYZB01_kvwjujy9
dev:3902021-09-07 12:09:12.852 debuggetting info for unknown Zigbee device...
dev:3902021-09-07 12:09:11.762 infoZigbee parsed:[raw:34120204020A0000290D0A, dni:3412, endpoint:02, cluster:0402, size:0A, attrId:0000, encoding:29, command:0A, value:0A0D, clusterInt:1026, attrInt:0]
dev:3902021-09-07 12:09:10.952 infoZigbee parsed:[raw:34120104000A0000218657, dni:3412, endpoint:01, cluster:0400, size:0A, attrId:0000, encoding:21, command:0A, value:5786, `Preformatted text`clusterInt:1024, attrInt:0]
dev:3902021-09-07 12:09:10.837 debugconfigure() called...
dev:3902021-09-07 12:09:10.829 infoZigbee parsed:[raw:34120204050A000021C121, dni:3412, endpoint:02, cluster:0405, size:0A, attrId:0000, encoding:21, command:0A, value:21C1, clusterInt:1029, attrInt:0]

As I have 4 of the buggers currently one is on MQTT in home assistant and another in Smart Life Official to check for any disparity between data and performance.

1 Like

Thanks, @lusciouslukey !

What did you use for logging the communication between the device and the zigbee coordinator?

Meanwhile, I connected the ZSS-ZK-THL sensor to zigbee2mqtt and it working without visible problems for 2 hours!

I noticed the following in the logs:

Line 31064: debug 2021-09-08 20:21:48: Received Zigbee message from 'Moes TS0222 Z2M', type 'read', cluster 'genTime', data '["localTime"]' from endpoint 1 with groupID 0

Added a "zdo bind..." command for cluster 000A ,,,,, and now it has passed more than one hour without self-resting !! :slight_smile:

Fingers crossed! :sweat_smile:

ive had two connected since my last post, one keeps resetting quite often, the other appears stable. happy to log data if you tell me how.

Hi @benwiseman ,
I have now a second ZSS-ZK-THL device and I observe a similar inconsistent behavior. There was a configuration where one of the devices was working stable and did not reset/reboot for more than a day, now both devices reset each hour... I hope that comparing the different configurations and different drivers versions will help me to find out what could be the reason(s) for the issue.

I am using 'InfluxDB Loger' app in HE to feed the data to a database server running on a RaspberryPi and then Grafana for visualization. But you could use the HE community app 'Hubigraphs' for drawing a time-line charts ( see this link )

Mine looks like this:


and clearly shows how both devices are reset every one hour now... ( I have the "Filter zero readings" option turned off in the driver).

There's an interesting observation from some changes that I made today:

TS0222 (old ) : continues to reset every hour:

  • paired to a second HE hub (DEV);

  • about 12 meters between the hub and the device, 3 solid brick walls in between

  • just one other zigbee device in the same mesh, no zigbee repeaters!

  • shows in ChildAndRouteInfo table :
    Child Data
    child:[Button SYMFONISK, 16F4, type:EMBER_SLEEPY_END_DEVICE]
    child:[TS0222 (old) - DEV, 494C, type:EMBER_SLEEPY_END_DEVICE]

TS0222 (NEW) : DOES NOT RESET ! (for 14 hours till now):

  • paired to the main HE hub (Home);
  • less than 1 meter between the hub and the device,
  • a lot of other zigbee devices in the same mesh, 5 zigbee repeaters in total!
  • does not show in ChildAndRouteInfo table :
    not present in the 'Child Data' ( so no direct connection to the sensor?)
    *a strange entry in the Route Table :
    status:Active, age:64, routeRecordState:0, concentratorType:None, [null, 00E4] via [Power Plug Ikea TRADFRI , F9A5]

The driver code is one and the same for both devices. No filtering of the zero readings.

This is the graph: ( the resets are clearly seen as drops of the temperature and the humidity)

The only change for the second device named "Moes TS0222 (NEW)" is the position of the sensor - away from the hub (reboots) and close to the hub (works OK!)

For me, the most suspicious difference between the working and the not working (resetting) device is not the distance to the zigbee hub, but the presence (or not) of Zigbee repeaters in the same network.

So as a next step I will move the non-working device to be close to the hub that it is paired to. If this does not change anything (the device continue to reset ), next planned step is to add a Zigbee repeater to the DEV hub mesh and see what happens. The working device will stay as it is now, no changes of any type so that it is used as a reference.

A quick update - as expected, both devices that I have are working fine, without any restarts and false zero readings when the communication to HE goes through a Zigbee repeating device (mains powered) :

This fact doesn't make the Moes ZSS-ZK-THL (TS0222) device fully usable with HE hub, as there is no guarantee that the communication will always go through a repeater. I achieve this by placing a Zigbee repeater or Zigbee power plug close to the Moes brightness thermometer and then removing the battery, waiting >30 seconds and re-insterting the battery again. There is a high probability that few minutes later the sensor will start communicating to the HE hub via the repeating device, but this can never be guaranteed.

in my setup, my house is made of concrete, i have the HE several rooms away and theres many zigbee light switches inbetween, i also have 3 eero6 devices which have a zigbee mesh, im not sure if the HE network and the eero5 network are meshed together or work separately though.

im certain the ts0222s are not communicating directly with the HE in my case.

@benwiseman can you double-check your settings again?

In a browser, open http://192.168.0.66/hub/zigbee/getChildAndRouteInfo ( replace the IP address with your HE hub actual IP address). You should NOT see the name of your TS0222 sensors listed in the 'Child Data' section. If TS0222 devices are listed in this section this means they are communicating directly to the hub and you have to re-connect the sensors again - very close to the nearest zigbee light switch, that is paired to the HE hub. The eero6 zigbee mesh is different, even if it happens to work on the same channel as HE. Mains powered devices that are paired to eero6 zigbee network are not used as repeaters in HE.

And last, double-check you are using the driver that I posted 2 weeks ago; your device information page should look like this:


Latest published version is 1.2.2 ( link posted again).

Parent child parameters
EzspGetParentChildParametersResponse [childCount=0, parentEui64=0000000000000000, parentNodeId=65535]

Child Data

Neighbor Table Entry
[Hall Light, 34EC], LQI:254, age:4, inCost:1, outCost:6
[Bathroom, 6EC0], LQI:254, age:3, inCost:1, outCost:6
[Lounge Front Door, 8384], LQI:254, age:4, inCost:1, outCost:7
[Main bedroom light, C633], LQI:254, age:4, inCost:1, outCost:7
[null, DDA7], LQI:254, age:4, inCost:1, outCost:7
[Lounge Light, EE75], LQI:254, age:4, inCost:1, outCost:6

Route Table Entry
status:Active, age:64, routeRecordState:0, concentratorType:None, [null, 1663] via [Lounge Light, EE75]
status:Active, age:64, routeRecordState:0, concentratorType:None, [null, A2C9] via [Main bedroom light, C633]
status:Active, age:64, routeRecordState:0, concentratorType:None, [Bathroom, 6EC0] via [Hall Light, 34EC]
status:Active, age:64, routeRecordState:0, concentratorType:None, [null, A44C] via [Lounge Light, EE75]
status:Active, age:64, routeRecordState:0, concentratorType:None, [null, FA36] via [Lounge Light, EE75]
status:Active, age:64, routeRecordState:0, concentratorType:None, [null, 9ACC] via [Main bedroom light, C633]
status:Active, age:64, routeRecordState:0, concentratorType:None, [Lounge Light, EE75] via [Lounge Light, EE75]
status:Active, age:64, routeRecordState:0, concentratorType:None, [Lounge Front Door, 8384] via [Lounge Front Door, 8384]
status:Active, age:64, routeRecordState:0, concentratorType:None, [null, 8205] via [Lounge Light, EE75]
status:Active, age:64, routeRecordState:0, concentratorType:None, [null, F622] via [Lounge Light, EE75]
status:Active, age:64, routeRecordState:0, concentratorType:None, [Main bedroom light, C633] via [Lounge Light, EE75]
status:Active, age:64, routeRecordState:0, concentratorType:None, [Spare Room TH, 954F] via [Main bedroom light, C633]
status:Active, age:64, routeRecordState:0, concentratorType:None, [null, D56C] via [Lounge Light, EE75]
status:Active, age:64, routeRecordState:0, concentratorType:None, [null, DDA7] via [Lounge Front Door, 8384]
status:Active, age:64, routeRecordState:0, concentratorType:None, [Hall Light, 34EC] via [Hall Light, 34EC]
status:Unused

thats one of the ts0222s

ill update the driver

ok i was on 1.2.0 now on 1.2.2, ill keep an eye on things and let you know what i find

New version 1.2.3 of the driver was uploaded today. Disabling any clusters bindings and reporting configurations seems to improve the stability a lot! Now my 2 x TS0222 are paired to two different HE hubs directly (not using any repeaters or mains-powered Zigbee devices). But we will need few weeks of monitoring before we can say it works stable or not.

Driver updates can be handled automatically if Hubitat Package Manager is used (it's a great must-have application!). As this driver is still experimental and not 100% proven to be working in all possible configurations, a 'custom repository' must be added :
https://raw.githubusercontent.com/kkossev/Hubitat/main/repository.json

Then the driver can be found in the Hubitat Package Manager 'Install', 'Browse by tags' : 'Zigbee, "Moes ZSS-ZK-THLTS0222)"

The driver is now available for installation from the Hubitat Package Manager community app.

For new installations, you can search by keyword TS0222. For existing manual installations of the same driver, you can use "Match Up" function to ensure you will be notified of future updates.

1 Like

There is a new version 1.3.0 release that shows promising results in regards to stability.
The update is available from HPM.

If anyone still keeps this thing running or can take it out of the drawer - please let me know how if it works stable, without restarts, and without stopping the temperature and humidity reports after an hour, or after a day, or after a week.

I just setup one of these yesterday with your code. It did reset itself several times, however after fiddling with it (removed battery, repeatedly pressed the red button) I got it talking to HE, it reported lux, temp and humidity and seemed stable. However this morning I found it flashing black/white. I tried removing and replacing the battery but it just kept flashing. I then hooked it up to my bench power supply at 3v and it came back to life. Looks like the battery was drained overnight. Maybe it started resetting itself over and over until the battery drained? Maybe the battery drained down and it couldn't keep itself powered on? My next step will be to keep it on the bench supply and see if it resets itself. Will report back in a day or two.

1 Like