AP config

[kueblc]

This allows a Tuya device to pair with the tuya-convert AP without using EZ config
Device must first be in AP config mode "slow blink" vs the EZ config "fast blink"
Once connected to the IoT device's AP, running ./apconfig.py will bind the device to tuya-convert
./start_flash.sh can then be executed as normal, skipping the pairing process

[dachshund-digital]

Cool, looking forward to it!

[AdriaanDeVos]

Using this script helped me from:
No ESP82xx based devices connected according to your wifi log.
to
An ESP82xx based device connected according to your wifi log.
👍

[tauno]

Attempting to test this out but unclear on the steps. Is this correct?

1. Put device in AP config mode (slow blink)
2. On the tuya-convert machine, connect to the device AP
3. Run apconfig.py
4. Run start_flash.py

Do you need to modify start_flash to skip the pairing step?

[darkmattercoder]

@kueblc I am a bit lost, too. The apconfig gives me some long number Sending 000055aa00000000000000010000003e7b2273736964223a227674727573742d666c617368222c22706173737764223a22222c22746f6b656e223a223030303030303030227d726cfc610000aa55

and nothing else. The start_flash.sh script then seems to still want to start the ap and cannot find any devices

[jonasbark]

Thank you @kueblc - it works very well!

[jonasbark]

if anyone stumbles upon this: the token needs to be the combination of the region (e.g. EU) + token + secret, as described in https://github.com/ct-Open-Source/tuya-convert/blob/master/scripts/smartconfig/smartconfig.py#L47

[Hervshahn]

Hello @kueblc and all,

I ran into the same problem like @darkmattercoder.

Do I have to modify the Defaults section of the script apconfig.py, like replacing SSID "vtrust-flash" with the SSID of my Gosund device?

Also would I have to change the BIND ADDRESS and what should be entered here?

[MacSass]

Yes - this sounds very interesting and might help to solve my issue, but would really be great if @kueblc could provide some more info / backtround on the steps required, because I also do not understand the full procedure ...

• Do we need to make changes to the existing scripts?
• Do we need to make modifications to your additional script?
• What about the remark about the needed token? Is this required? Where?
• How can your script bind the device to tuya-convert before starting start_flash.py, as the vtrust-flash AP is not running yet?

I´m a bit lost and your help would really be appreciated as I´m hopeful to be able to flash my last devices with that method finally ... thanks!

[Hervshahn]

