ERROR (MainThread) [custom_components.localtuya.common] [551...8a4] Connect to 192.168.1.122 failed
I even found the data points but none of them work because local tuya can’t connect.
H-A is installed in supervised mode on Debian 11 bullseye.
Versions:
Home Assistant Core 2022.5.5
Home Assistant Supervisor 2022.05.3
Frontend version: 20220504.1
Kernel version 5.10.0-14-amd64
Local Tuya 3.5.0
I have a motion sensor integrated with the newest localtuya version 4.0.0, which changed the updating scheme to push from poll. The issue with the pairing is the fact that these types of battery-operated WiFi sensors (i.e., door contact sensors, motion sensors) only connect to the WiFi briefly for about 10 seconds once activity is detected and then fall off to preserve battery. They may also wake up intermittently to check in with the Tuya cloud so it knows they’re still online, although I’m not sure about this.
So to install it, you’ll want to trigger the sensor and immediately start the config flow with localtuya. You’ll want to continue to trigger the sensor so it stays connected while you’re finalizing the config flow as a binary_sensor (code for true is “pir”, code for false is “none”). It may take a couple of tries but it works pretty well imo.
The main problem I’m encountering is with usage. Unlike when you visualize the device in the SmartLife app, the device in localtuya actually sits unavailable most of the time until it detects motion (makes sense given what I said above), at which point it wakes up, connects to the WiFi and reports the state. All my IoT devices have static IPs btw, so in theory the reconnection process should be pretty fast. In the SmartLife app, the device takes about 1-3 secs to respond, which is very good for a WiFi device imo. Unfortunately in localtuya it takes more like 5-6 secs, which is a bit more annoying. Basically, by the time the stairs light comes on in response to the sensor I’ve already gotten half way down it in the dark, which is not ideal. In theory I would hope for the sensor to update even faster with localtuya then via the cloud, which is the case for my other light and switch devices, so not sure why this is the case. Hopefully it’ll get fixed in future updates. I use mostly ZigBee motion sensors now, but I do have a few WiFi ones that would be nice to use if possible.
I would like to ask to somebody if is somehow possible to display battery status for tuya wifi PIR sensor. In official tuya integration i see battery level everytime even though pir sensor after few seconds goes to offline for battery saving. In local tuya i have always status unavailable. I tried to modify all possible parameters but nothing helps.
Not really. I ended up using the sensor via the official tuya integration for a while, but ultimately switched to ZigBee sensors entirely. I still use localtuya for several lights and switches, which works great, I just feel sensors (e.g., motion, doors) work better via ZigBee.
I have a very good solution. I’m using Localtuya, I have a wifi pir sensor with batteries and a wifi lightbulb. First of all you need to understand how the wifi pir sensor with batteries works. When it detects movement, it connects to the router (gets an IP address), sends some data, and disconnects. All this happens in seconds. While it keeps detecting movement, it will NOT connect again to the router until it stops detecting you. (Lets say your detector is in the kitchen and you are there cooking, it will keep detecting you and WILL NOT connect to the router again until you leave the kitchen and stop detecting you). Then it will connect to the router, and send data saying it is not detecting movement.
You can use those “data sending moments” as triggers to turn the light (in this scenario) on or off.
1.- Create a binary sensor, ping every 2 seconds sending only 1 packet (count: 1).
2.- Then create an automation. The trigger will be when status of that binary sensor changes from off to on.
3.- The action will be an if action. If the state of the lightbulb is off, turn it on. Else turn the lightbulb off.
This way you can have exactly the same functionality provided by the official Tuya integration for Wifi Pir sensor with batteries.
Additional note: IF for any reason, the entity you are planning to use (remember in above example I’m using a lightbulb and it does have a state on or off) doesn’t have that variable, you can create an “input boolean” to assign state status. Remember to assign inverse status (if state is on set it to off and viceversa) on the actions of the automation.