Repeated use of status() turns off light

[law1964]

The light connected to my device starts in the ON (True) state.. I run the following python script:

import pytuya, time

old_state=[False, False, False]
SmartLife=["", "", ""]
SmartLife[1] = pytuya.OutletDevice('02200270ecfabc8e2ff0', '192.168.20.39', 'ceb9acd336c853f2')
SmartLife[2] = pytuya.OutletDevice('04200086b4e62d121b87', '192.168.20.14', '3e637e09ea909522') #Desk Lamp

device_set={2}
for i in device_set:
    data = SmartLife[i].status()
    old_state[i] = data['dps']['1']
    print ("*** Polling started " + time.strftime("%a, %d %b %Y %H:%M:%S", time.localtime())
        + " " + str(i) + " " + str(old_state[i]) )

while True:
    for i in device_set:
        data = SmartLife[i].status()
        state = data['dps']['1']
        if (state != old_state[i]):
            print time.strftime("%a, %d %b %Y %H:%M:%S", time.localtime()) + " State has changed to " + str(i) + " " + str(state)
            old_state[i]=state
        time.sleep(0.5)

The resulting console output:

*** Polling started Thu, 28 Jun 2018 10:18:46 2 True Thu, 28 Jun 2018 10:48:33 State has changed to 2 False

There are no timers on the device. Nor is there user intervention. The light turns off by itself. This is repeatable (and an eventuality) on multiple but not all devices.

Thoughts?

[BillSobel]

The script in the email doesn't appear to touch the device, so its not clear how the device is originally being turned on. I did find that if the timer DP is set to 0 during a state change, that the unit does then turn the light back off. E.g. don't send dp1 to TRUE and dp2 to 0 on a typical timer outlet or that creates a 'on and immediate off'. Its best to not touch the timer DP at all unless you want any sort of timer involved. Is it possible some other code is setting the timer DP to 0?

On Thu, Jun 28, 2018 at 8:04 AM, law1964 notifications@github.com wrote:

The light connected to my device starts in the ON (True) state.. I run the following python script:

import pytuya, time

old_state=[False, False, False] SmartLife=["", "", ""] SmartLife[1] = pytuya.OutletDevice('02200270ecfabc8e2ff0', '192.168.20.39', 'ceb9acd336c853f2') SmartLife[2] = pytuya.OutletDevice('04200086b4e62d121b87', '192.168.20.14', '3e637e09ea909522') #Desk Lamp

device_set={2} for i in device_set: data = SmartLife[i].status() old_state[i] = data['dps']['1'] print ("*** Polling started " + time.strftime("%a, %d %b %Y %H:%M:%S", time.localtime())

• " " + str(i) + " " + str(old_state[i]) )

while True: for i in device_set: data = SmartLife[i].status() state = data['dps']['1'] if (state != old_state[i]): print time.strftime("%a, %d %b %Y %H:%M:%S", time.localtime()) + " State has changed to " + str(i) + " " + str(state) old_state[i]=state time.sleep(0.5)

The resulting console output:

*** Polling started Thu, 28 Jun 2018 10:18:46 2 True Thu, 28 Jun 2018 10:48:33 State has changed to 2 False

There are no timers on the device. Nor is there user intervention. The light turns off by itself. This is repeatable (and an eventuality) on multiple but not all devices.

Thoughts?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/clach04/python-tuya/issues/29, or mute the thread https://github.com/notifications/unsubscribe-auth/ADLj6IIA_peF3thMcV0mOZipPj-GCl7tks5uBPBqgaJpZM4U7j5P .

[law1964]

The device is in an ON state before the script is executed. I don't know how to answer your question because I don't know what a timer DP is. Please elaborate. As far as I know, no other device affecting processes are running and nobody else touches the device except me.

[BillSobel]

Many of the outlets have a switch (binary DP) and a timer (countdown DP). Setting binary to TRUE turns on the outlet. Setting the countdown turns the item back off after that many seconds. I noticed that if you set the outlet to ON (true) with a countdown of 0 it doesn't treat 0 as 'no countdown' but rather turns the light right back off. So I was curious how the outlet was getting turned on in the first place, and if it was code, if that code set the countdown to 0 thinking that meant 'no countdown'...

