jasonacox
3.4 protocol is not supported
Hi @koyaya - thanks for opening this issue. You are correct. TinyTuya does not yet support 3.4 protocol. I don't have a 3.4 device yet so I'm limited on what I can do. I'm very happy to accept any PRs to help us expand support to 3.4.
Can you provide a bit more context to help us?
- What device are you using (a link would be helpfpul)?
- Have you found another project that works with your 3.4 device?
Ref:
- https://github.com/codetheweb/tuyapi/issues/481
- https://github.com/rospogrigio/localtuya/issues/812
Note on protocol: https://github.com/codetheweb/tuyapi/issues/481#issuecomment-921756711
@harryzz has figured out the protocol and added code to a forked version of tuyapi (node library) to support 3.4. This could be converted to python and incorporated into TinyTuya if someone has a device they can use to test.
i didn't find anything that supports 3.4 will be cool if you would be the first one to support it
i can help you
this is the device that i have
US $5.80 42%OFF | Tuya Smart Wifi Motor Switch Module 5V 12V 32V 220V RF 433 Radio Remote Control 4 Channels Inching Relay for Alexa Google Home https://a.aliexpress.com/_vl0Ak2
On Mon, Jul 4, 2022, 10:28 PM Jason Cox @.***> wrote:
Hi @koyaya https://github.com/koyaya - thanks for opening this issue. You are correct. TinyTuya does not yet support 3.4 protocol. I don't have a 3.4 device yet so I'm limited on what I can do. I'm very happy to accept any PRs to help us expand support to 3.4.
Can you provide a bit more context to help us?
- What device are you using (a link would be helpfpul)?
- Have you find another project that works with your 3.4 device?
Ref:
- codetheweb/tuyapi#481 https://github.com/codetheweb/tuyapi/issues/481
- rospogrigio/localtuya#812 https://github.com/rospogrigio/localtuya/issues/812
— Reply to this email directly, view it on GitHub https://github.com/jasonacox/tinytuya/issues/148#issuecomment-1174155377, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIX2L5NQWAMEFNO6Y6A563VSM3OVANCNFSM52SZKUTA . You are receiving this because you were mentioned.Message ID: @.***>
Hi, This gateway from silvercrest (lidl) support v 3.4: https://paulbanks.org/projects/lidl-zigbee/#overview available on ebay.de.
regards, Zahari
what i have isn't a gateway, this is a smart relay, like a switch, only with 4 channels
On Tue, Jul 5, 2022, 2:55 PM Zahari Zahariev @.***> wrote:
Hi, This gateway from silvercrest (lidl) support v 3.4: https://paulbanks.org/projects/lidl-zigbee/#overview available on ebay.de.
regards, Zahari
— Reply to this email directly, view it on GitHub https://github.com/jasonacox/tinytuya/issues/148#issuecomment-1174973068, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIX2L66I32YW27VMEXDZP3VSQPCRANCNFSM52SZKUTA . You are receiving this because you were mentioned.Message ID: @.***>
Agree @koyaya , it would be great to get this added. I will see if I can get one of these devices.
Hi @harryzz , thanks for your help! Are you aware of any other smart plugs, lights or others that use 3.4?
@jasonacox i got this Mini Smart Switch and it's a 3,4 device and it's also cheap. With mine,on tinytuya scan i get this:
Access rejected by 192.168.188.50: Unexpected Payload from Device
Thanks @pretoriano80 - I'll working on getting a 3.4 device so I can see what we can do to add this support to TinyTuya. It does seem like 3.4 device are still very scarce.
Hi folks, I just received 10x superbrightleds.com G4-RGBW3W. To my surprise they are running 3.4. Please let me know which branch to pull and what debugs you would like.
HI @orrious - thanks for the info, can you post the link? Also, can you try to run scan with the latest version (1.6.4)? python -m tinytuya scan
https://www.superbrightleds.com/moreinfo/miniature-and-subminiature-bulbs/g4-led-smart-bi-pin-bulb-rgbw-color-changing-hubless-alexa-google-assistant-wi-fi-compatible-bluetooth-controller/6977/18351/
# python3 -m tinytuya scan
TinyTuya (Tuya device scanner) [1.6.4]
[Loaded devices.json - 6 devices]
Scanning on UDP ports 6666 and 6667 for devices (21 retries)...
Walkway-02 Product ID = key8u54q9dtru5jw [Valid payload]:
Address = 192.168.100.102, Device ID = eb0123456789001234567890, Local Key = 0123456789ABCDEF, Version = 3.4, MAC = cc:8c:bf:62:94:a4
Access rejected by 192.168.100.102: Unexpected Payload from Device
Walkway-03 Product ID = key8u54q9dtru5jw [Valid payload]:
Address = 192.168.100.103, Device ID = eb0123456789001234567891, Local Key = 0123456789ABCDEF, Version = 3.4, MAC = cc:8c:bf:62:92:54
Access rejected by 192.168.100.103: Unexpected Payload from Device
Walkway-01 Product ID = key8u54q9dtru5jw [Valid payload]:
Address = 192.168.100.101, Device ID = eb0123456789001234567892, Local Key = 0123456789ABCDEF, Version = 3.4, MAC = cc:8c:bf:62:92:51
Access rejected by 192.168.100.101: Unexpected Payload from Device
Walkway-04 Product ID = key8u54q9dtru5jw [Valid payload]:
Address = 192.168.100.104, Device ID = eb0123456789001234567893, Local Key = 0123456789ABCDEF, Version = 3.4, MAC = cc:8c:bf:62:90:47
Access rejected by 192.168.100.104: Unexpected Payload from Device
Walkway-06 Product ID = key8u54q9dtru5jw [Valid payload]:
Address = 192.168.100.106, Device ID = eb0123456789001234567894, Local Key = 0123456789ABCDEF, Version = 3.4, MAC = cc:8c:bf:62:8b:91
Access rejected by 192.168.100.106: Unexpected Payload from Device
Walkway-05 Product ID = key8u54q9dtru5jw [Valid payload]:
Address = 192.168.100.105, Device ID = eb0123456789001234567895, Local Key = 0123456789ABCDEF, Version = 3.4, MAC = cc:8c:bf:62:8c:f7
Access rejected by 192.168.100.105: Unexpected Payload from Device
Device ID and Local Keys have been obfuscated, but their sizes are accurate.
Thanks! Positive sign is that it is broadcasting the Tuya discovery UDP packets. We need to add the code to handle the 3.4 decryption in the core.py _decode_payload() function.
@harryzz has done the discovery and has working code in Node (JS) https://github.com/codetheweb/tuyapi/issues/481#issuecomment-921756711 (see code here) - we need to convert it to python.
Due to not being able to tuya-convert these devices to my own firmware, I've no choice but to run them on an isolated network. That said, it makes it easy to provide a developer with access to them while implementing version 3.4 I'm happy to provide a RPi or run a container of your choice on that network.
I'm using this smart bulb and it's also running version 3.4. I can help with testing, if need be.
Logs:
TinyTuya (Tuya device scanner) [1.6.4]
[Loaded devices.json - 3 devices]
Scanning on UDP ports 6666 and 6667 for devices (18 retries)...
First hall light Product ID = key8u54q9dtru5jw [Valid payload]:
Address = 192.168.0.103, Device ID = bf9cbf4d50f588d20ebwac, Local Key = 7544f9f750819bee, Version = 3.4, MAC = cc:8c:bf:4e:bb:22
Access rejected by 192.168.0.103: Unexpected Payload from Device
Thank you, @manj9501
A few more things could help if anyone has time to explore:
- What information do you see about these 3.4 devices in the iot.tuya.com console? Specifically any documentation that appears about the 3.4 version.
- Are you able to use the TinyTuya cloud functions to control these 3.4 devices?
- Has there been any official communication from Tuya about 3.4 devices since it seems the adoption of this new protocol is extremely low. I ask to help understand why they proposed a different protocol. 3.1 to 3.3 was to introduce full encryption. I'm not able to determine the 3.3 to 3.4 justification.
I have a 3.4 device on order to use for testing. @orrious I would like to try to avoid using your network for my disruptive testing but I'll let you know, and will definitely appreciate your help once we have code to test.
Thanks for the help!
I just ordered some WiFi bulbs and one of them came with Firmware version 1.3.21 which has protocol 3.4 which brought me here.
Cloud function in native Tuya integration can send state change commands but does not receive any state updates. I also compared the device debugging screen on the iot.tuya.com between a protocol 3.3 and a protocol 3.4 device and all the data is identical ... cant see any difference on the portal between the two devices.
Using harryzz/tuyapi version I can connect to the light and get the data packet with all the values for the relevant dps. However, device.set does not work and times out with an error message : Error! Timeout waiting for status response from device id: xxxxxx
Let me know if there is anything I can do to help push this further.
Thanks!
Thanks to the brilliant work by @uzlonewolf we now have 3.4 device support in TinyTuya. We have not yet released this to PyPI, but that will come after some additional testing.
Everyone here, if you can, please test this new code on your 3.4 devices:
git clone https://github.com/jasonacox/tinytuya.git
cd tinytuya
# Use Wizard to Scan
python3 -m tinytuya wizard
# Use Scanner
cp /path/to/devices.json devices.json
python3 -m tinytuya scan
# Test with your local key
python3
import tinytuya
d = tinytuya.OutletDevice('id', '10.0.1.90', 'key')
d.set_version(3.4)
print(" > Fetch Status < ")
data = d.status()
print(data)
print(" > Turn On < ")
d.turn_on()
data = d.status()
print(data)
print(" > Wait 5 sec < ")
time.sleep(5)
print(" > Turn Off< ")
d.turn_off()
data = d.status()
print(data)
Upon using python3 -m tinytuya scan, I get the following output:
TinyTuya (Tuya device scanner) [1.7.0]
[Loaded devices.json - 3 devices]
Scanning on UDP ports 6666 and 6667 for devices (18 retries)...
Second hall light Product ID = keytg5kq8gvkv9dh [Valid payload]:
Address = 192.168.0.102, Device ID = eb0123456789001234567890, Local Key = 0123456789ABCDEF, Version = 3.3, MAC = cc:xx:xx:09:xx:71
Status: {'20': False, '21': 'white', '22': 10, '23': 270, '24': '000003e803e8', '25': '000e0d0000000000000000c80000', '26': 0, '34': True}
Third light Product ID = keytg5kq8gvkv9dh [Valid payload]:
Address = 192.168.0.100, Device ID = eb0123456789001234567890, Local Key = 0123456789ABCDEF, Version = 3.3, MAC = xx:1f:xx:ef:xx:77
Status: {'20': False, '21': 'colour', '22': 10, '23': 270, '24': '003203e8000a', '25': '000e0d0000000000000000c80000', '26': 0, '34': True}
First hall light Product ID = key8u54q9dtru5jw [Valid payload]:
Address = 192.168.0.101, Device ID = bfce70xxxxxxxxx69tll2, Local Key = 1055xxxxxx6f120d, Version = 3.4, MAC = xx:8c:xx:4e:xx:22
Status: {'20': True, '21': 'white', '22': 10, '23': 270, '24': '000003e803e8', '25': '000e0d0000000000000000c80000', '26': 0, '34': True, '41': True}
Scan Complete! Found 3 devices.
>> Saving device snapshot data to snapshot.json
I can successfully see the DPs connected to my v3.4 Smart Bulb (though not sure what DP 41 is).
Now after modifying the script given by @jasonacox for Bulb Devices, I get the following output:
$ python3 Tuya.py
> Fetch Status <
{'Error': 'Unexpected Payload from Device', 'Err': '904', 'Payload': None}
> Turn On <
Traceback (most recent call last):
File "C:\Users\manj9\tinytuya\Tuya.py", line 11, in <module>
d.turn_on()
File "C:\Users\manj9\tinytuya\tinytuya\BulbDevice.py", line 257, in turn_on
self.set_status(True, switch, nowait=nowait)
File "C:\Users\manj9\tinytuya\tinytuya\core.py", line 1252, in set_status
payload = self.generate_payload(CONTROL, {switch: on})
File "C:\Users\manj9\tinytuya\tinytuya\core.py", line 1215, in generate_payload
return self._generate_message(command_override, payload)
File "C:\Users\manj9\tinytuya\tinytuya\core.py", line 928, in _generate_message
payload = self.version_header + payload
AttributeError: 'BulbDevice' object has no attribute 'version_header'
Here's the modified script:
import tinytuya
d = tinytuya.BulbDevice('bfce70xxxxxxxxxb69tll2', '192.168.0.101', '1055xxxxxx6f120d')
d.set_version(3.4)
print(" > Fetch Status < ")
data = d.status()
print(data)
print(" > Turn On < ")
d.turn_on()
data = d.status()
print(data)
print(" > Wait 5 sec < ")
time.sleep(5)
print(" > Turn Off< ")
d.turn_off()
data = d.status()
print(data)
@manj9501 Fixed with #182. tinytuya/BulbDevice.py needs set_version to call super(BulbDevice, self).set_version(version) instead of simply doing self.version = version
I can confirm that the modifications made in #182 have solved the previously encountered error whilst running the BulbDevice script.
Thanks for the great work, @uzlonewolf!
@manj9501 -Thanks for testing and the bug find on the BulbDevice!
And, thanks @uzlonewolf ! Brilliant work! Also, I love the version= to constructor addition! Old code will still work (as will anything using pytuya) but would allow us to update all the README and example scripts to a more intuitive (and if wanted, self descriptive) way:
d = tinytuya.OutletDevice(
dev_id='xxxxxxxxxxxxxxxxxxxxxxxx',
address='x.x.x.x',
local_key='xxxxxxxxxxxxxxxx',
version=3.4)
print(d.status())
PR #182 merged.
Others - please test if you can and post results.
TinyTuya v1.7.0 with 3.4 protocol support has been released to PyPI. Credit to @uzlonewolf !
pip install --upgrade tinytuya
python -m tinytuya version
TinyTuya [1.7.0]
Thanks everyone for your interest and support.