I have a WiFi smart socket that I control via the Tuya (cloud) integration. From time to time HA loses track of the socket’s on/off status, e.g. believing it to be off when in fact it’s on.
I have an automation that runs on a time trigger, which should turn the socket off based on a temperature sensor value, and it’s triggering, but it seems to not actually send the command, because (I’m guessing) it appears to HA that the switch is already off.
Either way, the result is that the socket (which supplies a 2kW greenhouse heater) can remain on for many hours of the night, pushing the temperature far above the threshold at which the automation should turn the socket off, and wastefully expending expensive energy.
The official Tuya app on the other hand, always seems to see the true status, and is able to send an off command to the socket, but that’s no use to me when I’m asleep! However it suggests that the WiFi link to the socket is not the problem.
Am I correct in supposing that HA won’t act on “switch.turn_off” if the observed state of the switch is already “off”? And if so, is there a way to FORCE the off command to be sent?
Also what could be causing HA to lose track of the switch state? I have no knowledge of the inner workings of the Tuya integration, but I gather most are event-driven, so maybe HA has somehow missed a notification of switch state change, in which case, what to do to have the correct state known?
No - unless you have included some sort of condition in your automation. Normally the “turn_off” command will still be sent, but nothing will happen because the switch is already off.
I think people need to see the yaml before they can comment.
Check these 2 entities in /Settings/Devices#Entities …Normally when you have such “trailing” _1, is because they for some reason have been created again(various reasons for this) … How ever the integration these belongs to have maybe “decided” to use the entities without _1 or visa-versa … so check your entities/devices(and integration they belong to
Good thought, but as far as I can remember those entities have always had the _1 on their names. The temperature sensor is coming in via an Ecowitt gateway, and it’s the first remote sensor connected to the gateway device, so _1 makes sense. The socket is also sold as a 2-gang device so again _1 makes sense.
I’m going to try the localTuya integration instead of the ‘official’ cloud based one, as I’ve seen reports saying it’s much quicker to update.