Do you have any firewalls? Check for ufw and firewalld

I never had any firewall issue on this pc, so I'd say no.

#> sudo ufw status
WARN: Duplicate profile 'Apache', using last found
WARN: Duplicate profile 'Apache Secure', using last found
WARN: Duplicate profile 'Apache Full', using last found
Status: inactive

#> firewalld

Command 'firewalld' not found, but can be installed with:

sudo apt install firewalld

I was looking at logfiles by other users... mine have mostly nothing in the web part. It's just the phone/tablet that visits the sign in page of the wifi. So strange...

Yep, if I netcat from my phone to 10.42.42.1, the phone IP address pops up in smarthack-udp.log, so I'd say this part works.

The other bulb does exactly the same. I was afraid that having used the first one for one day with the original app may have updated its firmware in the background.

I think I found the problem. start_flash.sh assumes that the device is at 10.42.42.42 (it's hardcoded in the script) but mine acquires its address via DHCP, so between 10.42.42.10 and 10.42.42.40. In fact, it becomes 10.42.42.21 (see attached arp table).

I'll try to change the destination from 10.42.42.42 to 10.42.42.21 and I'll report back if it works.

tuya-nooie.pcap.gz

Nope... that part comes later... so it's a multicast problem? The device doesn't subscribe to 226.120.89.84?

start_flash.sh assumes that the device is at 10.42.42.42 (it's hardcoded in the script)

This is intentional and should not be changed, as you have likely discovered. The static IP 10.42.42.42 is only taken by the device once it is running our intermediate firmware, this is the signal it uses to notify the script of success and to proceed.

The device doesn't subscribe to 226.120.89.84?

Multicast is used by the smartconfig process to transmit AP credentials. No subscription is needed. The device enters sniffer mode and extracts information encoded in the IP addresses of the multicast packets. This is how it can transmit information before it is connected to the network.

There is nothing wrong with the smartconfig process as we can see the device in your wifi log. The problem is that there are no requests from the device in your psk log.

Making a comparison between a successful pairing via app:

and an unsuccessful pairing via tuya-convert:

I'd say I have some DNS problem...

I've already tried the pairing on a fresh raspberry, but the result is the same. I've also found a region = "US" in main.py in smartconfig directory, tomorrow I'll try to set it to EU.

I'd say I have some DNS problem...

This was my original thought, but now it is looking like the device is trying to access an unusual port (4433). We don't have anything listening on this port which would explain why it isn't getting a response, and thus why the process is failing. This is what we must investigate.

It looks like it is expecting MQTT. Perhaps as a quick test you can edit psk-frontend.py so that MQTTS is answered on 4433 instead of 8886.

I've also found a region = "US" in main.py in smartconfig directory, tomorrow I'll try to set it to EU.

This shouldn't make a difference. Even if it could, like I said earlier, there is no issue with smartconfig since we can see the device connecting. This is the only role of smartconfig and the third connected device.

Ah, somehow I did not notice this before, but your device does not use an ESP82xx and therefore is not supported by tuya-convert, Tasmota, ESPHome, etc. This is apparent by the device's MAC address using an OUI lookup tool. Supported devices will have an OUI of Espressif Inc.

Better luck with your next device!

Oh, that's really bad news. Well, at least I'm done suffering :)