This is what I did, I just did not want to run over the original driver for the older device. If I assign the new version 1.4.4 to the older device will it still work?
1 Like
Should be, but there is always risk for newly introduced bugs.. I usually delay updating the main version for at least a week after being used on my main hub, but today I made exception of this rule.
I don’t have the time to test what is the effect of modifying the multiple‘preferences’ on the presence/occupancy detection, so it will be interesting to hear others opinions.
1 Like
OK. I assigned the dev version to the older senosr ( TS0601_TUYA_RADAR) and I will let you know if it still working as expected.
Thank you!
Also, any ideas for practical use of the humanMotionState events are welcome.
Currently I just change the colour of an RGB light for testing purposes…
What automation makes sense to implement? One idea is to lower the brightness of the room lights, if the ‘stationary’ humanMotionState stays unchanged for more than 10 minutes - probably the person in the room has felt asleep? : )
Just one off the top of my head; I would see in a bedroom where a state change from (small_move or stationary) to moving during the night would turn on a night light under the bed at 20% just so you can see where you are going. Or a change from none to moving during the same period would turn on the main light unless you were in that room in the last 1/2 hour or something just to let you do your nighttime emergencies.
1 Like
So many ways to use these things.
-
none
- missing child
- Room or House is empty so you can automate away modes
- pet is not in this room
- someone with a health issue may need help
- etc
-
Moving
- focus location has active presence - can be specific or a room
- Lights, alarms, data point to compare to other things, unlock exit doors etc
- sequence events along a path with more than one sensor to automate actions
- hidden sensors can be used as event triggers for hand movements - swipe in front of top shelf etc.
-
Small Move
- pet location
- not moving through a space
- not sleeping, but present
- keeping lights on or off in a media room/kitchen/bathroom/office when someone is present
-
stationary
- Sleeping so ensure other automations don't wake
- check on general occupancy for child or elderly
- sleeping pet
- security for closets or other spaces
- use to set HVAC temps zones
- locate sleeping or incapacitated people
So many possibilities. The new LD2450 sensors can track up to 3 people and give you people count up to 3. Human count in a room without using a camera is very very useful for things like Airbnb and sensitive locations like bathrooms.
1 Like
i basically use it to keep lights on in room when someone is in there.. i normally have rules to turn on lights and turn off when innactive at night via normal motion.. but those dont work well when someone is just sitting at table not moving.. these newer detectors work well in such a circumstance.
I also use all my mmWave sensors for this purpose. - as general presence (I prefer the term 'occupancy') detectors and simply keeping the lights on (I use the Room Lighting app). All mmWave sensors (Aqara FP1, Aqara FP2, and the old Tuya 5.6GHz radars are performing very well when someone is sitting and not actively moving. There is no place for comparison to any PIR motion sensors.
What makes the new 24GHz Tuya radars different when compared to the old series is exactly this 'humanMotionState' new attribute. It changes frequently between 'moving' and 'small_move' state when sitting on a chair, but switches much less frequently between 'stationary' and 'small_move' when I am laying still on the couch... This is something new that will be interesting to use.
Another possibility is to dynamically change some of the preferences, depending on the mode - small 'radarFadingTime' (15 seconds or less) during the day, but can be set to 10 or more minutes during the night. This way the 'stationary' state (someone is sleeping) should be kept much more reliable... there is room for a lot of experiments.
2 Likes
@kkossev I updated to the 1.4.3 version of the driver earlier, and the device is now showing a few extra (erroneous) attributes under Current States. Now showing battery (50), Humidity (1), and tamper (detected).
These weren't here before - still using device profile TS0225_HL0SS9OA_RADAR
An error that has crept in with recent updates or are these supposed to be here? Thanks 
If you have the square shaped 24Ghz radar (from @iEnam link), there is a new device profile for it :
The driver is still not ready for this 24GHz device, it is similar but not the same as the first one.
Click on the Initialize button and see what profile is selected automatically by the driver.
Yes it is - I previously provided the debug logs to you to fix the illuminance reporting issue. New attributes appeared between driver version 1.4.1 and 1.4.3
Thank you for the report, I will be looking for a possible issue here.... My device (same manufacturer) is still working as expected.
I will also add some code to clear the current states when you click on Initialize button, so that there is no need to go to the inbuilt Device driver to do it.
The above fake temperature, tamper, humidity, etc.. states can appear if you accidentally set a Device Profile for a PIR 4-in-1 device.
Update:
@jason12 If you update to the latest version 1.4.4 2023/08/17 11:39 PM and hit the Initialize button, all the fake current states should be cleared (all preferences will have their default values too!)
@iEnam, the decoding (only) of the preferences for the second TS0225 device _TZE200_2aaelwxk should be OK now. Note that changing the preferences is not ready for this manufacturer yet.
1 Like
Great use cases you've thought of @JumpJump
Has anyone been able to find a supplier for the ceiling mount version of this new ‘non-spammy’ radar sensor with the TS0225 firmware and the humanMotionState State Variable?
What I have found here (from a Github link) is probably not what we are looking for. It is TS0601 manufacturer code _TZE204_ijxvkhd0 and the price is very high (almost double the wall version)- €53.65 including EU VAT. Probably the ceiling mount version is not in standard production yet, because it is listed on some other sites but can not be selected at the moment.
You can ask questions to the seller, and most of them are responsive. Ask them to send you screenshots of the ceiling mount version Smart Life app settings (they usually know nothing else except Smart Life).
1 Like
@kkossev - Thanks, that has done the trick.
I also had 4 x Square Version arrive today ( TS0225_2AAELWXK_RADAR) and can confirm they are pairing/working also.
Device profile confirmed as TS0225_2AAELWXK_RADAR and driver version 1.4.4 2023/08/18 2:44 PM
EDIT: Ahh I see you have been 'tweaking' - this 1.4.4 version is later than the one you reference in the post 
can confirm working, and preferences showing.
2 Likes
OK, so early reports on illuminance, but some more work to do as only a quick look:
I have got a few (indoor) Hue motion sensors dotted about the place (which I will probably replace with these). I'm not sure how accurate they are seen to be? My only issue is they often don't update due to being battery...anyway...
I downloaded an app for my phone, that uses the light sensor to report 'Lux'. This particular app seems to be reporting values very close to what the hue motion sensors are reporting through hubitat - for example my bathroom with 1 window (cloudy day) is reporting around '40' on both the app and the Hue motion sensor.
If I compare the app to the Tuya sensors I observe the following:
HL0SS9OA - reports approximately 3 x the app reading (e.g. App says 50, Sensor reports about 150)
2AAELWXK - reports approximately 4 x the app reading (e.g. App says 50, Sensor reports about 200) - perhaps because this appears to have a bigger hole for the light sensor?
I appreciate that it is no scientific accuracy, but might be useful for someone!
When I have time, I'll check out in a bit more detail
In my mind, at least, the higher values may be better as the resolution towards the lower end may be higher?
Since the lux scale is linear, just having an offset in the settings should bring things back to where they should be, that being said, I have not paired mine yet to do testing and see what the raw data is that we are receiving from the device.
@kkossev will more likely be able to know this and maybe find a solution or not, because 3x and 4x higher means that some devices might not be reporting the same way than others? He might need to code something for each model and also have the offset adjustment in the settings.
Yeah, agreed. I would take this with a pinch of salt at the moment. We need to see what happens over time, and also once any sensor has 'settled down'. May the simple answer is to have a preference/variable of an offset that the user can set (if desired) in all cases.
