Hi All, this post was inspired by the recent discussion around processes which need to stop if there’s no internet connectivity, like swimming pool filling and dosing. If there’s an internet outage you don’t want the pool to continue filling and so here’s a Tuya-based workaround (@teknofilo and pebneter’s idea to be honest but I’m writing it up).
First I add a condition that’s monitoring a Tuya smart plug, with a trigger to evaluate a logicblock if the timer is at, or below 60 seconds:
Then I add a logicblock to reset the timer to a suitable timeout (in this case 600 seconds) once it’s evaluated positively. So if there’s no connectivity, the maximum the connectionless equipment will run for is 600 seconds. If connectivity remains/returns, the timer will keep being reset to 600 every time it reduces to 60. Voila! And thanks again to @teknofilo and the .
@DanT Looks good, but are you sure that the countdown is implemented locally in the plug rather than in software via the Tuya servers? If the latter then losing connectivity would still be an issue.
The timing function is implemented in two ways, namely cloud timing and local timing.
Cloud timing: All timing data is stored in the cloud server. When the timing execution time is reached, the cloud sends a command to the device, which is not affected by the device’s power failure (you must reconnect to the network after the power failure). However, if the device is offline, the timing execution will be unsuccessful. If the device is online normally, the execution can be successful.
Local timing: All timing rules are not only stored in the cloud, but also stored locally on the device itself. The local timer of the device will determine whether the timing needs to be executed, regardless of whether the device is offline. However, if the device has a power failure during the timing period, the local timing of the device will be restored to the initial setting. If the device is not connected to the Internet after the power is restored and calibrated through the cloud timing, the device cannot perform timing tasks.
So it seems that whether this will work depends on the capability of the specific device. However, I do not know how to find this out (apart from testing directly).
.
