@lpakula what driver did you end up using for these?
S.
@lpakula what driver did you end up using for these?
S.
This driver, and I would have selected the "TS0225_2AAELWXK_RADAR" model.
Thanks! I guess I should have asked, what profile? But you answered that anyway!
I had that one selected too, and it seems to work well so far!
Thanks!
S.
It's almost identical. There are 3-DP's the driver didn't support (not sure what they were for), and the only other difference was "humanMotionState" value. These ones add a moving towards/moving away field that the driver will just say "null" when it detects them.
Unfortunately, mine(Kitchen Radar) is very, very chatty. I appear to have the same one you picked up. I originally put it to the driver you did but have been experimenting. I should also point out that I'm not having any issues. I've just been watching it since I put it in to replace a Sonoff radar I suspected was causing zigbee reboots. I haven't had one since I installed this 2 weeks ago. Might turn out to be a red herring, if you will, but we'll see.
How long as the hub been up? For me, that's the activity I see for a hub that had booted 7 days ago.
That's actually irrelevant to the data provided but it's been up 5 days. Since I posted that it's up to 104078 messages and no one is home. The next device is at 2625. That is very, very chatty to me. I could have my hub up for months and nothing else would come close to that number. Our opinions of chatty devices are very different. Do you have other devices with a higher message count? I'm curious as to what the next device in your list has.
It's actually quite relevant. These devices do report luminosity as well, so there are continuous updates as lighting changes over the day. What was your Sonoff radar for messaging? Was that the 24GHz or 5.8GHz style?
Here is close to 7-days for me:
And if you want real chatty, thanks Google for your last POS chromecast update that floods my network with UDP spam:

Actually, it's not. IMHO, you have ridiculously chatty devices.
What are you comparing mmWave radars to? Did they have light sensors and human body detection?
I've yet to see a HPD sensor that is less than 10k messages per day. The ones that the @kkossev tagged as "chatty / avoid" in the driver (I own both BTW) were close to 100k messages per day. I have since decommissioned them due to it bogging zigbee if a person is continuously within their detection range.
Looking for context since it seems you are comparing to PIR sensors without light sensors which is comparing apples and oranges IMO.
That is a valid point. But I was comparing, in my head, to my previous Sonoff. I don't ever remember the message count being that much greater than the next device and I watched it for months. I have plans to put it back to see if it does cause any reboots. I'll keep you posted.
I'd be interested in seeing what those do. The Tuya ones are all wired, and they seem to like to "abuse the network" more since there is no battery penalty for transmissions.
Sorry if this has been asked before but I have a Tuya Battery Powered TS0601 TZE200_rhgsbacq its a 4 in 1 sensor with a 10g mmwave sensor.
The 4 in 1 driver does work but it seems to only have support for pir sensors and does not allow me to configure the mmwave sensor there are no settings to configure sensitivity or distance.
Hi @kkossev .
I've purchased a mmWave Motion Sensor.
It was initially discovered as a 'Device' so I changed it to this driver to try.
It's doesn't work correctly with this driver but does with your Tuya 4 in 1 driver.
I thought I'd post what I am seeing here in case you want to include it into this driver.
Here is the relevant information.

Here is the 'Get Info' logs.
When using this driver I see the following in the logs.
I have started working on a solution. The first attempt failed, but I have new ideas now ![]()
Currently, this driver supports more than 150 (one hundred and fifty!) different unique manufacturer/model mmWave devices, grouped in 27 (twenty-seven) groups ("deviceProfiles"). The inbuilt JSON configuration data in this driver has reached the maximum allowed 64K of static data in Hubitat, which is why new mmWave radars cannot be added anymore.
The next attempt will be to move the JSON configuration as a file stored locally on the Hubitat File Storage.
BOOM!!!!! Back of the net!!!!. (Sorry. English Footy term).
Looks to be working OK.
Here's the logs that shows it all.
Update 09/07/2025:
First successful tests - the one-time loading (after HE hub reboot) of all the different mmWave radar device 'Product Profiles' from a locally stored JSON file is now working OK!
The JSON file : Hubitat/Drivers/Tuya Zigbee mmWave Sensor/deviceProfilesV4_mmWave.json at deviceProfileV4 · kkossev/Hubitat · GitHub
New mmWave devices could be added by simply clicking on an 'Update DeviceProfiles from GitHub' button on the driver Commands tab - no need to update the driver code.
Nice work!
I have decided to publish the current beta version code, as I have been testing it during the last 3 days with 4 different mmWave sensors on two different hubs (C-7 and C-8-Pro) and it has been working as expected for me. What is not ready yet is the automatic first-time-only loading of the default JSON file from GitHub - in this first version you will need to manually press the button after you update or install the driver :

In the next version, I will make this initial loading of the mmWave devices definitions ('Device Profiles') happen automatically. The "deviceProfilesV4_mmWave.json" file will also be included in the HPM package later.
The temporarily URL for installing or updating to the new driver version is :
https://raw.githubusercontent.com/kkossev/Hubitat/refs/heads/deviceProfileV4/Drivers/Tuya%20Zigbee%20mmWave%20Sensor/Tuya_Zigbee_mmWave_Sensor_lib_included.groovy
The driver can be updated by opening the existing 'Tuya Zigbee mmWave Sensor' driver code in HE Drivers Code editor and copy/paste the raw code, or by copying the link above and pasting it in the HE Drivers Code editor Import function :

Note, that the standard link for manually installed the old stable 'production' version 3.5.2 is different. As this standard link will be replaced with the driver version 4.0.X in the near future, I have made the latest version 3.5.2 availavle from a Google Drive archive (just in case ...) :
(old version 3.5.2 link)
The new version 4.0.0 (timestamp: "2025/09/09 7:00 AM") should be as much CPU effective as the old one. In addition to the 4 real mmWave sensors I have tested it also with 9 virtual (not-existing) devices on the same hub. There is interlock logic implemented in the code, so only one (the first) of the devices will read the JSON file from the HE hub File storage and will put the needed device profiles definitions in the hub memory. All other devices using the same driver will reuse the same shared data structure in the hub memory.
Next update should include better diagnostic and errors logging. For this first beta version, do not forget to click once on the 'Update from Github' button.