I am trying to flash a Woox R5077 (tuya wifi bulb) wifi RGB GU10 lightbulb. Today i already did it succesfully with one, but i didn't use that bulb for some time with the tuya app. The one i'm trying now has been used recently with the tuya app and its firmware might have been updated?
Any suggestions for trying?
I get the following output from running start_flash.sh:
./start_flash.sh
Checking for network interface wlo1... Found.
Checking UDP port 53... Occupied by systemd-resolve with PID 2159.
Port 53 is needed to resolve DNS queries
Do you wish to terminate systemd-resolve? [y/N] y
Attempting to stop systemd-resolved.service
Checking UDP port 67... Available.
Checking TCP port 80... Available.
Checking TCP port 443... Available.
Checking UDP port 6666... Available.
Checking UDP port 6667... Available.
Checking TCP port 1883... Available.
Checking TCP port 8886... Available.
======================================================
Starting AP in a screen..
Starting web server in a screen
Starting Mosquitto in a screen
Starting PSK frontend in a screen
Starting Tuya Discovery in a screen
======================================================
IMPORTANT
1. Connect any other device (a smartphone or something) to the WIFI vtrust-flash
This step is IMPORTANT otherwise the smartconfig may not work!
2. Put your IoT device in autoconfig/smartconfig/pairing mode (LED will blink fast). This is usually done by pressing and holding the primary button of the device
Make sure nothing else is plugged into your IoT device while attempting to flash.
3. Press ENTER to continue
======================================================
Starting smart config pairing procedure
Waiting for the device to install the intermediate firmware
Put device in EZ config mode (blinking fast)
Sending SSID vtrust-flash
Sending wifiPassword
Sending token 00000000
Sending secret 0101
................
SmartConfig complete.
Resending SmartConfig Packets
.................
SmartConfig complete.
Resending SmartConfig Packets
..................
SmartConfig complete.
Resending SmartConfig Packets
.................
SmartConfig complete.
Resending SmartConfig Packets
..................
SmartConfig complete.
Resending SmartConfig Packets
..................
SmartConfig complete.
Resending SmartConfig Packets
.................
SmartConfig complete.
Resending SmartConfig Packets
.................
SmartConfig complete.
Resending SmartConfig Packets
.................
SmartConfig complete.
Resending SmartConfig Packets
................
SmartConfig complete.
Resending SmartConfig Packets
..........
Device did not appear with the intermediate firmware
Check the *.log files in the scripts folder
Do you want to try flashing another device? [y/N] n
Logs
smarthack-mqtt.log
smarthack-psk.log
smarthack-udp.log
smarthack-web.log
smarthack-wifi.log
could not establish sslpsk socket:
returned a result with an error set
This line in your psk log suggests your OpenSSL is outdated.
could not establish sslpsk socket:
returned a result with an error set This line in your psk log suggests your OpenSSL is outdated.
i checked and this is due to my own attempts reading issues on github, one recommended changing psk-frontend.py shebang to python3, afterwards i reverted it back, which shows expected errors again in the error logs. thanks for noticing though! Sorry for the mess in the logs, should have cleared them.
Could you please check your OpenSSL version?
Run openssl version. I believe it should be at least 1.1.1.
openssl version
OpenSSL 1.1.1 11 Sep 2018
OK great, we can rule that out. Can you repeat the process while recording the network traffic? Run tcpdump -i wlo1 -w capture.pcap and attempt start_flash again.
I cleaned all my log files and did one more try. Probably better to look at these:
smarthack-mqtt.log
smarthack-psk.log
smarthack-udp.log
smarthack-web.log
smarthack-wifi.log
had to rename extension, since github doesn't support upload of .pcap files apparently, but its the pcap file as requested
capture.txt
This latest attempt, the device never connected. I can see the device MAC address in your earlier wifi log. See if you can get there again.
FYI once the device makes a connection (appears in wifi log) you do not need to repeat the pairing process with each attempt. It will automatically reconnect when you run start_flash again unless you put it back into pairing mode (resetting the wifi config).
It just seems i am not able to connect to these specific bulbs (the one in the first log i posted is probably the bulb that i did manage to convert). They are all exactly the same, except that i didn't use the first bulb with the Tuya app recently. I can still pair with the tuya app itself without a problem while pairing so its something else..
OK I see. It is added to the Tuya app now? Can you retrieve the device info?
I did see a user post about a week ago that they thought they'd encountered a device with an ESP82xx that would not take the TC flash... because it appeared the the Tuya firmware had been patched ☹️ I hope not...
OK I see. It is added to the Tuya app now? Can you retrieve the device info?
What info do you need to know? i had tuya-cli working at some point
[ { name: 'GU10 Smart Bulb R5077 5',
id: '75014088b4e62d6bfd59',
key: '1ee8539aef2271e4' },
For this specific light i get the above information from tuya-cli by adding it to the app again
@meingraham could you link to the discussion? A copy of the firmware in question would be really valuable.
@jcageman if you have the device added to your network, you can run tuya-discovery.py on the same network to pick up the relevant device information.
tuya-discovery.py
Thanks, it says listening and took a long time to give some info back. From the tuya app i was able to find that 75014088b4e62d6bfd59 is the one i am trying to flash at the moment. Would it be possible to join a chat/discord or whatever to speed up the conversation (if you don't mind of course)
192.168.1.107 {'ip': '192.168.1.107', 'gwId': '686633613c71bf33fe74', 'active': 2, 'ability': 0, 'mode': 0, 'encrypt': True, 'productKey': 'key35nu9wt9xxnv4', 'version': '3.3'}
192.168.1.106 {'ip': '192.168.1.106', 'gwId': '54263524807d3a2ce659', 'active': 2, 'ability': 0, 'mode': 0, 'encrypt': True, 'productKey': 'key4fv3xs8twchhy', 'version': '3.1'}
192.168.1.106 {'ip': '192.168.1.106', 'gwId': '54263524807d3a2ce659', 'active': 2, 'ability': 0, 'mode': 0, 'encrypt': True, 'productKey': 'key4fv3xs8twchhy', 'version': '3.1'}
192.168.1.106 {'ip': '192.168.1.106', 'gwId': '54263524807d3a2ce659', 'active': 2, 'ability': 0, 'mode': 0, 'encrypt': True, 'productKey': 'key4fv3xs8twchhy', 'version': '3.1'}
192.168.1.102 {'ip': '192.168.1.102', 'gwId': '75014088b4e62d6bfd59', 'active': 2, 'ability': 0, 'mode': 0, 'encrypt': True, 'productKey': 'keywrqvhydt3ghp3', 'version': '3.3'}
192.168.1.102 {'ip': '192.168.1.102', 'gwId': '75014088b4e62d6bfd59', 'active': 2, 'ability': 0, 'mode': 0, 'encrypt': True, 'productKey': 'keywrqvhydt3ghp3', 'version': '3.3'}
192.168.1.105 {'ip': '192.168.1.105', 'gwId': '02704107bcddc2a2c4d2', 'active': 2, 'ability': 0, 'mode': 0, 'encrypt': True, 'productKey': 'key4fv3xs8twchhy', 'version': '3.1'}
192.168.1.105 {'ip': '192.168.1.105', 'gwId': '02704107bcddc2a2c4d2', 'active': 2, 'ability': 0, 'mode': 0, 'encrypt': True, 'productKey': 'key4fv3xs8twchhy', 'version': '3.1'}
192.168.1.105 {'ip': '192.168.1.105', 'gwId': '02704107bcddc2a2c4d2', 'active': 2, 'ability': 0, 'mode': 0, 'encrypt': True, 'productKey': 'key4fv3xs8twchhy', 'version': '3.1'}
192.168.1.102 {'ip': '192.168.1.102', 'gwId': '75014088b4e62d6bfd59', 'active': 2, 'ability': 0, 'mode': 0, 'encrypt': True, 'productKey': 'keywrqvhydt3ghp3', 'version': '3.3'}
192.168.1.105 {'ip': '192.168.1.105', 'gwId': '02704107bcddc2a2c4d2', 'active': 2, 'ability': 0, 'mode': 0, 'encrypt': True, 'productKey': 'key4fv3xs8twchhy', 'version': '3.1'}
192.168.1.102 {'ip': '192.168.1.102', 'gwId': '75014088b4e62d6bfd59', 'active': 2, 'ability': 0, 'mode': 0, 'encrypt': True, 'productKey': 'keywrqvhydt3ghp3', 'version': '3.3'}
192.168.1.105 {'ip': '192.168.1.105', 'gwId': '02704107bcddc2a2c4d2', 'active': 2, 'ability': 0, 'mode': 0, 'encrypt': True, 'productKey': 'key4fv3xs8twchhy', 'version': '3.1'}
192.168.1.105 {'ip': '192.168.1.105', 'gwId': '02704107bcddc2a2c4d2', 'active': 2, 'ability': 0, 'mode': 0, 'encrypt': True, 'productKey': 'key4fv3xs8twchhy', 'version': '3.1'}
192.168.1.102 {'ip': '192.168.1.102', 'gwId': '75014088b4e62d6bfd59', 'active': 2, 'ability': 0, 'mode': 0, 'encrypt': True, 'productKey': 'keywrqvhydt3ghp3', 'version': '3.3'}
192.168.1.105 {'ip': '192.168.1.105', 'gwId': '02704107bcddc2a2c4d2', 'active': 2, 'ability': 0, 'mode': 0, 'encrypt': True, 'productKey': 'key4fv3xs8twchhy', 'version': '3.1'}
192.168.1.105 {'ip': '192.168.1.105', 'gwId': '02704107bcddc2a2c4d2', 'active': 2, 'ability': 0, 'mode': 0, 'encrypt': True, 'productKey': 'key4fv3xs8twchhy', 'version': '3.1'}
192.168.1.102 {'ip': '192.168.1.102', 'gwId': '75014088b4e62d6bfd59', 'active': 2, 'ability': 0, 'mode': 0, 'encrypt': True, 'productKey': 'keywrqvhydt3ghp3', 'version': '3.3'}
192.168.1.105 {'ip': '192.168.1.105', 'gwId': '02704107bcddc2a2c4d2', 'active': 2, 'ability': 0, 'mode': 0, 'encrypt': True, 'productKey': 'key4fv3xs8twchhy', 'version': '3.1'}
192.168.1.107 {'ip': '192.168.1.107', 'gwId': '686633613c71bf33fe74', 'active': 2, 'ability': 0, 'mode': 0, 'encrypt': True, 'productKey': 'key35nu9wt9xxnv4', 'version': '3.3'}
192.168.1.106 {'ip': '192.168.1.106', 'gwId': '54263524807d3a2ce659', 'active': 2, 'ability': 0, 'mode': 0, 'encrypt': True, 'productKey': 'key4fv3xs8twchhy', 'version': '3.1'}
192.168.1.107 {'ip': '192.168.1.107', 'gwId': '686633613c71bf33fe74', 'active': 2, 'ability': 0, 'mode': 0, 'encrypt': True, 'productKey': 'key35nu9wt9xxnv4', 'version': '3.3'}
192.168.1.106 {'ip': '192.168.1.106', 'gwId': '54263524807d3a2ce659', 'active': 2, 'ability': 0, 'mode': 0, 'encrypt': True, 'productKey': 'key4fv3xs8twchhy', 'version': '3.1'}
192.168.1.106 {'ip': '192.168.1.106', 'gwId': '54263524807d3a2ce659', 'active': 2, 'ability': 0, 'mode': 0, 'encrypt': True, 'productKey': 'key4fv3xs8twchhy', 'version': '3.1'}
192.168.1.106 {'ip': '192.168.1.106', 'gwId': '54263524807d3a2ce659', 'active': 2, 'ability': 0, 'mode': 0, 'encrypt': True, 'productKey': 'key4fv3xs8twchhy', 'version': '3.1'}
192.168.1.106 {'ip': '192.168.1.106', 'gwId': '54263524807d3a2ce659', 'active': 2, 'ability': 0, 'mode': 0, 'encrypt': True, 'productKey': 'key4fv3xs8twchhy', 'version': '3.1'}
192.168.1.106 {'ip': '192.168.1.106', 'gwId': '54263524807d3a2ce659', 'active': 2, 'ability': 0, 'mode': 0, 'encrypt': True, 'productKey': 'key4fv3xs8twchhy', 'version': '3.1'}
192.168.1.106 {'ip': '192.168.1.106', 'gwId': '54263524807d3a2ce659', 'active': 2, 'ability': 0, 'mode': 0, 'encrypt': True, 'productKey': 'key4fv3xs8twchhy', 'version': '3.1'}
192.168.1.106 {'ip': '192.168.1.106', 'gwId': '54263524807d3a2ce659', 'active': 2, 'ability': 0, 'mode': 0, 'encrypt': True, 'productKey': 'key4fv3xs8twchhy', 'version': '3.1'}
192.168.1.106 {'ip': '192.168.1.106', 'gwId': '54263524807d3a2ce659', 'active': 2, 'ability': 0, 'mode': 0, 'encrypt': True, 'productKey': 'key4fv3xs8twchhy', 'version': '3.1'}
192.168.1.106 {'ip': '192.168.1.106', 'gwId': '54263524807d3a2ce659', 'active': 2, 'ability': 0, 'mode': 0, 'encrypt': True, 'productKey': 'key4fv3xs8twchhy', 'version': '3.1'}
192.168.1.105 {'ip': '192.168.1.105', 'gwId': '02704107bcddc2a2c4d2', 'active': 2, 'ability': 0, 'mode': 0, 'encrypt': True, 'productKey': 'key4fv3xs8twchhy', 'version': '3.1'}
192.168.1.102 {'ip': '192.168.1.102', 'gwId': '75014088b4e62d6bfd59', 'active': 2, 'ability': 0, 'mode': 0, 'encrypt': True, 'productKey': 'keywrqvhydt3ghp3', 'version': '3.3'}
192.168.1.105 {'ip': '192.168.1.105', 'gwId': '02704107bcddc2a2c4d2', 'active': 2, 'ability': 0, 'mode': 0, 'encrypt': True, 'productKey': 'key4fv3xs8twchhy', 'version': '3.1'}
192.168.1.106 {'ip': '192.168.1.106', 'gwId': '54263524807d3a2ce659', 'active': 2, 'ability': 0, 'mode': 0, 'encrypt': True, 'productKey': 'key4fv3xs8twchhy', 'version': '3.1'}
I'm having the exact same issue with a new pair of AUKEY SH-PA1s bought off of Amazon.ca within the last couple if weeks.
After seeing this I'm really hoping the firmware isn't patched.
OK it looks like this device should be compatible with tuya-convert.
The last 12 characters of the gwId is the MAC address, which on looking up the OUI, is definitely an Espressif device. Version 3.3 is the TLS firmware so it should be making calls through the psk-frontend which we should see in the psk log.
It seems like the current roadblock is just getting the device added to the vtrust-flash network.
We don't have an official chatroom but I assure you I am keeping this thread open.
@ViXXoR can you provide more details as to how your issue is related? The issue we're seeing here is that the device is not pairing. If you have been able to flash other devices but have a device that will not appear in the wifi log, it might be the same issue.
just checking, but myvtrust-flash network has no password, while i read some guides which say flashmeifyoucan should be the password. I also connect to it with my phone without issues, which is also shown in the logs, but the bulb doesn't somehow.
I believe it is related.
I just flashed a couple CE plugs a day or two ago with no issues. With the AUKEY, it flashes the intermediate firmware and never goes past that. I get the same "device did not appear" and I see the SSL cipher errors in smarthack-psk log.
In this issue, @jcageman was not able to install the intermediate firmware, so it is not likely related. The SSL cipher errors are irrelevant as the device never connected, so they are from another device (likely the mobile device).
@jcageman the password requirement was removed a few versions back to make the process easier.
@jcageman I have another idea, since you're able to get the device added to tuya-cli, we can issue a command to force the device to switch from your home network to vtrust-flash.
I'm assuming you already have tuyapi, if not do npm i -g tuyapi.
Then open a NodeJS repl, node.
Paste the following
const {MessageParser, CommandType} = require('tuyapi/lib/message-parser')
function switchAP( ip, key ){
const payload = JSON.stringify({
ssid: "vtrust-flash",
passwd: "",
token: ""
})
const parser = new MessageParser({
key,
version: 3.3
})
const buffer = parser.encode({
data: payload,
commandByte: CommandType.AP_CONFIG,
sequenceN: 0
})
const client = new net.Socket
client.connect( 6668, ip )
client.on( 'connect', () => {
client.write( buffer )
client.destroy()
})
client.on( 'error', console.log )
}
Then type switchAP( <device IP>, <device key> )
This should ask the device to switch from your home network to the vtrust-flash network. I believe it is OK to do this even when vtrust-flash isn't running, it will connect when it becomes available and then you can skip the pairing process.
@kueblc I may have made an incorrect assumption in saying that the intermediate firmware was flashed.
My output matches what the OP was showing, so I may in fact be in the same boat.
I'll simply follow this thread and try any solutions that come up and see if they help.
@ViXXoR you can check if the intermediate flashed by looking in your web log. If it did, you should see two requests for upgrade.bin. The output for a device that fails to complete the process will look the same regardless of the underlying cause, but you can find out more by reading the logs.
I'm assuming you already have
tuyapi, if not donpm i -g tuyapi.Then open a NodeJS repl,
node.Paste the following
const {MessageParser, CommandType} = require('tuyapi/lib/message-parser') function switchAP( ip, key ){ const payload = JSON.stringify({ ssid: "vtrust-flash", passwd: "", token: "" }) const parser = new MessageParser({ key, version: 3.3 }) const buffer = parser.encode({ data: payload, commandByte: CommandType.AP_CONFIG, sequenceN: 0 }) const client = new net.Socket client.connect( 6668, ip ) client.on( 'connect', () => { client.write( buffer ) client.destroy() }) client.on( 'error', console.log ) }Then type
switchAP( <device IP>, <device key> )This should ask the device to switch from your home network to the
vtrust-flashnetwork. I believe it is OK to do this even whenvtrust-flashisn't running, it will connect when it becomes available and then you can skip the pairing process.
do i have to be in pairing mode for this or just execute after already being paired to tuya app? seems not to be doing anything.
switchAP(192.168.1.102, keywrqvhydt3ghp3)
...
You need to execute that on a network which the device is already connected to. If it is paired to your home network and set up with tuya-cli, use the key from that and IP address of the device on your network.
You may also try changing CommandType.AP_CONFIG to CommandType.AP_CONFIG_NEW, not sure if that also changed with version 3.3.
You need to execute that on a network which the device is already connected to. If it is paired to your home network and set up with
tuya-cli, use the key from that and IP address of the device on your network.
Did exactly that as far as i know and the script is just hanging without doing anything
I used the discovery script to make sure i used the right information:
192.168.1.102 {'ip': '192.168.1.102', 'gwId': '75014088b4e62d6bfd59', 'active': 2, 'ability': 0, 'mode': 0, 'encrypt': True, 'productKey': 'keywrqvhydt3ghp3', 'version': '3.3'}
Also make sure that the key is the one from tuya-cli, not the productKey from tuya-discovery
Once you run the switchAP function, the change should take effect immediately, but there won't be any output. You can verify that the device has disconnected from your home network though.
Oke, seems to be hanging still.
I found the key
[ { name: 'GU10 Smart Bulb R5077 5',
id: '75014088b4e62d6bfd59',
key: '3baea4fcf4fd3549' },
Still get the following and the device is still part of the network
switchAP(192.168.1.102,3baea4fcf4fd3549)
...
Tried commandByte: CommandType.AP_CONFIG_NEW as well
switchAP(192.168.1.102,3baea4fcf4fd3549)
You must quote the arguments, sorry for not mentioning
switchAP("192.168.1.102", "3baea4fcf4fd3549")
switchAP("192.168.1.102", "3baea4fcf4fd3549")
my javascript sucks, was already doubting. It executes right away, tried both options again, not errors, but device is still part of the network
Are you able to ping 192.168.1.102?
Are you able to
ping 192.168.1.102?
ping 192.168.1.102
PING 192.168.1.102 (192.168.1.102) 56(84) bytes of data.
64 bytes from 192.168.1.102: icmp_seq=1 ttl=255 time=11.7 ms
64 bytes from 192.168.1.102: icmp_seq=2 ttl=255 time=39.8 ms
64 bytes from 192.168.1.102: icmp_seq=3 ttl=255 time=6.24 ms
64 bytes from 192.168.1.102: icmp_seq=4 ttl=255 time=86.4 ms
Hmm I am a loss right now. If we can't establish a connection, we won't be able to tell if the firmware has changed. It looks like it should be able to flash if we can get past the pairing step.
ok, i managed to connect the device though!
const TuyAPI = require('tuyapi');
const device = new TuyAPI({
id: '75014088b4e62d6bfd59',
key: '3baea4fcf4fd3549'});
(async () => {
await device.find();
await device.connect();
let status = await device.get();
console.log(`Current status: ${status}.`);
await device.set({set: !status});
status = await device.get();
console.log(`New status: ${status}.`);
device.disconnect();
})();
This toggles the light!
Excellent, so for sure we have the correct key.
Now I'm wondering if the AP_CONFIG command format has changed.
Are you comfortable and able to modify DNS requests on your home network, ie through dnsmasq on your router or on a home server? If you can capture *.tuya(us|eu|cn).com requests, we can redirect them to our fake-registration-server.
I can't find the chat. All I know was that when I saw it I ordered some of the GD-30W Diffuser so I'd get the version that I can easily Tuya-Convert... before the stock upgrades to a later Tuya firmware.
I'll keep my eyes & ears open for more buzz... should it come up again. And I will ask folks to download the firmware for analysis.
dnsmasq
Never done anything like it, i would like to have a look at the tuyAPI first, maybe we are just slightly off (i have a feeling we are already close)
I tried modifying your script a bit and added logging, but its really connecting and writing the data to it. Might really indicate a change in how to connect to these lights.
We might be able tocapture the registration process from the app.
Tomorrow i will try to flash one of the other devices which seems to be version 3.2 and see how that goes
Not to hijack the thread... but I think I was having a similar issue... and seeing this in the web log... any suggestions?
Traceback (most recent call last):
File "/usr/local/lib/python3.7/site-packages/tornado/web.py", line 1697, in _execute
result = method(self.path_args, *self.path_kwargs)
File "./fake-registration-server.py", line 224, in post
self.reply(answer, encrypted)
File "./fake-registration-server.py", line 85, in reply
payload = b64encode(AES.new(options.secKey.encode(), AES.MODE_ECB).encrypt(pad(answer))).decode()
File "/home/brian/.local/lib/python3.7/site-packages/Crypto/Cipher/_mode_ecb.py", line 135, in encrypt
c_uint8_ptr(plaintext),
File "/home/brian/.local/lib/python3.7/site-packages/Crypto/Util/_raw_api.py", line 235, in c_uint8_ptr
raise TypeError("Object type %s cannot be passed to C code" % type(data))
TypeError: Object type
[31m[E 191229 21:24:28 web:2246][m 500 POST /gw.json?a=tuya.device.dynamic.config.get&et=1&gwId=03046203807d3a2d771e&t=87&v=1.0&sign=f515eaf936ba6a2a11dea08041d888de (10.42.42.1) 7.59ms
@bryeartem not related to this issue, feel free to open a new one with your full logs attached. For a quick fix you might try adding .encode() after answer on line 85 of fake-registration-server.
this morning i tried with a few light bulbs from tuya that showed version 3.2 and they flashed without any problems. These are just normal light bulbs not spots like the GU10 one i couldn't flash.
@kueblc I may have made an incorrect assumption in saying that the intermediate firmware was flashed.
My output matches what the OP was showing, so I may in fact be in the same boat.
I'll simply follow this thread and try any solutions that come up and see if they help.
FWIW, and I feel silly having not tried this before posting, after plenty of power-cycling and watching log files, I started thinking it may be a connectivity issue.
I moved some things around and got the plug just a few physical inches from the vtrust-flash source. After that, I was able to flash two plugs without issue. I guess the antennas in some devices are significantly weaker than others.
Sorry for adding fuel to the fire without troubleshooting more myself.
I had a similar problem, and the solution was to turn off my firewall (it was stopping the communication between the raspberry with tuya convert and the lamp).
(for @kueblc : yes, I did the same error TWICE because apparently I have the memory of a goldfish xD)
It seems I have the same issue, with a version 3.3 device:
smarthack-mqtt.log
1578428296: mosquitto version 1.4.10 (build date Wed, 13 Feb 2019 00:45:38 +0000) starting
1578428296: Using default config.
1578428296: Opening ipv4 listen socket on port 1883.
1578428296: Opening ipv6 listen socket on port 1883.
^C1578428442: mosquitto version 1.4.10 terminating
smarthack-psk.log
new client on port 443 from 10.42.42.31:39720
('could not establish sslpsk socket:', SSLError(1, u'[SSL: NO_SHARED_CIPHER] no shared cipher (_ssl.c:661)'))
^CTraceback (most recent call last):
File "./psk-frontend.py", line 111, in <module>
main()
File "./psk-frontend.py", line 104, in main
r,_,_ = select.select(readables, [], [])
KeyboardInterrupt
smarthack-udp.log
Listening for Tuya broadcast on UDP 6666
Listening for encrypted Tuya broadcast on UDP 6667
10.42.42.28 b'{"ip":"10.42.42.28","gwId":"e62b573f2a5e6906","active":0,"ablilty":0,"encrypt":true,"productKey":"a3g9fxaujjgtei27","version":"3.3"}'
10.42.42.28 b'{"ip":"10.42.42.28","gwId":"e62b573f2a5e6906","active":0,"ablilty":0,"encrypt":true,"productKey":"a3g9fxaujjgtei27","version":"3.3"}'
10.42.42.28 b'{"ip":"10.42.42.28","gwId":"e62b573f2a5e6906","active":0,"ablilty":0,"encrypt":true,"productKey":"a3g9fxaujjgtei27","version":"3.3"}'
10.42.42.28 b'{"ip":"10.42.42.28","gwId":"e62b573f2a5e6906","active":0,"ablilty":0,"encrypt":true,"productKey":"a3g9fxaujjgtei27","version":"3.3"}'
10.42.42.28 b'{"ip":"10.42.42.28","gwId":"e62b573f2a5e6906","active":0,"ablilty":0,"encrypt":true,"productKey":"a3g9fxaujjgtei27","version":"3.3"}'
10.42.42.28 b'{"ip":"10.42.42.28","gwId":"e62b573f2a5e6906","active":0,"ablilty":0,"encrypt":true,"productKey":"a3g9fxaujjgtei27","version":"3.3"}'
10.42.42.28 b'{"ip":"10.42.42.28","gwId":"e62b573f2a5e6906","active":0,"ablilty":0,"encrypt":true,"productKey":"a3g9fxaujjgtei27","version":"3.3"}'
10.42.42.28 b'{"ip":"10.42.42.28","gwId":"e62b573f2a5e6906","active":0,"ablilty":0,"encrypt":true,"productKey":"a3g9fxaujjgtei27","version":"3.3"}'
10.42.42.28 b'{"ip":"10.42.42.28","gwId":"e62b573f2a5e6906","active":0,"ablilty":0,"encrypt":true,"productKey":"a3g9fxaujjgtei27","version":"3.3"}'
10.42.42.28 b'{"ip":"10.42.42.28","gwId":"e62b573f2a5e6906","active":0,"ablilty":0,"encrypt":true,"productKey":"a3g9fxaujjgtei27","version":"3.3"}'
10.42.42.28 b'{"ip":"10.42.42.28","gwId":"e62b573f2a5e6906","active":0,"ablilty":0,"encrypt":true,"productKey":"a3g9fxaujjgtei27","version":"3.3"}'
10.42.42.28 b'{"ip":"10.42.42.28","gwId":"e62b573f2a5e6906","active":0,"ablilty":0,"encrypt":true,"productKey":"a3g9fxaujjgtei27","version":"3.3"}'
10.42.42.28 b'{"ip":"10.42.42.28","gwId":"e62b573f2a5e6906","active":0,"ablilty":0,"encrypt":true,"productKey":"a3g9fxaujjgtei27","version":"3.3"}'
10.42.42.28 b'{"ip":"10.42.42.28","gwId":"e62b573f2a5e6906","active":0,"ablilty":0,"encrypt":true,"productKey":"a3g9fxaujjgtei27","version":"3.3"}'
10.42.42.28 b'{"ip":"10.42.42.28","gwId":"e62b573f2a5e6906","active":0,"ablilty":0,"encrypt":true,"productKey":"a3g9fxaujjgtei27","version":"3.3"}'
10.42.42.28 b'{"ip":"10.42.42.28","gwId":"e62b573f2a5e6906","active":0,"ablilty":0,"encrypt":true,"productKey":"a3g9fxaujjgtei27","version":"3.3"}'
10.42.42.28 b'{"ip":"10.42.42.28","gwId":"e62b573f2a5e6906","active":0,"ablilty":0,"encrypt":true,"productKey":"a3g9fxaujjgtei27","version":"3.3"}'
10.42.42.28 b'{"ip":"10.42.42.28","gwId":"e62b573f2a5e6906","active":0,"ablilty":0,"encrypt":true,"productKey":"a3g9fxaujjgtei27","version":"3.3"}'
10.42.42.28 b'{"ip":"10.42.42.28","gwId":"e62b573f2a5e6906","active":0,"ablilty":0,"encrypt":true,"productKey":"a3g9fxaujjgtei27","version":"3.3"}'
10.42.42.28 b'{"ip":"10.42.42.28","gwId":"e62b573f2a5e6906","active":0,"ablilty":0,"encrypt":true,"productKey":"a3g9fxaujjgtei27","version":"3.3"}'
10.42.42.28 b'{"ip":"10.42.42.28","gwId":"e62b573f2a5e6906","active":0,"ablilty":0,"encrypt":true,"productKey":"a3g9fxaujjgtei27","version":"3.3"}'
10.42.42.28 b'{"ip":"10.42.42.28","gwId":"e62b573f2a5e6906","active":0,"ablilty":0,"encrypt":true,"productKey":"a3g9fxaujjgtei27","version":"3.3"}'
10.42.42.28 b'{"ip":"10.42.42.28","gwId":"e62b573f2a5e6906","active":0,"ablilty":0,"encrypt":true,"productKey":"a3g9fxaujjgtei27","version":"3.3"}'
10.42.42.28 b'{"ip":"10.42.42.28","gwId":"e62b573f2a5e6906","active":0,"ablilty":0,"encrypt":true,"productKey":"a3g9fxaujjgtei27","version":"3.3"}'
10.42.42.28 b'{"ip":"10.42.42.28","gwId":"e62b573f2a5e6906","active":0,"ablilty":0,"encrypt":true,"productKey":"a3g9fxaujjgtei27","version":"3.3"}'
10.42.42.28 b'{"ip":"10.42.42.28","gwId":"e62b573f2a5e6906","active":0,"ablilty":0,"encrypt":true,"productKey":"a3g9fxaujjgtei27","version":"3.3"}'
10.42.42.28 b'{"ip":"10.42.42.28","gwId":"e62b573f2a5e6906","active":0,"ablilty":0,"encrypt":true,"productKey":"a3g9fxaujjgtei27","version":"3.3"}'
^C
smarthack-web.log
Listening on 10.42.42.1:80
^CReceived SIGINT, exiting...
smarthack-wifi.log
Configuring AP interface...
RTNETLINK answers: File exists
RTNETLINK answers: File exists
Starting DNSMASQ server...
Starting AP on wlan0...
Configuration file: /dev/stdin
wlan0: Could not connect to kernel driver
Using interface wlan0 with hwaddr b8:00:00:00:00:00 and ssid "vtrust-flash"
wlan0: interface state UNINITIALIZED->ENABLED
wlan0: AP-ENABLED
wlan0: AP-STA-CONNECTED 28:6d:cd:16:48:91
wlan0: AP-STA-CONNECTED 60:00:00:00:00:00
wlan0: AP-STA-DISCONNECTED 28:6d:cd:16:48:91
wlan0: AP-STA-CONNECTED 28:6d:cd:16:48:91
wlan0: AP-STA-DISCONNECTED 28:6d:cd:16:48:91
wlan0: AP-STA-CONNECTED 28:6d:cd:16:48:91
wlan0: interface state ENABLED->DISABLED
wlan0: AP-STA-DISCONNECTED 28:6d:cd:16:48:91
wlan0: AP-STA-DISCONNECTED 60:00:00:00:00:00
wlan0: AP-DISABLED
nl80211: deinit ifname=wlan0 disabled_11b_rates=0
AP closed
Stopping DNSMASQ server...
@deiger, this is a different issue. tuya-convert only supports ESP82xx devices and yours is unfortunately a WinnerMicro based device.
I noticed the typo ablilty in your discovery packet, which tells me its not an ESP. Then I checked the MAC address and saw the manufacturer is Winner.
I'm running into this same issue with two of the four devices I flashed in the last two days.
https://templates.blakadder.com/kmc-4.html - Successful
https://templates.blakadder.com/euri_lighting_LIS-A1001.html - Successful
https://templates.blakadder.com/lohas-ZN036.html - Both did not appear with intermediate firmware
None of these were connected to the tuya app before attempting flash.
I'm on a raspberry pi 3 B+ running buster (killing wpa_supplicant before flashing)
smarthack-mqtt.log
smarthack-psk.log
smarthack-udp.log
smarthack-web.log
smarthack-wifi.log
(the ea:fc:74... mac in the wifi log is the randomized mac of my phone)
dig a3.tuyaus.com points to 10.42.42.1
I also did a tcpdump of one attempt
capture.pcap.txt
I can get the LOHAS spotlights into a "flashing twice per second" mode and a "flashing once every 3 seconds" mode. The slow flash appears to be AP mode, which does nothing with tuya-convert.
The fast flash appears to work for a moment, as the device shows up in the wifi logs. However, the flashing stops when the smart config packets are sent, followed by tuya-convert retrying and eventually timing out.
I just got it working after checking out the development branch and fixing a bug!
Bug: https://github.com/ct-Open-Source/tuya-convert/blob/development/scripts/psk-frontend.py#L66 needs to be hint=self.hint.decode() instead of hint=self.hint
Both spotlights are now flashed!
Had the same issue. Device was connected to Tuya app first.
I've pulled a clean newest dev branch, installed all the prereqs and added the PR #496 fix for psk-frontend.py but still no success in flashing. It just trying to resend smartpackets
all the logs are quiet:
smarthack-udp.log
smarthack-web.log
smarthack-wifi.log
smarthack-mqtt.log
smarthack-psk.log
tuya-discovery:
tuya.log
tcpdump:
capture.zip
Edit:
After disassembly the used module is WR3E with RTL8710BN so that explains everything
Im having the same problem with Wipro 16a smart plug https://www.amazon.in/gp/product/B07XPQYVLG/ref=ppx_yo_dt_b_asin_title_o08_s00?ie=UTF8&psc=1
I tried using raspberry pi zero USB serial gadget mode
these are my logs
smarthack-mqtt.log
smarthack-web.log
smarthack-udp.log
smarthack-psk.log
smarthack-wifi.log
what am i doing wrong?
I have same issue with some smart switch modules that before were ESP and now it seems that they have moved to a Beken Corp chip. IThe previous versions were completely white, and these have the connections in green, so I don't know if all the ones like this are not ESP, but you should be aware.
Mine were from MOES Home
I got the issues listed in this thread
I am attaching the log files I got when tried to tuya-convert it.
smarthack-wifi.log
smarthack-web.log
smarthack-udp.log
smarthack-psk.log
smarthack-mqtt.log
@photonforge I did not find an ESP82xx based device connecting in your web logs unfortunately, suggesting it might not be possible to use ESP third party firmware on that device.
@kueblc
@photonforge I did not find an ESP82xx based device connecting in your web logs unfortunately, suggesting it might not be possible to use ESP third party firmware on that device.
oh damn! could it be because ive done the flashing process wrong or is it definitely that the board is unsupported? Because, some other products from the same brand (like led bulbs) have worked with tuya convert. And the plug connected to the smartlife app without any issues..
If the device connected (slowed or stopped blinking), it is definitely not supported. Seems like you would have experienced problems flashing other devices if you had the process wrong.
It is common for the same brand or even same model to start switching to another module, and yes they will still work with SmartLife if they are Tuya based, whether or not they use an ESP module.
tried on kali linux and raspbian buster...
sometimes the program is taking a lot of time without succes. Logs are complete, just stopped the program after no succes for 20 times and removing the logs to have “clean” logs. Devices are lsc door sensor and pir. Never connected to the app / brand new devices.
smarthack-mqtt.log
smarthack-psk.log
smarthack-udp.log
smarthack-web.log
smarthack-wifi.log
@DenDeze see #135
Never mind, soldered and flashed true GPIO pins. the device tuya MCU powers the esp only when the door contact is made / broken.
@kueblc
@photonforge I did not find an ESP82xx based device connecting in your web logs unfortunately, suggesting it might not be possible to use ESP third party firmware on that device.
oh damn! could it be because ive done the flashing process wrong or is it definitely that the board is unsupported? Because, some other products from the same brand (like led bulbs) have worked with tuya convert. And the plug connected to the smartlife app without any issues..
Hi from a brother from the same neck of woods. Do remember to add such devices on the Blackadder repo under unsupported.
I almost bought a few of those Wipros! Thanks!
I think i have the same problem with a "Magic Home-Smart Home" bulbs (sorry for my bad english)
I update de log
tuya-convert v2.4.3
Checking for network interface wlan0... Found.
Checking UDP port 53... Available.
Checking UDP port 67... Available.
Checking TCP port 80... Available.
Checking TCP port 443... Available.
Checking UDP port 6666... Available.
Checking UDP port 6667... Available.
Checking TCP port 1883... Available.
Checking TCP port 8886... Available.
sudo: ufw: command not found
Starting AP in a screen...
Starting web server in a screen
Starting Mosquitto in a screen
Starting PSK frontend in a screen
Starting Tuya Discovery in a screen
[...]
Starting smart config pairing procedure
Waiting for the device to install the intermediate firmware
Put device in EZ config mode (blinking fast)
Sending SSID vtrust-flash
Sending wifiPassword
Sending token 00000000
Sending secret 0101
................
SmartConfig complete.
Resending SmartConfig Packets
.................
SmartConfig complete.
Resending SmartConfig Packets
.......................
Device did not appear with the intermediate firmware
Check the *.log files in the scripts folder
Do you want to try flashing another device? [y/N] n
I upload the logs
Thanks
smarthack-mqtt.log
smarthack-psk.log
smarthack-udp.log
smarthack-web.log
smarthack-wifi.log
tuya-convert.log
EDIT: I'm sorry I think they are RDA 5981AM chip
PID:000000000000000000000000c7600000
DID:00000000000000000000c8f7428bf538
Access to the cloud:7b35777b7cd2da75bf75ba4a99371___
MAC:c8:f7:42:8b:f5:38
Firmware:Load failed. Tap to retry Device IP:null
I also get the message "device did not appear with the intermediate firmware" when I try to flash a smart door sensor or a smart movement sensor from LSC. Now I am new to this matter. So I hope someone can tell me why I can't flash them. Maybe I do something wrong or there is already a newer version of software on it so it is no longer possible to flash them. I've included the log files.
smarthack-mqtt.log
smarthack-psk.log
smarthack-udp.log
smarthack-web.log
smarthack-wifi.log
@ColinDexter
I am afraid that the devices appear to be non-esp based and as succ, will not be possible to flash them with Tuya convert.
If you open-up one of the devices, perhaps you will see a chip from another brand.
Hm, that's too bad. The enclosed photos are from the inside


Hey Colin, Good news - these, in-fact, are ESP based chips! Great!
You should be okay to solder the serial wires and flash them in a jiffy 😃
Lemme know if you need help with it....plenty of examples available on the web.
I am surprised that you got the intermediate error....hmmmm.
Anyway, you are good.
As an example... https://github.com/arendst/Tasmota/wiki/TYWE3S
Thank you for your answer. Just one more question. Which bin should I use. There's so many. Can I just use the tasmota.bin I have on the raspberry?
Since you are will be doing a serial flash, size of the bin will not be an issue. Please use the full version - tasmota.bin
Get it from the tasmota github release page. 8.2 version.
I suggest you also read the tasmota documentation...the getting started part for sure. If you get stuck, see us over at the discord server and someone will help you for sure.
https://discord.gg/6UVnRX
Thanks for the support. I think it's gonna work now for me :-)
@ColinDexter @amitseth13 door and motion sensors have a secondary MCU that powers down the ESP, unfortunately making it tricky to stay online long enough to flash. This also presents a challenge once you've installed a third party firmware, since it does not stay powered. See #135
@kueblc Thanks for the nudge in the right direction - at times, case-in-point, zeal tends to overtakes sound experience. @ColinDexter May not be terrible to stay with the OEM firmware. But if you are like me - why go gentle into the good night 😉
Ah, I get it. It's working now. Just setting it up is a little tricky :-) But it works!
Thank you all
Hi, another case of this problem. It is a E27 adapter, and works with TUYA. (I suppossed)
I HAVE NEVER connected it to tuya or smart life app, just in case.
But I am getting this error:
'''
SmartConfig complete.
Resending SmartConfig Packets
..........
Device did not appear with the intermediate firmware
'''
I have tried with an old version (Kali live USB persistent) with which I tasmotized two SP22, and also downloading again from github and installing prerequisites in the same Kali live usb but without persistence.
Here you have the log files.
What could I do next? Thanks.
smarthack-mqtt.log
smarthack-psk.log
smarthack-udp.log
smarthack-web.log
smarthack-wifi.log
And logs from "old version":
smarthack-psk.log
smarthack-udp.log
smarthack-web.log
smarthack-wifi.log
smarthack-mqtt.log
Thanks a lot for your help.
@ortegafernando see #483
Hi, I've converted two 2018 bought SP22's last week without problems.
A third 2019 bought one also seemed to be going fine untill it was 'bricked' and didn't respond to anything anymore. I had to open that one up and solder it (first time soldering!) and succesfully flashed it :



Now I had a go with 2 other 2019 bought SP22's and they don't do much, they only stop blinking and then nothing, both of them.
Logfiles :
smarthack-mqtt.log
smarthack-psk.log
smarthack-udp.log
smarthack-web.log
smarthack-wifi.log
Nevermind, I see now I do have the same as 483 just with another psk key. I'll see if I can take one apart these days and provide some logs.
So I opened them up today, it's very easy actually, if you put a cloth around and carfully put between a bench vice the glue will burst en case pops open without a single mark/scratch :

Anyway, I think I have another problem, if I'm not mistaken then these have Realtek chips and are not usable with any custom software ?
Not much left except putting them together I suppose ?


@PoloB12 did you try shorting GPIO0? It might be possible to still flash Tasmota.
As I understood there is no support for Realtek chipsets by either Tasmota or Espurna? Could be I missed something, do you have a link maybe?
@PoloB12 you are correct, Tasmota and Espurna only support the ESP82xx. I am not aware of any mature custom firmware for these Realtek chips.
Gents, don’t waste your time with the Realtek chips unless, of course, you wish to create a port of the firmware for them.
I suggest doing an organ transplant (read replace RT with ESP). It’s a fun project and most gratifying...having done a few, I speak from experience :-)
https://community.home-assistant.io/t/unkown-tuya-chip/153591/22
@timaseth that looks like a fun project indeed but I'm not sure if I'm up to it, maybe in the future !