Tuya motion sensor is not supported in Home Assistant

Feature Requests
61

You need to add this to the configuration.yaml
The first part creates an input_boolean which is named Door Open and its initial state is off as I want it only to be on if the door get open.

The second part is the emulated hue component. Here you need to add the static ip of your home assistant device (a raspberry pi for example). Then you add the port 80 as Alexa listens only to it. Then you expose all the input_booleans (for example Door Open which we just created).

Then you search with your Alexa App for new lamps and choose Hue Bridge V1 and after 45 seconds the Alexa should find your lamp “Door Open”. After that, you can create a routine with Alexa (where you have your tuya door sensor already in place with the tuya/smart life skill) and use as a trigger your tuya door sensor and as an action you choose the lamp and turn it on. In addition, you need to do the reverse routine where you turn the the “Door Open” lamp off when the door sensor is closing.

I hope this helps you.

62

HA doesn’t support Tuya sensors, so this doesn’t appear to deal with getting that data into HA. Once you’ve got the sensor in -via a tuya automation triggering a tuya switch- you don’t gain anything to using your approach from what I can see.

63

I just wanted to help you as you stated that you want to use the approach from @mattvolp
Nevermind, good luck to you

64

Ah, no. I said:

I did also say:

and:

But, hopefully your code might help others out that want to try that approach.

1 Like
65

@Phill_Healey I don‘t agree with your opinion but everyone is entitled to have one :slight_smile:
No need to reply. Let’s sattle this conversation for good

66

Ok. All the best.

68

I’ve been struggling with some Tuya motion sensors I purchased from aliexpress since the last 3-4 days. It was disappointing that HA did not support them, nor did python-tuya or even codetheweb’s tuyapi, I tried the following different ways of getting tuya motion sensor state to HA:

Approach 1: tuya IFTTT integration (failed)

Setup a incoming webhook from IFTTT on motion sensor alarm (sadly there’s no trigger for motion sensor “normal”), and then the following automation, which did two things: turn on an input_boolean and update an input_datetime to capture the last motion timestamp:

  alias: IFTTT incoming webhook for tuya motion sensors
  description: ''
  trigger:
  - event_data:
      action: motion_sensor_trigger
    event_type: ifttt_webhook_received
    platform: event
  condition:
  - condition: template
    value_template: '{{ trigger.event.data.sensor != '''' }}'
  action:
  - data_template:
      datetime: '{{ now().strftime(''%Y-%m-%d %H:%M:%S'') }}'
      entity_id: input_datetime.{{ trigger.event.data.sensor | replace(" ","_") |
        lower }}_last_motion
    service: input_datetime.set_datetime
  - data_template:
      entity_id: input_boolean.{{ trigger.event.data.sensor | replace(" ","_") | lower
        }}_state
    service: input_boolean.turn_on

Here’s the IFTTT trigger payload:

{ "action": "motion_sensor_trigger", "sensor": "<<<{{DeviceName}}>>>" }

The problem with this: The IFTTT trigger is unreliable. My first automation did not have the trigger.event.data.sensor != '''' check. IFTTT would send triggers every 30 minutes even when there was no motion detected by the PIR! I then noticed that the correct triggers had the DeviceName field populated so started checking for that. Then it got worse: it would sometimes not send the DeviceName even for genuine motion alarms!

The above automation was to switch the input_boolean to ‘ON’, what about switching it ‘OFF’ you may ask. Well that was the job of another automation:

  alias: Living Room Motion Sensor Off-State Automation
  description: ''
  trigger:
  - platform: template
    value_template: '{{ as_timestamp(states.sensor.date_time.last_changed) - state_attr(''input_datetime.living_room_motion_sensor_last_motion'',
      ''timestamp'') > states(''input_number.motion_sensor_idle_secs'')|int }}'
  condition: []
  action:
  - data: {}
    entity_id: input_boolean.living_room_motion_sensor_state
    service: input_boolean.turn_off

This used the difference in time between the time sensor and the last updated motion timestamp on the input_datetime. This too had issues of its own as the time sensor doesn’t really tick away in real time and had a lag of 30+ seconds at all times. Nevertheless, that wasn’t the biggest problem and could be ignored. The bigger problem was that: since the IFTTT trigger wouldn’t fire properly, the input_datetime wouldn’t get updated properly and this would always stay off.

Here are the state entities:

input_datetime:
  living_room_motion_sensor_last_motion:
    name: Living Room Motion Sensor Last Motion
    has_date: true
    has_time: true
    icon: mdi:mdi-motion-sensor

input_boolean:
  living_room_motion_sensor_state:
    name: Living Room Motion Sensor State
    initial: off
    icon: mdi:mdi-motion-sensor

Approach 2: Ping binary sensor (works!)

Note: This approach works flawlessly but only with the battery powered ones.

After the above approach failed, I started looking into more interceptive ways of doing this. I ran wireshark on my laptop and filtered it down to the MAC addresses of the motion sensors. Here’s what I saw - these motion sensors keep sleeping all the time and as soon as there’s some motion, they wake up, send ARP requests to find the router, and do the regular DHCP stuff, and then fire the MQTT message (i believe) to tuya cloud for motion. One way would have been to use something like GitHub - KimiNewt/pyshark: Python wrapper for tshark, allowing python packet parsing using wireshark dissectors and sniff these requests off the network to create a binary sensor. However I found a much simpler way :slight_smile:

