Tuya-convert: New Tasmota build intended for distribution with tuya-convert

[blakadder]

Greetings!

I bring you a feature request/demand.

Tasmota devs have built a new special binary intended for first flash with tuya-convert. It is available on http://thehackbox.org/tasmota/sonoff-tuya.bin.

After a successful flash we recommend using command reset 5 to completely erase the flash completely and remove any remnants of the factory firmware. Afterwards apply a corresponding template and enjoy.

tl:dr Could you add this binary instead of the sonoff-basic.bin one in tuya-convert?

[pfeerick]

Nice! :) I see the Sonoff-Tasmota documentation has been updated to recommend to this file by default, so that's good also.

Any idea why the reset 5 is necessary if this is a tailored build? Was it not possible to have that done automatically somehow? Edit: meh... I half suspect it is possible, via either one or perhaps two flags, but it would still probably end up resetting someones "perfectly handcrafted config" and resulting on them complaining about it, so not worth the hassle. Better to just document the recommendation do the reset 5 and ensure flash memory is cleared and settings are all at their defaults.

[Jason2866]

@pfeerick Better you look in Tasmota wiki before writting suggestions
https://github.com/arendst/Sonoff-Tasmota/wiki/Tuya-OTA

[pfeerick]

@pfeerick Better you look in Tasmota wiki before writting suggestions

?? This was the documentation I was referring to in my comment, which recommends that the sonoff-tuya.bin be used instead of the version distributed in this repo. It also makes the recommendation to run the reset 5 command after loading, which I still think _could_ be made redundant - possibly via the bootcount variable/counter.

Anyway, thanks for the link... ;)

[Jason2866]

@pfeerick And we know reset 5 is needed because Tuya Convert does not erase flash.
This is a big problem from Tuya Convert NOT erasing unused flash after loading 3rd party firmware.
Every 3rd party firmware runs in a dirty environment!
To be clear Tasmota was not designed to be used with Tuya Convert.
Tuya Convert uses Tasmota so Tuya Convert has to take care for the needed requirements...

[blakadder]

@pfeerick Better you look in Tasmota wiki before writting suggestions

?? This was the documentation I was referring to in my comment, which recommends that the sonoff-tuya.bin be used instead of the version distributed in this repo. It also makes the recommendation to run the reset 5 command after loading, which I still think _could_ be made redundant - possibly via the bootcount variable/counter.

Anyway, thanks for the link... ;)

How do you intend to make a command that erases the entire flash after tuya-convert to ensure no remnants of the original firmare interferes with the new firmware redundant?
The fact that it solves issues in practice and has been repeatedly confirmed is why it is explicitly mentioned in the documentation and this OP.

Only when tuya-convert manages to erase entire flash before flashing new firmware (tasmota or any other) will be the time reset 5 is not needed.

[Jason2866]

@pfeerick The need of reset 5can be seen here:
https://github.com/ct-Open-Source/tuya-convert/issues/328#issuecomment-545835008

[kueblc]

Happy to accept a PR, not happy to accept a "demand"...

[Tollbringer]

I think this is a great addition to the support of Tuya-Convert since MANY users including myself choose to flash this. The restrictions on the sonoff-basic.bin file are cleary not the best choice; for my use case- and perhaps many others.. However - it was included for our benefit and ease-of-use.

DigiblurDIY addressed one key issue, based on forever repetitive issues of people 'bricking' their unit due to incorrect wifi passwords and what I call the fat finger/excited effect.

It would be great to see Tuya-Convert include the newly formed sonoff-tuya.bin file- I was aware this was a request and I am glad to see it included. I certainly don't see the need for a demand, public or otherwise.

This is such a great community and I am very happy to participate in it. Thanks to Colin, M4DMartig4n and all others who have contributed to the success of Tuya-Convert.

And of course - thanks for Theo Arends and Team for the quality firmware provided!

Just my $ 0.02 worth (Canadian, so worthless in the USA of A !! -lol)

[-=SrZ=-]

[andrethomas]

Just to note not to get too fixed on the naming convention - I plan to change it to sonoff-wifiman.bin since the binary serves two simple purposes.

