[RELEASE] Linptech/Moes 24Ghz Presence Sensor ES1 ( TS0225 _TZ3218_awarhusb ) drivers

⚙️ Custom Apps and Drivers Custom Drivers
861

Removed the sensor, factory reset and added it back to the hub and these showed up in the logs:

dev:1554 2024-04-27 13:09:41.122 warndescription logging is: true
dev:1554 2024-04-27 13:09:41.121 warndebug logging is: true
dev:1554 2024-04-27 13:09:41.120 infoupdated...
dev:1554 2024-04-27 13:08:58.206 debugmotion timeout response:10
dev:1554 2024-04-27 13:08:56.622 debugmotion timeout response:10
dev:1554 2024-04-27 13:08:55.779 debugskipped:[raw:catchall: 0000 8021 00 00 0040 00 82F7 00 00 0000 00 00 6F00, profileId:0000, clusterId:8021, clusterInt:32801, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:82F7, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[6F, 00]]
dev:1554 2024-04-27 13:08:55.560 warndescription logging is: true
dev:1554 2024-04-27 13:08:55.559 warndebug logging is: true
dev:1554 2024-04-27 13:08:55.558 infoupdated...
dev:1554 2024-04-27 13:08:54.638 debugmotion timeout response:10
dev:1554 2024-04-27 13:08:54.345 infoLinptech Human Presence Sensor is active
dev:1554 2024-04-27 13:08:53.112 debugdetection distance:600 Centimeters
dev:1554 2024-04-27 13:08:52.711 debugstatic sensitivity:5
dev:1554 2024-04-27 13:08:52.360 infoLinptech Human Presence Sensor is inactive
dev:1554 2024-04-27 13:08:52.314 debugmotion sensitivity:5
dev:1554 2024-04-27 13:08:51.915 debugdistance:0 Centimeters
dev:1554 2024-04-27 13:08:51.107 debugskipped:[raw:catchall: 0000 8021 00 00 0040 00 82F7 00 00 0000 00 00 6700, profileId:0000, clusterId:8021, clusterInt:32801, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:82F7, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[67, 00]]
dev:1554 2024-04-27 13:08:51.107 infoLinptech Human Presence Sensor is active
dev:1554 2024-04-27 13:08:50.695 debugskipped:[raw:catchall: 0000 8021 00 00 0040 00 82F7 00 00 0000 00 00 6600, profileId:0000, clusterId:8021, clusterInt:32801, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:82F7, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[66, 00]]
dev:1554 2024-04-27 13:08:50.472 warnconfigure...

862

Switch back to the ‘Device’ driver.
Any logs when clicking on ‘Get Info’?

863

Yup... one entry:
dev:15542024-04-27 13:22:38.681debuggetting info for unknown Zigbee device...

864

You are among the minority of HE users who have problems keeping some Zigbee 3.0 devices connected to the C-8 Zigbee 3.0 hub.

865

Any recommendations to remedy this problem? My other Sylvania LED RGBW strips work as intended - yes, they are older Zigbee devices.

866

In a similar case, @bobbyD was able to help.

867

That button is for putting the sensor in pairing mode as far as I know. You don’t need to push it otherwise. The sensor is powered, so doesn’t need woken up.

1 Like
868

Is it possible that you are holding the Linptech sensor button for too long, and it resets and goes into pairing mode (disconnecting from the hub )?

As said above, for mains/dc-powered devices there is no need to press the device button when you click on the 'Get Info' web page button.

The typical 'effect' of loosing the Zigbee connection with the 'Device' driver pre-assigned is that during the first seconds (30..60) after pairing the device will respond to the 'Get Info' command and you will see fingerprint logs every time you click on the button. Less than a minute later the device will stop responding.

869

The documentation with the sensor said press the button for 5 seconds to perform factory reset. That's what I did. I read through the link you shared - Zigbee pairing issues. I've changed the channel to 26 and also restarted the Zigbee radio. Let's see if that helps.
If not, @bobbyD ... is there anything else you can recommend?

1 Like
870

26 is normally not a good Zigbee channel, you should usually be on 20 or 25 when you're at the upper end of the Zigbee channels (where most of us end up).

Channel 26 is transmission power limited in North America (and possibly elsewhere), and not supported by all devices

2 Likes
871

I chose 26 and I'm not going to change it again; but I understand 26 can be reduced power in some regions. @bobbyD suggested 23/24 being better. reasons why I won't be changing resulted in me having to 're pair' a dozen battery temperature sensors that didn't make the switch to a new channel. everything is stable again now.

2 Likes
872

Falls under the "if it ain't broke" clause. :slight_smile:

But I wouldn't generally recommend 26, at least for folks in the US.

1 Like
873

mine was a pairing fault that wasn't resolved till I changed channels; even if I choice of channel was dubious. being in Europe I'm not aware I was affected by the choice.

1 Like
874

Next time try to just take the batteries out for a min, might save you time and effort having to repair sensors. I also don't recommend channel 26 in the US. Like you said, 23, 24, 25 have been better choices for many folks, including my own experience.

3 Likes
875

Must be... you are still here... :rofl:

1 Like
876

Got the replacement sensor from Amazon. That is reporting the motion accurately. :slight_smile:
I did change the channel to 23 & have left it there.
@kkossev & @bobbyD ... the sensor is working as expected & it also shows up on the Zigbee device graph. Looks like I had received a broken sensor originally! Thanks for helping me troubleshoot it.
One additional Q - when I tried building a rule, this doesn't show up under presence sensors for me to use it as a trigger. It shows up only under motion sensors.
I've removed @kkossev 's driver before adding the replacement sensor and am using the default/built-in driver. Should I download and re-install @kkossev 's driver for it to show up as a presence sensor?

2 Likes
877

Just like any other mmWave sensor (or PIR sensor), it's only ever going to show motion.

Perhaps this will change sometime in the future, but for now, "Presence" is used for geofence-based away/home related stuff, e.g. your cell phone is a presence sensor.

2 Likes
878

Glad you got the unit replaced.

That, as Hydro noted, is how they are integrated into the hub, as motion sensors. Presence (as I think about it) tends to be person-specific, e.g., "Tom is home" and these sensors don't have that capability to ID specific people. Their Static Sensitivity capablity does allow them to monitor/confirm presence of someone w/out motion, but no ID of that person, so makes sense (to me, anyway) that overall they are identified as motion sensors.

image

I would recommend using the driver that is purpose-built for this device, links to it at the top of this topic, but best to install it from HPM. It will still show up as a motion sensor in your rules, and they solved my issues by being able to accurately report my wife's presence in the office when she sits not moving for many minutes. So my automations don't turn off the lights while she/anyone else is sitting in there sitting still. :slight_smile:

3 Likes
879

Thanks. I'll play around with it to see if the default drivers will do the trick. My use case is similar - my wife sitting with a blanket covered and watching TV... so a motion sensor is useless. If the default drivers let it pickup the static sensitivity, I'll leave it the way it is and build rules around it. If not, I will download Krassimir's driver via HPM :+1:

1 Like
880

They do. Motion doesn’t become inactive until static is inactive. I switched to the built in drivers for my 3 Linptech sensors and they have the same functionality.

1 Like