Also, I tried this on my devices that are fully supported with this driver and I am able to change the values and save them so I suspect it's not related to Hubitat UI.
I ordered a few of these based on this discussion (can't beat the price at $9!). However, they still seem pretty spammy - maybe that's the nature of presence sensors? My Linnptech ones (which I'm not using in a prod capacity anymore as they would disconnect periodically requiring a device power cycle) has around 13k messages for a full cycle. The ones I linked earlier from Amazon hit 120K messages per day in my zigbee stats (I replaced them with these). These are at 18k messages after about 14 hours (I assume it's a 24h view?). So far though, functionally they seem solid, if maybe a slight pause in detection triggering compared to some other models I've tried.
Curious which devices folks are having the most luck with (least spammy, reliable connection, etc.)? Also curious if folks have any insights into how much message traffic is too much - e.g. what ends up having an impact on your hub? Is having a bunch of sensors with 40k messages per day a problem, or not really?
As most of these are USB powered how are you getting USB power to them if they are on the ceiling or on the walls?
Was thinking of replacing some of my motion sensors (all battery powered) with these.
I have mounted some of my mmWave sensors on top of a shelf to keep the cables out of sight, making them less visible to my wife. When mounted at such a height, the sensor must be tilted downward towards the floor for optimal performance :
(Aqara FP2 sensor)
There is a second mmWave sensor (Tuya) hidden behind the same cabinet wooden door:
It is a 5.8GHz radar, which are less prone to loosing sensitivity when hidden this way.
4 Likes
I have discovered (after a few power outages last week) that if the device loses power, both radarSensitivity and staticDetectionSensitivity reset to zero, which impacts its operation. I tested this by using Set Par and Preferences to configure these attributes and then unplugging the device. Upon restarting, both values returned to zero. Unfortunately, it seems my earlier optimism about resolving this issue was premature.
I can recall similar complaints (preferences not retained after cycling the power supply) in Zigbee2MQTT-related posts.
A potential solution would be to intercept the device reboot event and automatically send all the configured parameters in the driver code.
I can experiment with this idea the days after HE fixes the problem, which does not allow user driver code to be saved when it includes library files. Currently, this driver can not be modified.
2 Likes
Thank you for the update! Once HE resolves the issue with saving user driver code, let me know when you're able to apply the fix, and I'll gladly test it for you. In the meantime, keep up the excellent work!"
1 Like
I've been thinking about this and I believe I can write a webCoRE piston that resets the settings whenever either value changes to zero, along with a check every half hour to ensure they remain correct.
1 Like
On this Page, there are two Zigbee versions, which one is recommended and functional for use with HE or both the same ?
If I want presence and temperature, is there some other better one to use?
None of the Tuya mmWave sensors are reporting temperature.
It is not possible to identify a Tuya device based on a picture (there are at least 2 x 10 = 20 different mmWave sensor models in the same form factor cabinets...). At this price, I can only speculate that these are the old, spammy models.
If you really need an inbuilt temperature sensor inside a mmWave device, I can recommend this one:
A cheaper alternative (w/o temperature reporting) :
This battery-powered mmWave sensor is also very good and not spammy :
AliExpress : (link) Attention: there are two models in the same cabinet - the cheap PIR only sensor and the more expensive PIR+24GHz radar.
I should probably move it on top of the first post in this thread. I have it working on 2xAAA cheap batteries for several months now.
1 Like
One of my sensors has been acting oddly recently and would be stuck in "active" with Human Motion State "small" indefinitely even when no one would be downstairs to trigger that. I compared it to the same sensor at a different location that is working fine and noticed that it may be because I had the motion detection sensitivity and small motion detection sensitivity set to 8. It's just odd because the sensor was working fine before. Changing them back to 6 works now. I'll just have to test to make sure it's still sensitive to someone sitting on the toilet for extended periods of time. That was the reason I had the sensitivity set to 8.
Hi everyone, could you please help me?
I have a "TS0601_TZE204_clrdrnya" installed and running with this kkossev Driver (Thanks kkossev for it) configured with the auto-detect profile (SBYXOLM6) but even though every time I enter the space where it is located it detects me without problems, there are many times a day where the device detects movement when there is none. Could it have to do with the Drivers? I have already configured it at both sensitivity extremes and it is the same... Thanks!
mmWave sensors can be difficult to tune to completely avoid false positive triggers.
Are you certain it can’t be something like a fan, or curtains that’s causing it to trigger?
1 Like
No, nothing really... It's the kitchen of the house and the only thing that can vary over time is the brightness of the room. It detects movement even when everything is off.
Just to be sure, which is the lowest sensitivity setting (1 or 9)?
Hi kkossev
This is a follow-up regarding our discussion on the ZigBee Device Connectivity Issue. I believe this forum is more pertinent for discussing these devices since it relates to the release of the driver we had been talking about, which I am currently using with various devices
I'm specifically referring to the following devices:
- Device 678: Media Room Presence Sensor
- Device Profile: Tuya Human Presence Detector YA4FTOW4
- Device Type: Tuya Zigbee mmWave Sensor
- Device Version: 3.3.4 (2024/11/17 7:42 PM)
- Model: TS0601 _TZE200_ya4ft0w4 (C-7 2.4.0.151)
- Device 677: Office Presence Sensor
- Device Profile: Tuya Human Presence Detector YA4FTOW4
- Device Type: Tuya Zigbee mmWave Sensor
- Device Version: 3.3.4 (2024/11/17 7:42 PM)
- Model: TS0601 _TZE204_ya4ft0w4 (C-7 2.4.0.151)
- Device 667: Living Room Presence Sensor
- Device Profile: Tuya Human Presence Detector YA4FTOW4
- Device Type: Tuya Zigbee mmWave Sensor
- Device Version: 3.3.4 (2024/11/17 7:42 PM)
- Model: TS0601 _TZE204_ya4ft0w4 (C-7 2.4.0.151)
I’ve noticed something interesting regarding Device 678 (Media Room Presence Sensor) which uses a TZE200 model. As mentioned in my previous post, I've been using the TZE204 driver for this device, and it seems that I can update and maintain the Distance Reports preferences set to disable along with the other attributes . However, the TZE204 model does not retain the Distance Reports preferences set to disable.
I'm wondering if, similar to how the radarSensitivity and staticDetectionSensitivity can be updated using Set Par on the T2E204 and the T2E200 models, if it is possible to use this to also update the Distance Reports? If so how would I do that?
Update: It looks like after about 10 minutes, the T2E200 Distance Reports reverted back to 'Enabled'
Hi @kkossev
Is it expected behavior to have motion "inactive" while human is present or moving?
dev:2882025-02-02 15:57:34.880infoRadar humanMotionState is present
dev:2882025-02-02 15:57:34.868infoRadar Detected motion
dev:2882025-02-02 15:57:28.477infoRadar Motion reset to inactive after 0s
dev:2882025-02-02 15:57:28.418infoRadar humanMotionState is moving
dev:2882025-02-02 15:57:28.411infoRadar Detected motion
dev:2882025-02-02 15:57:19.930infoRadar Motion reset to inactive after 0s
dev:2882025-02-02 15:57:19.876infoRadar humanMotionState is present
dev:2882025-02-02 15:57:19.861infoRadar Detected motion
dev:2882025-02-02 15:57:11.366infoRadar Motion reset to inactive after 0s
dev:2882025-02-02 15:57:11.310infoRadar humanMotionState is moving
dev:2882025-02-02 15:57:11.302infoRadar Detected motion
dev:2882025-02-02 15:56:05.913infoRadar Motion reset to inactive after 0s
dev:2882025-02-02 15:56:05.851infoRadar Detected motion
dev:2882025-02-02 15:55:55.909infoRadar Motion reset to inactive after 0s
dev:2882025-02-02 15:55:55.846infoRadar Detected motion
dev:2882025-02-02 15:55:45.925infoRadar Motion reset to inactive after 0s
The logs are bit weird to me.
Device I'm using is
Device Data
Application
4A
Manufacturer
_TZE204_ya4ft0w4
Model
TS0601
Tuya Version
1.0.10
1 Like
No, there is something wrong in the driver logic... 
Please send me some more detailed Debug logs (you can send the logs in a DM to me) :
- enable the Debug logging
- walk into the room where this device is, stay 5 seconds, leave the room.
I will need the Debug logging of the whole sequence to find out why the motion is reset to inactive.
Thank you for the logs and the testing. I have made some small tweaks in the code related to TS0601 _TZE204_ya4ft0w4, hopefully it works more stable now.
This device has problems retaining some parameters, or it may be just buggy reporting back to the hub. Very similar issues are reported in GitHub for Z2M implementation, I will keep an eye on it.
Latest version 3.4.0 is now pushed for update via HPM.
The bad news is that this driver code reached the maximum allowed size for static data structures again (the deviceProfilesV3 static map in this driver). I made some optimizations in the code, but these were not enough. I had to comment out some fingerprints of devices that I think are rarely or never used...
The above code size problem means that adding new Tuya mmWave sensor models is almost impossible at this time. Surely there is a solution, however, it will require a significant refactoring of the code and the common libraries - something that will take time.
1 Like