ping 192.168.1.21
PING 192.168.1.21 (192.168.1.21): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
64 bytes from 192.168.1.21: icmp_seq=13 ttl=255 time=404.428 ms
64 bytes from 192.168.1.21: icmp_seq=14 ttl=255 time=188.593 ms
64 bytes from 192.168.1.21: icmp_seq=15 ttl=255 time=6.086 ms
Request timeout for icmp_seq 16
Request timeout for icmp_seq 17
Request timeout for icmp_seq 18
Request timeout for icmp_seq 19
Request timeout for icmp_seq 20
Request timeout for icmp_seq 21

You see, these sneaky little things come online for around 2-3 seconds before vanishing away. In that small little window, they do respond ping/ICMP requests! Bam, and here’s the solution:

binary_sensor:
  - platform: ping
    host: 192.168.1.21
    count: 1
    scan_interval: 1
    name: ping_tuya_motion_sensor_master_bedroom
  - platform: template
    sensors:
      tuya_motion_sensor_master_bedroom:
        friendly_name: "Master Bedroom Motion Sensor Alarm"
        value_template: >-
          {{ as_timestamp(states.sensor.date_time.last_changed) - as_timestamp(states.binary_sensor.ping_tuya_motion_sensor_master_bedroom.last_changed) < states('input_number.motion_sensor_idle_secs')|int }}

That’s it. You now have a working binary sensor which accurately represents your Tuya motion sensor state. The first binary sensor does the actual work. It uses the ping platform with the lowest interval of 1 seconds (because these sneaky things disappear quickly after waking up). And booyah:

CjCyQ3l6vK

The second, template binary sensor, then creates the illusion of motion being detected for a while and then turning to an off state based on an input_number of idle seconds. I believe even the Tuya cloud would be doing the same as the sensor doesn’t really wake up to tell the cloud when motion is no longer detected. You can ofcourse configure idle seconds to your liking (mine is set to 10 minutes or 600 seconds).

Here’s the end result:

screencapture
screencapture1150×299 49.3 KB

There’s a tiny problem right now which can be easily solved: i enabled the debug logs and saw that the ping sensor isn’t really pinging at my configured interval of 1 seconds, but 3 seconds (and exactly every 3 seconds for some reason), so it misses the motion sensor sometimes. I intend to write a simpler ping sensor which can just do a simple continuous ping and report back state that way (instead of waking up on intervals and doing pings).

Hope this helps somebody like me, who does not have the equipment or doesn’t want to risk flashing their sensors with Tasmota and such to get them working with HA.

9 Likes
69

Hi @angadsingh thank you for posting your code for this one, I have tried it myself but I must be missing something?

I copied your code into my config.yaml and changed the ip and name of the motion sensor.
The ping binary sensor works ok and picks up the motion, however it dosnt pass the I do through to the other entity.

I am new to ha so it’s possible I’m doing something wrong.

Cheers

70

@4Sakyen Please point me to your config so that I may be able to help.

71

Hi @angadsingh

binary_sensor:

  • platform: ping
    host: 192.168.1.67
    count: 1
    scan_interval: 1
    name: ping_tuya_motion_sensor_laundry
  • platform: template
    sensors:
    tuya_motion_sensor_laundry:
    friendly_name: “Laundry Motion Sensor”
    value_template: >-
    {{ as_timestamp(states.sensor.date_time.last_changed) - as_timestamp(states.binary_sensor.ping_tuya_motion_sensor_laundry.last_changed) < states(‘input_number.motion_sensor_idle_secs’)|int }}

Cheers

72

@angadsingh My formatting is incorrect in my post but I believe it is current in my config

73

@angadsingh You are a wizard!

Thank you so much!

74

It’s really important to paste your code properly formatted, since bad formatting accounts for a lot of YAML issues. Wrap your code in the </> tag.

75

You’ll have to excuse my ignorance, and I totally mean no disrespect, but is it really that difficult to bring in other things from the Tuya service other than switches and lights? Obviously it’s a much sought after feature, to be able to use door/window sensors and motion sensors. I also understand there are a lot of other much sought after features in HA so it can’t just be done at the drop of a hat, but I would have thought if the integration already exists it would be something that could be added. I’m just curious :slight_smile:

This also might be the incorrect place to ask, so I apologise if that’s the case.

76

According to the docs it is more, it includes climate, cover, fan, light, scene and switch.

But don’t forget that these things are hacked together from information from a company that doesn’t particularly want to share it’s data.

If you want something that works, buy something that works.

1 Like
77

@4Sakyen Have you configured the time sensor? It is not activated by default. you have to explicitly enable it like so:

  - platform: time_date
    display_options:
      - 'date_time'

Also hope you created the input_number:

input_number:
  motion_sensor_idle_secs:
    name: Motion Sensor Idle Seconds
    initial: 600
    min: 10
    max: 3600
    step: 1

To test if the condition is working you can just go to Developer Tools > Template and check the evaluated value there first.

1 Like
78

@nickrout Fair call, I just happened to have the Tuya devices before I discovered HA, so was hoping to get it all to work natively without the workarounds. Definitely not knocking the work that’s been done thus far.

79

Yes I think a lot of people buy stuff and then try to make it fit in. I was fortunate that the only smart stuff I bought before I discovered HA was some hue bulbs, and they still work :slight_smile:

There is a lot of unfortunate proprietary stuff out there, and generally it is cloud based.

It’ll all be fixed when I rule the world.

2 Likes
80

@angadsingh No I had not :blush: I’m still new to ha to be honest. Do I need this in my config.yaml?

Thanks again for your help

81

Yes @4Sakyen