Looks like unfortunately the developer is not actively monitoring this space anymore :-(

[kueblc]

No additional script or config modifications should be necessary. @tauno has the correct procedure.

1. Put device in AP config mode (slow blink)
2. On the tuya-convert machine, connect to the device AP
3. Run apconfig.py
4. Run start_flash.py

At the point where start_flash asks you to put the device into EZ config mode and press enter, you can just press enter, as the device has already been configured with AP config.

The purpose of the apconfig.py script is to configure the IoT device over it's own AP. After running the script, the device will store the network config and stop broadcasting it's own network. It will then repeatedly attempt to connect to vtrust-flash. At this point, running the start_flash script as normal will create the vtrust-flash network and allow you to proceed with flashing.

Please let me know if there is anything else I can clarify.

[kueblc]

I should also note that connecting a third device is not necessary, since that is only to facilitate EZ config.

[MacSass]

thanks a lot @kueblc for the clarification.
I will try that today or tomorrow and report back. That would be a nice enhancement to make everything more "robust".

[MacSass]

Wow @kueblc !!!
I had 5 plugs of which I could only flash two with default tuya-convert, three obviously identical ones always had the issue that they would not connect back to the vtrust-flash AP.
I tried all the workarounds and issues I could find (different name of network service, etc.) - nothing worked. In the end I even broke one open and serial flashed it ...

Yesterday I tried apconfig.py and "bingo" - it worked right away for my remaining two devices (the second on first run of start_flash showed a timout within 1s, re-running it worked perfectly).

For me this method of connecting "manually" and using apconfig.py seems much more robust than the "automatic" way and should be integrated into tuya-convert.

Thanks @kueblc for making your work available to us!

[Hervshahn]

Thanks a lot, this is great feedback! I had flashed my two devices meanwhile using a USB-TTL adapter but will use apconfig.py for the next couple of devices as well

[kueblc]

Thanks for reporting back @MacSass, I'm very happy to hear it worked well for you

[chaudhryfaisal]

hi everyone, I ordered following from Amazon and I am not able to get it to flash.

1. Press and hold the power button, light start to blink
2. I don't see any AP to connect to so assume plug is not creating any AP so not able to run appconfig.py
3. ran ./start_flash.sh but with no success

I wouldn't mind opening them to flash but it seems like there is no way way to open this either

Any suggestions ?

[MacSass]

Make sure you have your device on „slow blinking“, only then you get an AP to show …

I need to hold the button for my device, then it goes to fast blink, then I need to hold button again until it changes to slow blinking…

[chaudhryfaisal]

here is videos of what it does https://www.veed.io/view/5877f0b6-85c2-4064-86ab-45a97e5bcbc0

as soon I let the button go it reboots and starts blinking fast. I never see additional AP created
I only have vtrust-flash which is created by running ./start_flash.sh

[MacSass]

Hmm, as per https://support.tuya.com/en/help/_detail/K9hut3w10nby8 doing a second "hold button" when device is blinking fast should take you to the "led blinging slow" = AP mode.
That worked for me - I don´t have any unflashed devices anymore right now - so I´m afraid I can´t help.
When I had gotten my devices in slow blink AP mode, I could see the wifi on my mobile (I think the name was including something like "smart device" or so ...

[montyx99]

When I run the apconfig.py my gosound sp1 device is turning OFF. What can cause this issue? Thanks

[floxboy]

where can i get appconfig.py? I don't see it in tuya-convert folders

[kesselborn]

where can i get appconfig.py? I don't see it in tuya-convert folders

this pull request is not merged yet, you need to use the version from https://github.com/kueblc/tuya-convert/tree/ap-config

[kueblc]

When I run the apconfig.py my gosound sp1 device is turning OFF. What can cause this issue? Thanks

@montyx99 it will appear to "turn off" once it has successfully paired.

[preese]

Might this thread still be alive, even after the commit?

I've tried this approach with several TopGreener TGWF115PQM plugs. No luck. (Yes the dreaded 4 pack from Amazon)

My experience is that I get the plug in AP mode and the host gets a 192.168.175.100/24 wlan address, from the plug.
I run the apconfig.py script and the long number shows on the screen but no change to the wlan IP, yet.
Next, I run start_flash.sh, and shortly hit Enter, it gives out a 10.42.42.1/24 address for the wlan now.
But the dance starts and continues with the Resending refrain.
Eventually, I'm left with a wlan ip in the ever popular space of 169.254.148.1/16.

Seems the formerly solid tuya-convert wins of the TopGreener plugs no longer work for us hobbyists even after the VERY helpful work on the general issue by Kuebic!

[kueblc]

@preese could you share your logs? I'm curious if the AP config succeeded and then failed at the provision stage.

[preese]

Here is the log. I'm using a RPI4 with fresh build from RPI Imager, 64bit and then tuya-convert+apconfig.py. This is a fresh trial today, with the same results. I've log before this point in time but thought this covers the issue. Let me know if earlier logs would help.

Failed-apconfig-tuyaconvert-TopGreenerplug.txt

[kueblc]

@preese have you retained the logs from the tuya-convert directory? smarthack-web.log may be of particular interest.

Recent reports have suggested that newer releases of RPi OS are not working as intended. You may want to try an older release (Buster). I have not been able to verify this myself.

[preese]

Not much progress. I did go back to a RPI OS based on Buster, and ran through all the steps a few times with similar results as before.

A few tech points to be clear on.

1. I have the RPI on an enet connection and am using its WiFi for these tests while still logged in via enet.
2. When start-flash starts up, it asks to terminate dnsmasq service, I assume should be answered with 'Y'
3. Similarly, it wants to stop mosquitto, again I assume 'y'.
4. No ufw found
5. I never manually connect my phone to the vtrust-flash SSID.
6. I turned BlueTooth off to try to minimize the logs.

In general is it better to run is on separate hardware, RPI, or use the more standard Docker version with small tweaks to config.txt file?

Thanks for you persistence in looking into the issue! Sent you some Coffee!

Large log file and concatenated smarthack-xx files below:
RPI-Buster-TuyaCon-logs-fail.txt

all-smarthack-logs.txt

[kueblc]

Hi @preese, thank you very much for the coffee!

Your process looks absolutely fine to me. Connecting over ethernet is the way to go in your setup. We stop dnsmasq and mosquitto to free up the ports for our own configuration. You will not need to connect your phone if using AP config. Keeping other wireless radios off for clean logs is a great idea.

As far as whether to use your own hardware, a RPi, or Docker is mostly a matter of preference. I personally run this directly on a standard laptop running an Ubuntu based distro. I don't have an RPi available and the Docker version was a community addition.

From your logs it seems the process is failing between the AP config and the server provisioning. I do not see any attempts from the device to connect to your AP or the web server.

After you put the device into slow blink mode, you were able to connect to it's AP, so we can affirm that it does permit AP config. Does the device "click" or make any other observable changes when the AP config script is run?

It might be that this device is not an ESP82xx (we can check the MAC address). Or it could be that the firmware has been patched to prohibit aspects related to tuya-convert, like it's SSID or password (we could try tweaking these).

EDIT: Unfortunately it looks like it may be likely that this device is not an ESP82xx. You may have gotten lucky with an old batch, so it is still worth checking the MAC address you get when connecting to the device or opening the device to inspect the chipset.

[preese]

@kueblc I think you've hit the nail on the head, or is it put the last nail in the coffin! One MACADDR from the new set of four is 38:1f:8d:9f:4a:02. In my google searches this doesn't seem to be in any of the EXP82xxx MAC ranges. Plus your link to the blakaddr page suggests similar info about these TopGreener plugs. Let's call this one done.

I do appreciate your work on the project and in this particular question specifically.

In broader searching, I've run across this site: https://cloudfree.shop/ They offer several openHAB/HomeAssistant type device options pre-loaded with Tasmota. Including their own 15A plug, as well as Sonoff's S31 plug. Their prices are slightly higher then Amazon and no free shipping. However, just being able to directly use the device rather than poke around for a number of hours seems to offset the higher price. Shipping can be first class USPS, which comes pretty fast and was modest in cost, $5 for four plugs.

[kueblc]

Bummer, sorry to hear these plugs can't be cut off the cloud! Glad to help diagnose anyway and I appreciate your support and kind words.

A while back I had considered trying to set up my own shop of cloudless IoT back when that was unheard of, glad to see there are more options popping up. Like you say, it might be worth a marginal cost for the convenience and security of getting exactly what you're looking for. I might still consider it if there's demand / room for competition. Wouldn't want there to be any (appearance of) conflict of interest with this project though!