Tuya Bulbs Last State Retaining Rule - Maybe a Fix

Hi All,

Recently I bought Tuya Bulbs (Teckin SB50) and managed to set and integrate them using their Smart Life app with Google Home and work perfectly. However, these bulbs are lacking the ability to retaining their last state. When they recover from electricity power-off or when you deliberately power them off using home wall switches (cut electricity on them) and then bring back the electricity on them, the bulbs will light up no matter what is their last state. Simple they never retain their last state. Weirdly enough, they keep their last color and dim level.

I did some googling and found tuya-MQTT (Thanks to @AgentK for his amazing post and also for @Tsightler for the release that supports ver3.3) and managed to install the tuya-mqtt service and integrate the tuya bulbs with it on OH2 successfully, now I have the full control. In order to solve the state retaining issue, I tried to make a workaround solution in order to push the state OFF in case electricity turned off/on the bulbs and conditioned this when their last state from OH2 is OFF as well.

This workaround works based on monitoring the pings on all the bulbs and take the action based on the last ping item state and bulb’s last item state. For example, if one of the bulbs’ state was off (switched from OH2 dashboard) and the electricity went off then on, this means that I need to retain the last state, so my rule will trigger based on the ping state.

The biggest challenge I faced here is the Tuya-MQTT service is not stable and sometimes hangs (can’t take more orders) when it takes more than one command from the OH2 and the worst part is that the tuya-MQTT service behaves very unstable when the bulbs recover electricity power flaps (seems like the inner part of the tuya-MQTT service is very unstable when the power is cut on the bulbs, it can’t keep up the previous session efficiently). For that, in my rule I decided to do while loop to repeat the commands I send to the tuya-MQTT service and restart it before and after my command.

The following rule did work for me, however, I feel there is a better way or another solution for this issue. I admit I’m naive when it comes to OH2 field, so excuse me if I have done something not professional:

Things:

(Pings) channels are configured from PaperUI and set to monitor the bulbs with the settings (Interval: 1000ms, Retry: 3)

Items:

Switch OfficeWallLamp_Ping (gTuyaPing {channel="network:pingdevice:53470984:online"}
Switch LivingRoomWallLamp1_Ping (gTuyaPing {channel="network:pingdevice:491e8b08:online"}
Switch LivingRoomWallLamp2_Ping (gTuyaPing {channel="network:pingdevice:c48a093e:online"}
Switch LivingRoomStandLamp_Ping (gTuyaPing {channel="network:pingdevice:5109b701:online"}

Group gLivingRoom
Group gTuyaPing

Switch LivingRoomWallLamp1 "Living Room Wall Lamp 1" (gLivingRoom) {channel="mqtt:topic:15d4c27b:1011"}
Switch LivingRoomWallLamp2 "Living Room Wall Lamp 2" (gLivingRoom) {channel="mqtt:topic:3c28ef87:1012"}
Switch LivingRoomStandLamp "Living Room Stand Lamp" (gLivingRoom) {channel="mqtt:topic:a9e8db51:1010"} Switch OfficeWallLamp "Office Wall Lamp" (gLivingRoom) {channel="mqtt:topic:12b6d8c2:1004"}

Rules:

rule "Switch Off Tuya Upon Electricity Recovery"
    when
            Member of gTuyaPing changed from OFF to ON
    then
            //run the rule two times to make sure the commands are delivery to the tuya mqtt service
var Number tloop = 2 
            var int randomTime = (new java.util.Random).nextInt(60)
            while (tloop > 0) {
            createTimer(now.plusSeconds(randomTime),  [ |
            gLivingRoom.members.filter[i | i.state.toString == "OFF" ].forEach(obj | { obj.sendCommand(OFF) } )
            ])
            executeCommandLine("sudo systemctl restart tuyaapi-mqtt.service")
            createTimer(now.plusSeconds(randomTime),  [ |
            gLivingRoom.members.filter[i | i.state.toString == "OFF" ].forEach(obj | { obj.sendCommand(OFF) } )
            ])
            tloop = tloop - 1
            }
    end

Appreciate your kind advice and suggestion.

Best,
Ibrahim

Definitely file an issue on the tuya-MQTT project on the instabilities you are seeing.

If you send the message with retained set to true, you just need to send the command once and then when you bounce the tuyaapi-mqtt service it will receive the retained messages again.

In fact, if you send all your commands with the retained flag set, all you need to do is restart the service and when the service comes back online it will receive all the retained messages again.

You can set the retained flags on your Generic MQTT Things (there is a toggle under “show more”).

Definitely file an issue on the tuya-MQTT project on the instabilities you are seeing.

True, I’ll consider reporting it.

In fact, if you send all your commands with the retained flag set, all you need to do is restart the service and when the service comes back online it will receive all the retained messages again.

I didn’t know about the retained flags, just noticed they exist in the more section! Let me check that one, perhaps I can get rid of sending multiple commands repeatedly.

Will get back to you about this shortly.

Thanks.

Thank you @rlkoshak for your suggestion about the retained flag which made my rules shorter and more importantly, now it is more reliable in delivering the commands when the tuya-MQTT service is restarted.

So grateful.