On Thu, Jun 28, 2018 at 10:20 AM, law1964 notifications@github.com wrote:

The device is in an ON state before the script is executed. I don't know how to answer your question because I don't know what a timer DP is. Please elaborate. As far as I know, no other device affecting processes are running and nobody else touches the device except me.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/clach04/python-tuya/issues/29#issuecomment-401110291, or mute the thread https://github.com/notifications/unsubscribe-auth/ADLj6A7hdCMxdIV76HoOZFD6i1J7XDTBks5uBRBggaJpZM4U7j5P .

[law1964]

Thanks for the explanation. I used Alexa to turn on the light by saying "Alexa, turn on Desk Lamp" in the first place. Alexa would not set a countdown DP value.

[clach04]

@law1964 as @BillSobel said this sounds more like a timer (or another device). Like you I'm using Alex (with a skill using the cloud API, I'm not using a HA skill) and I'm not seeing this, I just tried you test code and I'm not seeing this.

Thoughts;

• how many iterations/secs does it take for this to happen for you?
• can you dump data['dps'] in your script before the if? If a timer is set, element 2 will be non-zero - this number does NOT change until the timer expires - or at least that's what I see with my devices ;-) - this would at least help prove/disprove the timer theory

[law1964]

I see that you changed the Alexa to the masculine form. I hope the operation went smoothly. :)

The following is the relevant portions of the data dump:

*** Polling started Fri, 29 Jun 2018 07:55:03 2 True {u'1': True} {u'1': True} {u'1': True} {u'1': True} . . {u'1': True} {u'1': True} {u'1': True} {u'1': True} {u'1': False} Fri, 29 Jun 2018 07:59:18 State has changed to 2 False counter = 456 {u'1': False} {u'1': False}

It took 456 iterations this time, but it varies. The print data['dps'] right before the if statement in the script shows that there is only one element.

It just twigged that dps could stand for "double pole switch". I was wondering what the acronym stood for...

I'm also wondering whether something is making the device reset. That would explain why it changes to False (OFF) and never to True (ON) while the program is running. I have also noticed that there is a small delay (a few seconds) before I get the message that the state has changed. Is there any way that I can test this?

[law1964]

I ran the test program a second time. It took longer the time for the light to turn off, about 27 minutes and 2963 iterations. There is definitely a delay between when the light turns off and when the program detects the change (see sample points in bold). At most, the delay should only be a second.

* Polling started Fri, 29 Jun 2018 08:27:50 2 True Fri, 29 Jun 2018 08:27:50 {u'1': True} Fri, 29 Jun 2018 08:27:51 {u'1': True} . . Fri, 29 Jun 2018 08:54:43 {u'1': True} Fri, 29 Jun 2018 08:54:43 {u'1': True} Fri, 29 Jun 2018 08:54:44 {u'1': True} Fri, 29 Jun 2018 08:54:52 {u'1': False}** Fri, 29 Jun 2018 08:54:52 State has changed to 2 False counter = 2963

[jchulce]

I have two plugs impacted by this issue. They blink on and off by themselves several times an hour. I use pytuya via tuya-homeassistant. The impacted plugs are https://www.amazon.com/EPICKA-WiFi-Smart-Plug-2-Pack/dp/B076HKHSSX/ "EPICKA WiFi Smart Plug Mini (2-Pack) - Wireless Smart Plug Socket Outlet, Compatible with Amazon Alexa and Google Assistant, No Hub Required, Remote Control Your Devices from Anywhere". These are marked with model WP1000 model: SM-PW702 FCCID:2AJ5F. I have many other tuya plugs with different brands that work just fine, it's just that one model having the issue for me. I started using https://github.com/tixi/python-tuya-experimental earlier this week and have had issues since. Seems that persistent connections makes the issue go away.

[aneisch]

Issue still persists it appears but only for some devices. Perhaps this is a firmware bug in particular Tuya devices/versions?