How to automate Tuya mmWave with buggy reporting

Configuration
21

OK, when I get home I’ll try and put together an option for you.

1 Like
22

Just a note: i have one Tuya presence sensor ( don’t know which model though, bought on aliexpress), i converted it to esphome (i changed original non-supported control module inside with esp), and if i change any setting module always restarts after that - this is, as it seems, normal behaviour of sensor module and not a bug. It seems that module itself is made in a way that it requires reboot to work with new settings.

23

@Protoncek

Sure, thanks. I’m fine with it rebooting. The bug is that it reports absence in the presence of a human. Tuya should check its sensors first before reporting a wrong status.

If it was a hardware problem which cannot be rectified, the sensor should not report for X seconds after a reboot. Pretty sure there is a reasonable way to fix this upstream, but gets extremely complicated here in HA.

24

So is a 3 second delay when you leave the area too long? To me for a light that is super fast.

alias: presence in room (Advanced)
description: ""
mode: restart
trigger:
  - type: occupied
    platform: device
    device_id: xxxx_mmwave
    entity_id: xxxx_occupancy
    domain: binary_sensor
    id: 'occupied'
  - type: not_occupied
    platform: device
    device_id: xxxx_mmwave
    entity_id: xxxx_occupancy
    domain: binary_sensor
    for: '00:00:05'
    id: 'not_occupied'
action:
  choose:
    - conditions:
        condition: trigger
        id: 'occupied'
      sequence:
        - type: turn_on
          device_id: xxxx_switch
          entity_id: xxxx_light
          domain: light
        - device_id: xxxx_mmwave
          domain: number
          entity_id: xxxx_sensitivity
          type: set_value
          value: 4
    - conditions:
        condition: trigger
        id: 'not_occupied'
      sequence:
        - type: turn_off
          device_id: xxxx_switch
          entity_id: xxxx_light
          domain: light
        - device_id: xxxx_mmwave
          domain: number
          entity_id: xxxx_sensitivity
          type: set_value
          value: 1

You don’t need two automations for light control, just two triggers and a choose:

25

I would be fine for a minute :grin:

26

@sparkydave

Yes, I was already able to make it faster with high sensitivity, except that it gets false alarms from activities outside the room.

We are dealing with lights today, so I understand that asking for less than 3 seconds is not reasonable. But my aim is also to see how far we can push it without comparing with current norms. Being accurate at less than 1 second can open up other possiblities.

Hope that explains.

I see your automation is handling the bug on the absence side but has restart. Let me see how it behaves. Thanks!

27

That just helps with the dual triggers and for: command. It’s how I create pretty much all of my automations. This way if you re-trigger the automation during the 5 second cool-down, it will keep you light on for you (ie: if you are actually still in the room).

Having said that, with my automation you could probably simply adjust your sensor sensitivity to a median point and not need all this stuff making settings changes.

28

@sparkydave

It works. I even have for: down 1 second. But overall, it doesn’t seem to have improved the speed at which the lights turn off. I have to fiddle more with it when I have some time.

Nonetheless, it doesn’t go on and off continuously anymore and I have them both in 1 script. It is definitely progress for me. Thank you.

1 Like
29

@sparkydave

Just to explain,

  1. I did try to find a median sensitivity, but wasn’t able to
  2. In the end I decided to adjust the sensitivity and that was when I found the bug
  3. That bug led me to write my OP

:joy: