Third Reality Water Leak Sensor: Add to the hub but doesn't report leaks

šŸ›Žļø Get Help Devices
1

I decided to add an additional Third Reality water leak sensor to my setup. I already had one installed for over a year and it still functions properly. However, I just purchased 2 more and although they connect to my C7 hub they do not report back when wet. Upon adding them I get the following in the log:

dev:13782024-09-08 11:50:27.907 AMwarnconfigure...
dev:13782024-09-08 11:49:34.773 AMinfoGeneric Zigbee Moisture Sensor (no temp) battery is 100%
dev:13782024-09-08 11:49:34.770 AMdebugdescMap: [raw:A83F0100010A210020C8, dni:A83F, endpoint:01, cluster:0001, size:0A, attrId:0021, encoding:20, command:01, value:C8, clusterInt:1, attrInt:33]
dev:13782024-09-08 11:49:34.767 AMdebugparse: read attr - raw: A83F0100010A210020C8, dni: A83F, endpoint: 01, cluster: 0001, size: 0A, attrId: 0021, encoding: 20, command: 01, value: C8
dev:13782024-09-08 11:49:34.298 AMinforeporting configuration for Power Configuration (cluster 0x0001), attribute 0x0021 failed, unsupported attribute
dev:13782024-09-08 11:49:34.296 AMdebugdescMap: [raw:catchall: 0104 0001 01 01 0040 00 A83F 00 00 0000 07 01 86002100, profileId:0104, clusterId:0001, clusterInt:1, sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:A83F, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:07, direction:01, data:[86, 00, 21, 00]]
dev:13782024-09-08 11:49:34.292 AMdebugparse: catchall: 0104 0001 01 01 0040 00 A83F 00 00 0000 07 01 86002100
dev:13782024-09-08 11:49:34.276 AMdebugskipped:[raw:catchall: 0000 8021 00 00 0040 00 A83F 00 00 0000 00 00 BF00, profileId:0000, clusterId:8021, clusterInt:32801, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:A83F, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[BF, 00]]
dev:13782024-09-08 11:49:34.273 AMdebugdescMap: [raw:catchall: 0000 8021 00 00 0040 00 A83F 00 00 0000 00 00 BF00, profileId:0000, clusterId:8021, clusterInt:32801, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:A83F, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[BF, 00]]
dev:13782024-09-08 11:49:34.269 AMdebugparse: catchall: 0000 8021 00 00 0040 00 A83F 00 00 0000 00 00 BF00
dev:13782024-09-08 11:49:33.781 AMinforeporting configuration for Power Configuration (cluster 0x0001), attribute 0x0020 failed, unsupported attribute
dev:13782024-09-08 11:49:33.777 AMdebugdescMap: [raw:catchall: 0104 0001 01 01 0040 00 A83F 00 00 0000 07 01 86002000, profileId:0104, clusterId:0001, clusterInt:1, sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:A83F, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:07, direction:01, data:[86, 00, 20, 00]]
dev:13782024-09-08 11:49:33.771 AMdebugparse: catchall: 0104 0001 01 01 0040 00 A83F 00 00 0000 07 01 86002000
dev:13782024-09-08 11:49:33.374 AMdebugskipped:[raw:catchall: 0000 8021 00 00 0040 00 A83F 00 00 0000 00 00 BD00, profileId:0000, clusterId:8021, clusterInt:32801, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:A83F, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[BD, 00]]
dev:13782024-09-08 11:49:33.365 AMdebugdescMap: [raw:catchall: 0000 8021 00 00 0040 00 A83F 00 00 0000 00 00 BD00, profileId:0000, clusterId:8021, clusterInt:32801, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:A83F, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[BD, 00]]
dev:13782024-09-08 11:49:33.359 AMdebugparse: catchall: 0000 8021 00 00 0040 00 A83F 00 00 0000 00 00 BD00
dev:13782024-09-08 11:49:31.297 AMdebugdescMap: [raw:catchall: 0104 0500 01 01 0040 00 A83F 00 00 0000 0B 01 0000, profileId:0104, clusterId:0500, clusterInt:1280, sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:A83F, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:0B, direction:01, data:[00, 00]]
dev:13782024-09-08 11:49:31.294 AMdebugparse: catchall: 0104 0500 01 01 0040 00 A83F 00 00 0000 0B 01 0000
dev:13782024-09-08 11:49:30.780 AMdebugskipped:[raw:A83F0100000808002001, dni:A83F, endpoint:01, cluster:0000, size:08, attrId:0008, encoding:20, command:0A, value:01, clusterInt:0, attrInt:8]
dev:13782024-09-08 11:49:30.777 AMdebugskipped:[raw:A83F010000180040420876312E30302E3536, dni:A83F, endpoint:01, cluster:0000, size:18, attrId:4000, encoding:42, command:0A, value:v1.00.56, clusterInt:0, attrInt:16384]
dev:13782024-09-08 11:49:30.774 AMdebugdescMap: [raw:A83F0100000808002001, dni:A83F, endpoint:01, cluster:0000, size:08, attrId:0008, encoding:20, command:0A, value:01, clusterInt:0, attrInt:8]
dev:13782024-09-08 11:49:30.771 AMdebugdescMap: [raw:A83F010000180040420876312E30302E3536, dni:A83F, endpoint:01, cluster:0000, size:18, attrId:4000, encoding:42, command:0A, value:v1.00.56, clusterInt:0, attrInt:16384]
dev:13782024-09-08 11:49:30.768 AMdebugparse: read attr - raw: A83F0100000808002001, dni: A83F, endpoint: 01, cluster: 0000, size: 08, attrId: 0008, encoding: 20, command: 0A, value: 01
dev:13782024-09-08 11:49:30.765 AMdebugparse: read attr - raw: A83F010000180040420876312E30302E3536, dni: A83F, endpoint: 01, cluster: 0000, size: 18, attrId: 4000, encoding: 42, command: 0A, value: 0876312E30302E3536
dev:13782024-09-08 11:49:29.275 AMdebugdescMap: [raw:catchall: 0104 0500 01 01 0040 00 A83F 00 00 0000 04 01 00, profileId:0104, clusterId:0500, clusterInt:1280, sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:A83F, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:04, direction:01, data:[00]]
dev:13782024-09-08 11:49:29.271 AMdebugparse: catchall: 0104 0500 01 01 0040 00 A83F 00 00 0000 04 01 00