1. Disable all the drivers for all types of things one would not expect in a tuya device which has the result that it decreases the binary size making it possible to flash OTA without using an intermediate as would be required for the standard sonoff.bin binary.

2. Change the default behaviour of the wifi configuration so that if the device is reset to factory defaults it would automatically go into wifi manager mode instead of just continuously trying to connect whatever (possibly incorrect) wifi settings were found in the settings structure.

As these are introductory changes made to try and assist people who are using tuya devices there are no immediate plans to make a release available for this but the scripts are already in place to perform the development binary builds.

I understand the frustrations associated with trying to co-ordinate changes on different projects each sharing their own ideas and have their own github pages and such - That being said its important to remember that everyone is part of the same open-source community and although emotions do come into play at times one needs to take a principled approach to what will yield the best outcome for the users of the open-source projects - without the users we'd all still be coding our own little private pieces of firmware in our basements (wish I had one of those) :)

[kueblc]

Happy to coordinate, respectfully of course. We're all volunteers here :)

That said, thank you for your added effort to support tuya-convert users. It goes above and beyond the call of duty and it shows.

[pfeerick]

How do you intend to make a command that erases the entire flash after tuya-convert to ensure no remnants of the original firmare interferes with the new firmware redundant?

Perhaps you should be asking why you're fixating on it being related to tuya-convert, and not done across the board as part of the first run of tasmota if the data structure hasn't been initialised yet - as I'm sure tuya-convert isn't the only instance in which this can happen... but just the most relevant given the repo this issue is on!

i.e. is the device bootcount preserved across firmware updates? if so... bootCount < 1 == reset 5, or some other mechanism that can detect that first flash of tasmota onto a new device, and hence initialise all the data structures correctly.

I agree that if tuya-convert was able to erase the entire flash (except for it's loader) that this would hide the issue, not necessarily _fix_ the issue - fixing it in my mind rests in the project that doesn't handle initialisation of data structures and defaults properly... regardless of which one it is.

[andrethomas]

bootCount < 1 == reset 5

This would of course cause an infinite boot loop since the location where bootCount would be stored will be erased, on first boot be reset to defaults because it will fail CRC... rinse and repeat.

I believe the part that had an impact is erasing the portion of the flash where the SDK stores its settings.

I don't believe it is any other portion of the spi flash or even the portion where tasmota will end up storing its settings.

To prevent this issue on traditional serial flashable devices the flashing process is decribed in a way that the user would perform a full erase of the spi flash prior to flashing tasmota for the first time.

Since in this case that process is replaced by tuya-convert it would make sense that tuya-convert prepares the spi flash in a similar way.

[pfeerick]

@andrethomas Thanks for the quick and through response... not knowing how the bootcount was handled was part of why I was asking was it possible for tasmota to handle it (SDK being the other main issue). When I was looking at the commands I saw that there was reset 99 to explicitly reset the bootcount, so was unsure as to whether it was caught in the reset 5 erase ;)

That makes perfect sense now.... i.e. the tuya-convert update process needs to write it's own bootloader, and then erase the remainder of the flash... since it obviously can't erase itself. Thus leaving a clean slate for whatever else follows.

[blakadder]

How do you intend to make a command that erases the entire flash after tuya-convert to ensure no remnants of the original firmare interferes with the new firmware redundant?

Perhaps you should be asking why you're fixating on it being related to tuya-convert, and not done across the board as part of the first run of tasmota if the data structure hasn't been initialised yet - as I'm sure tuya-convert isn't the _only_ instance in which this can happen... but just the most relevant given the repo this issue is on!

First of all it is the tuya-convert repo. Second 99% of Tasmota flash on non tuya-converted devices is done over serial where you always erase the entire flash before flashing which nullifies the requirement of using reset 5

I agree that if tuya-convert was able to erase the entire flash (except for it's loader) that this would hide the issue, not necessarily _fix_ the issue - fixing it in my mind rests in the project that doesn't handle initialisation of data structures and defaults properly... regardless of which one it is.

Luckily it is indeed able to erase the critical parts of flash.