Can't control/get state of single socket WiFi power plugs

[richardklingler]

Controlling a 4-socket WiFi power strip works fine...

Though when using those Marmitek Power SE single socket WiFi Plugs, no state can be read nor can the switch be set to on or off....tested with version 3.1 and 3.3 protocol....

The devices.json file was created correctly with the keys for the WiFi plugs as the keys can be used in Home Assistants LocalTuya add on without any problems...

In Home Assistant I can control single socket and 4 socket power plugs...here I can only control the 4 socket power stips...

With the dps example I don't get any output...so no error message...

With the test script:

TinyTuya (Tuya Interface) [1.2.3]

TESTING: Device 8626xxxxxxxxxxxxx at 10.0.100.49 with key xxxxxxxxxxxxxxxx version 3.3

READING TEST: Response {'Error': 'Network Error: Unable to Connect', 'Err': '901', 'Payload': None}

READING TEST: Response {'Error': 'Network Error: Unable to Connect', 'Err': '901', 'Payload': None}

READING TEST: Response {'Error': 'Network Error: Unable to Connect', 'Err': '901', 'Payload': None} TIMEOUT: No response from plug 8626xxxxxxxxxxxxx [10.0.100.49] after 2 attempts.

And yes..the device is there (o;

Starting Nmap 7.70 ( https://nmap.org ) at 2021-03-06 10:26 CET Nmap scan report for 10.0.100.49 Host is up (0.0032s latency). Not shown: 999 closed ports PORT STATE SERVICE 6668/tcp open irc

Nmap done: 1 IP address (1 host up) scanned in 7.37 seconds

[jasonacox]

Hi @richardklingler Thanks for opening the issue. Would you mind trying a few things for me?

import tinytuya

tinytuya.set_debug(True)   # use tinytuya.set_debug(True,False) for non-ANSI color terminal

d = tinytuya.OutletDevice(ID, IP, KEY)
print(d)
d.set_version(3.3)
data = d.status()
print(data)

Try with device22 setting (Ideally this would be auto-detected but may not be working):

import tinytuya

tinytuya.set_debug(True)   # use tinytuya.set_debug(True,False) for non-ANSI color terminal

d = tinytuya.OutletDevice(ID, IP, KEY, 'device22')
d.set_version(3.3)
d.set_dpsUsed({"1": None})  # This needs to be a datapoint available on the device
data =  d.status()
print(data)

[richardklingler]

This is what comes without device22 set:

('86264025600194f31326', '10.0.100.49')
DEBUG:status() entry (dev_type is default)
DEBUG:building payload=b'{"gwId":"86264025600194f31326","devId":"86264025600194f31326","uid":"86264025600194f31326","t":"1615103172"}'
DEBUG:payload generated=b'\x00\x00U\xaa\x00\x00\x00\x00\x00\x00\x00\n\x00\x00\x00t{"gwId":"86264025600194f31326","devId":"86264025600194f31326","uid":"86264025600194f31326","t":"1615103172"}\x18\xf9b\xd5\x00\x00\xaaU'
DEBUG:Network connection error - retry 1/5
DEBUG:Network connection error - retry 2/5
DEBUG:Network connection error - retry 3/5
DEBUG:Network connection error - retry 4/5
DEBUG:Network connection error - retry 5/5
DEBUG:Network connection error - retry 6/5
DEBUG:Exceeded tinytuya retry limit (5)
DEBUG:Unable to connect to device 
DEBUG:ERROR Network Error: Unable to Connect - 901 - payload: null
DEBUG:status received data={'Error': 'Network Error: Unable to Connect', 'Err': '901', 'Payload': None}
{'Error': 'Network Error: Unable to Connect', 'Err': '901', 'Payload': None}

And with device22:

('86264025600194f31326', '10.0.100.49') DEBUG:status() entry (devtype is device22) DEBUG:building payload=b'{"devId":"86264025600194f31326","uid":"86264025600194f31326","t":"1615103665","dps":{"1":null}}' DEBUG:payload generated=b"\x00\x00U\xaa\x00\x00\x00\x00\x00\x00\x00\r\x00\x00\x00w3.3\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00K\xa8\xee\xb8\xe3\x13\xcd\x04\x89a;\xd1\x12\x80f\xf0\xfa*\xd4\xa3Q\x0b\x15?M\xe9E\xa0:\x05X \xbe\xf3\x11Ao\x94\xcas8: \xad\xdb\xe3\x00\xb9\x00\xdd\x1c\xa4\x83\xdd\x8c\xe0\x88\xc7\xd8\x98\xcc\xa6\x7f\x94\xb7\x9cy<\xb7\x14\n=OJ5'\x85\xcf\xf2\xaa\x86'm\x8c\x8a\xbc\xd9\x81C\xcd\x87\xe9\xc9\xe20s\xa4\xf9\xd7\x00\x00\xaaU" DEBUG:Network connection error - retry 1/5 DEBUG:Network connection error - retry 2/5 DEBUG:Network connection error - retry 3/5 DEBUG:Network connection error - retry 4/5 DEBUG:Network connection error - retry 5/5 DEBUG:Network connection error - retry 6/5 DEBUG:Exceeded tinytuya retry limit (5) DEBUG:Unable to connect to device DEBUG:ERROR Network Error: Unable to Connect - 901 - payload: null DEBUG:status received data={'Error': 'Network Error: Unable to Connect', 'Err': '901', 'Payload': None} {'Error': 'Network Error: Unable to Connect', 'Err': '901', 'Payload': None}

Datapoint set to 1 as the LocalTuya plugins detects datapoints 1 and 9 in Home Assistant.

[jasonacox]

Thanks @richardklingler - Can you confirm that nothing else is trying to connect to the device at the same time? If you have Home Assistant or the SmartLife app connected to the device it will refuse all other connections.

TinyTuya and Localtuya use the same base code from pytuya and the same pack/unpack TuyaMessage encoding functions. They do differ on the encryption library, but before I explore that, I just want to verify that it isn't caused by the single threaded nature of the Tuya device stack.

[richardklingler]

Good morning

Though the devices are set up in Home Assistant and in the iOS app, they don't access they don't access the WiFi plugs as I can control them either from the app or Home Assistant...( 2 WiFi plug single socket, 1 4 socket power strip)

From your script I can only access the 4 socket power strip....

Interesting that the scan command only finds one device:

[Loaded devices.json - 3 devices]

Scanning on UDP ports 6666 and 6667 for devices (15 retries)...

Steckdosenleiste [Valid payload]: 10.0.100.44 ID = bf6ec702f4e781239e1oov, Product ID = key4c4y5nd5mnh37, Version = 3.3 Status: {'1': False, '2': False, '3': False, '4': False, '7': False, '9': 0, '10': 0, '11': 0, '12': 0, '15': 0, '18': 0, '19': 0, '20': 2315, '21': 1, '22': 641, '23': 24439, '24': 14837, '25': 1404}

Scan Complete! Found 1 devices.

whereas the LocalTuya HA plugin finds all three...

[richardklingler]

This is really odd....now it can find all 3 devices and read the states from them, either with python 2 or 3:

TinyTuya (Tuya device scanner) [1.2.3]

[Loaded devices.json - 3 devices]

Scanning on UDP ports 6666 and 6667 for devices (15 retries)...

Steckdosenleiste [Valid payload]: 10.0.100.44 ID = bf6ec702f4e781239e1oov, Product ID = key4c4y5nd5mnh37, Version = 3.3 Status: {u'11': 0, u'10': 0, u'12': 0, u'15': 0, u'21': 1, u'22': 641, u'23': 24439, u'19': 0, u'18': 0, u'1': False, u'3': False, u'2': False, u'4': False, u'7': False, u'24': 14837, u'9': 0, u'20': 2362, u'25': 1404} Wi-Fi plug [Valid payload]: 10.0.100.49 ID = 86264025600194f31326, Product ID = keycrnyqtdhe8pcm, Version = 3.3 Status: {u'1': False, u'9': 0} Wi-Fi plug 2 [Valid payload]: 10.0.100.50 ID = 862640252462ab48123a, Product ID = keycrnyqtdhe8pcm, Version = 3.3 Status: {u'1': False, u'9': 0}

Scan Complete! Found 3 devices.

[richardklingler]

Okay...probably know what is going on:

The 4-socket power strip works with tinytuya regardless if it is configured in Home Assistant or not... Even with the test script you see on the HA dash board when one socket is switched on and later off.

But not with the single socket WiFi plugs....seems they can't handle concurrent sessions..... as soon I remove them from HA it works fine....and are controllable.

I assume this is some limitation in their ESP8266 or whatever firmware (o;

Sorry for confusions (o; Case closed ;-)

[jasonacox]

Thanks for the update @richardklingler ! Yes, I've seen a similar behavior. Some devices have a firmware that accepts multiple connections, but most do not. When a device is configured in Home Assistant, HA uses localtuya to make a persistent connect to the device. For the single threaded devices, that blocks others from connecting while it is in HA.

I should probably add a note to the 901 error code (Network Error: Unable to Connect) to raise that possibility for troubleshooting help.