Here is the endpoint I'm seeing:

endpointId: 01
application: 38
manufacturer: Third Reality, Inc
model: 3RWS18BZ

My working one looks like this:

endpointId: 01
application: 17
firmwareMT: 1233-D3A3-0000001F
manufacturer: Third Reality, Inc
model: 3RWS18BZ
softwareBuild: 00000031

Updating the software does nothing, removing it and reading it makes no difference nor does changing the diver.

C7 running on: 2.3.9.177

2

Do you see anything in the Debug logs when you remove the batteries for 30 seconds and then install them again?

3

Nothing in the log. However, if I remove the batteries and insert them again, the blue light continues to flash blue and then shut off after about a minute.

4

The device has fallen off the Zigbee network.

As you have a C-7 hub, the workaround that works for me is to reboot the hub, then pair the Zigbee 3.0 device again at a close distance to the hub, as soon as the hub UI becomes active.

2 minutes after pairing, check if the device stays connected, using the same procedure (removing and reinstalling the batteries).

5

I'll give it a shot

1 Like
6

Unfortunately, it didn't make a difference. Removed the device, rebooted, readded, waited a couple of minutes, pulled out the batteries, and waited about 30 seconds. Same results... I did have the device about 12 inches from the C7.

7

Removing the device is not necessary, I should have bet more clear that ā€˜pair againā€™ means ā€˜pair the device for a second time, without removing itā€™.

I donā€™t have more ideas at the moment, other than to try pairing 2-3 more times (without removing the device).

My speculation is that the new batches of TR leak sensors are produced using new Zigbee SoC , that is problematic to pair to HE via Zigbee 3.0 repeaters/routers.

8

I did this the second time and repaired it without removing and it just created a new device with the same problems. Your assumption may be correct, I'm going to try again and if it doesn't work I'll be sending them back. Thanks for your help.

9

I had trouble with some Tuya leak sensor which were also zigbee. Seemed like they were paired but no activity in the logs when removing batteries.

The double luck voodoo process got them all paired and working properly.

Double luck vodoo

1 Like
10

The double luck voodoo is only possible for the C-8 models, while William has a C-7....

11

Unfortunately, the C7 doesn't have that functionality.

12

@kkossev I believe the problem is with the driver, I switched it to Generic Zigbee Moister Sensor and it works. If I move it back it stops work but moving it back again allows it work... :shushing_face:

13

Which is the other driver?

14

The Generic Zigbee Moister Sensor (no temp), which is chosen by default when adding the device.

1 Like
15

That's kinda strange... But I have seen all kinds of strange Zigbee device behaviors, so everything is possible. : )

The most important thing is to have it working and go ahead using the device in your autoamtions.

1 Like
16

Just did the same thing with the 2nd one and it worked as well, crazy!

17

You might want to try the user driver. Third Reality Water Sensor by tmastersmart on Package Mgr. I'm using it with 7 or 8 Third Reality Water Sensors on a C8 and they stay connected and are reliable.

2 Likes
18

@bbrannon thanks for the recommendation, I'm going to give it a couple of weeks, and if it fails on me I'll try out that driver.

19

Good tip. Thats a nice driver!

1 Like