After flashing some devices succesfully I seem to have bricked my QS-Wifi-D02-Triac-2C (Tuya-based) dimmer. I would like to understand what I did wrong and if it is possible to debrick it.
Here is what
I did:
-flashed the
device through tuya-convert from stock to tasmota-lite 9.2.0
-applied a
template I found on the internet for my device https://gist.github.com/thxthx0/ce7f72ea75ab82be2704c9536ea77bf7,
and entered SetOption68 1 in the
console (as prescribed by that webpage)
This didn’t really work (pressing on/off or moving the sliders did not do anything), so I assumed the fact that I didn’t have the appropriate script installed caused this. So I had to compile my own firmware to enable the scripting part.
-logged into
gitpod, used the master release link https://gitpod.io#https://github.com/arendst/Tasmota/tree/master
-appended
#ifndef USE_SCRIPT
#define USE_SCRIPT // adds about 17k
flash size, variable ram size
#endif
#ifdef USE_RULES
#undef USE_RULES
#endif
to the existing /tasmota/user_config_override.h file, and saved it
-renamed platformio_override_sample.ini
to platformio_override.ini
-ran platformio
run -e tasmota
-downloaded
the generated tasmota.bin.gz
-downloaded
the latest tasmota-minimal.bin and flashed that
-after
restart flashed tasmota.bin.gz ; it ended with something green on the screen
and a message that all went ok, device was going to restart
… and that was the last thing that was every heard from the device.
Now what went wrong? Should I have customized the user_config_override.h settings to my own wifi ssid/password settings? Was I wrong in assuming that leaving all the settings at default would generate the “standard” tasmota.bin file? Should I have gunzipped the tasmota.bin.gz first before uploading it to the device?
And also: was I right in the assumption that the script not being there could cause the template not to work, or is that completely independent of that? When I read the script it seems to handle the external push-button functionality, perhaps not necessary for the tasmota-toggle to function?
Is it possible the MAC address has changed? An nmap scan did not show any new Expressif devices…..
Now, not
understanding what went wrong, I tried some debricking scenario’s:
-push the
external push-button 6 times to get it in “standard firmware settings”
-unplug/replug
the device 6 times, leaving it plugged the 7th time, to get it in “standard
firmware settings”
I’m not sure what to expect, should the device appear online with the old wifi settings or were they cleared by the tasmota-minimal flash? Or should the tasmota-XXX AP appear in my wifi -list?
Not surprising this did not help anything, because as far as I know the firmware that is in there is already in its most virgin state (newly flashed, that is).
I hope you guys can help me out understanding what happened and what went wrong, so I can prevent making the same error again. And if someone has a good debricking idea, that would be great too, my last resort would be trying to find the rx/tx/vcc/gnd connections and do a serial reflash…
THANK YOU!
--
You received this message because you are subscribed to the Google Groups "TasmotaUsers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonoffusers...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/sonoffusers/1de98f6f-3606-415c-9650-9039e3b0366dn%40googlegroups.com.
It’s a setting in the flash tool. If you have used OTA only it shouldn’t be a problem.
The surest wat to get to AP mode is the fast power cycle method – power off for at least 30 seconds and quickly switch on and off for 6 times then switch on for a seventh time.
To view this discussion on the web, visit https://groups.google.com/d/msgid/sonoffusers/9d83e8d4-9c9b-45c1-ba06-078d7eab66ean%40googlegroups.com.
I think I may have found the problem. If I do "file tasmota-minimal.bin" (downloaded from tasmota github) the output is:
tasmota-minimal.bin: DOS executable (COM)
If I do "file tasmota.bin.gz" (the file downloaded from the gidpod environment) the output is:
tasmota.bin.gz: gzip compressed data, original size modulo 2^32 446107.
Now if I gunzip this file, I get tasmota.bin:
tasmota.bin: gzip compressed data, was "tasmota.bin", last
modified: Sat Mar 6 14:34:23 2021, max compression, original size
modulo 2^32 622672
If I rename this file to test.bin.gz, and then gunzip it AGAIN, it says:
test.bin: DOS executable (COM)
It also has a more normal size of 622 kB, as to 446kB to the other version (gunzipped and double gunzipped).
Is it possible there is a problem in the GitPod environment that gunzips the tasmota.bin two times?
‘d raise it as an issue in the Tasmota GitHub.
Regards
Phil K
Sent from Mail for Windows 10
From: Hans Dingemans
Sent: 08 March 2021 07:44
To: Philip Knowles
Cc: TasmotaUsers
Subject: Re: bricked after self compile of tasmota.bin
Hi Phil, I must have been unclear, sorry for that.
For tuya-convert I used the tasmora.bin that is delivered with that software.
Then I reflashed with a standard release 9.3.1 tasmota-minimal.bin, and then reflashed with my (through Gitpod) self conpiled tasmora.bin.gz, which bricked my device. Even the recovery procedures dont work.
Now it turns out the tasmota.bin.gz file generated by Gitpod does not contain a valid tasmota.bin file, but it contains an already gzipped tasmota.bin file. So it has been gzippwd twice.
Could anyone point me to the person/group that is maintaining the Gitpod environment?
Op ma 8 mrt. 2021 07:36 schreef Philip Knowles <knowles...@gmail.com>:
Read the 3rd sentence of my reply and you will see why you bricked the device. Do NOT use minimal to convert a device.
Regards
Phil K
From: Hans Dingemans <jpldin...@gmail.com>
Sent: Monday, March 8, 2021 6:23:38 AM
To: Philip Knowles <knowles...@gmail.com>
Cc: TasmotaUsers <sonof...@googlegroups.com>
Subject: Re: bricked after self compile of tasmota.bin
Im saying that the self-compiled conpressed tasmora file should be called tasmota.bin.gz.gz since it is gzipped twice!
Op ma 8 mrt. 2021 06:48 schreef Philip Knowles <knowles...@gmail.com>:
Not sure what you are saying here. You are comparing tasmota-minimal with tasmota. Minimal is only used as an intermediate step when updating between versions (not to be used as a first flash).
Regards
Phil K
Technology just bites us sometimes
Sent from Mail for Windows 10
From: Hans Dingemans
Sent: 08 March 2021 14:58
To: TasmotaUsers
Subject: Re: bricked after self compile of tasmota.bin
Ok hardwired the device and unbricked it, reflashing it with the self-compiled uncompressed tasmoto.bin .
Tried to reproduce the problem on Gitpod, but was unsuccesfull at that. Can't imagine what I did to gzip it twice, I have the file to prove it but cannot reproduce the result so no use to open an issue at Github.
Thanks Phil for your help, consider this topic closed....
Op maandag 8 maart 2021 om 13:07:26 UTC+1 schreef knowles...@gmail.com:
‘d raise it as an issue in the Tasmota GitHub.
Regards
Phil K
Sent from Mail for Windows 10
From: Hans Dingemans
Sent: 08 March 2021 07:44
To: Philip Knowles
Cc: TasmotaUsers
Subject: Re: bricked after self compile of tasmota.bin
Hi Phil, I must have been unclear, sorry for that.
For tuya-convert I used the tasmora.bin that is delivered with that software.
Then I reflashed with a standard release 9.3.1 tasmota-minimal.bin, and then reflashed with my (through Gitpod) self conpiled tasmora.bin.gz, which bricked my device. Even the recovery procedures dont work.
Now it turns out the tasmota.bin.gz file generated by Gitpod does not contain a valid tasmota.bin file, but it contains an already gzipped tasmota.bin file. So it has been gzippwd twice.
Could anyone point me to the person/group that is maintaining the Gitpod environment?
Op ma 8 mrt. 2021 07:36 schreef Philip Knowles <knowles..@gmail.com>:
To view this discussion on the web, visit https://groups.google.com/d/msgid/sonoffusers/fd622e6c-fa87-45af-b61c-e3fb09889150n%40googlegroups.com.