Battery-powered WiFi devices are probably going into deep sleep, else the batteries would be needing replacement every couple of days. So, when movement is detected, the processor inside has to boot up and connect to WiFi. This can take two or three seconds. Which is exactly what you are seeing.
Zigbee is much better for battery-powered devices, and you would likely see near instant response.
They do seem to reply to a ping pretty quickly once they’ve been triggered though, so using that instead of going through tuyalocal or localtuya seems promising.
I’ve been trying to make that happen with nodered, but must be missing something.
Simlar with the ping addon for HA as well tbh
@mad-tunes simple, add a ping node, set time and IP adress, then a home assistant binary sensor, when double clicking on the binery sensor node you have to click on a pencil next to the entity config and enter info like this:
Then connect the two nodes with one another and click deploy, wait a second or two and you can see if the new entity is available in HA developer tools. If you have more then one motion sensor just repeat the steps and always create a new entity config.
I’ve been trying to do similar with the ping integration but not getting anywhere better. With it pinging every second, it seems pretty variable. Can take up to 8 seconds for the ping binary sensor to update after the PIR wakes up and has started replying to ping -t.
It seems to react to not getting replies almost instantly though, I dunno why, but I wish it was the other way round.
Foiled again.
Pinging through NodeRed does react quickly to getting a reply, but then it flutters on/off for a short while. It’s causing strange things to happen with any automation that relies on either on/off or off/on. So close!
I kept fiddling and I’m pretty sure I’ve found something that works
Pinging from the command line looks like it’s both fast (off/on and on/off) and gives a stable result, rather than using the ping integration (that was too slow/variable) or NodeRed (that fluttered on/off).
Got this in my configuration.yaml for the two PIR sensors I’ve got:
Using the states of Ping_PIRStairs & Ping_PIRConservatory changing to Connected lets me reliably turn on lights within about a second of triggering the PIRs.
I found that pinging the wifi PIRs worked perfectly… until I noticed them periodically start up a wifi connection when there was no movement, which ‘randonly’ turned my lights on.
After a tiny bit of configuration to get it connected to ZHA, it’s been working perfectly for the last few days with two of each of these buttonsPIRs
To get the hub conencted to ZHA/HA, I:
Plugged it in using LAN cable
Browsed to its IP/hostname to get to tasmota web interface
GPIO2: TCP Tx
GPIO4 TCP Rx
OTA URL: http://ota.tasmota.com/tasmota/tasmota-zbbridge.bin.gz
Run in console: Rule1 ON System#Boot do TCPStart 8888 endon
(optionally) set wifi connection details and my own hostname
Connected ZHA to EZSP @ 115200 using: socket://Hub_IP_or_hostname:8888
I’d read warnings about these hubs not working well over WiFi, but it is so far. It’s close to my router, and might not be as solid if it was further away. I see no need to use a cable as things are though.
I’m not sure what the battery life will be like with the buttons and PIRs yet, but I’d be surprised if they’re not better than the WiFi ones I was using before.