HAA Installer 3.2.0
Closed this issue · 5 comments
Hi,
I have documented the problem in here: RavenSystem/esp-homekit-devices#1074
But I think it could also be useful to open an issue here. It seems that your method is installing the "HAA Installer 3.2.0" version, maybe because of a local copy on a repository, while the developer of the project has launched "HAA Installer 4.0.0".
Problem is that "HAA Installer 3.2.0" is no longer compatible with "HAA Main" versions since 2.5.2. They are currently at 2.5.7.
So if we update a Shelly with your procedure nowadays, it gets stuck into an update loop and never ends the process. I had to point my Shelly to an older version (2.5.0 in my case) to get it working again.
I copy and paste here my solution from the other GitHub:
Hi again! I solved the problem :) try this, at least it worked for me.
It seems that there are two different things into the HAA: Installer and Main.
In my case, I "flashed" the Shelly 1 vía OTA using a link from the internet, in my case the link was this one:
http://X.X.X.X/ota?url=http://dl.dasker.eu/firmware/mg2haa-Shelly1.zip
Problem with this procedure was that the mg2haa uses a local copy of the HAA Installer and it is still using the 3.2.0 version. The HAA Installer 3.2.0 version is only compatible with HAA Main versions until 2.5.2. Since 2.5.3 this Installer is no longer compatible and the installation will fail and enter into a loop.
Solution for me was the following:
1º) I set my Shelly1 into setup mode.
2º) I accessed the menu and under the "Custom Server for updates" I have set this link:
github.com/RavenSystem/haa/releases/download/2.5.0/
3º) Wait a bit and you will have version 2.5.0 installed of HAA Main, with HAA Installer 3.2.0.
4º) Access again to "Setup Mode" and select "Update all now (HAA OTA v3.2.0)"
5º) Wait a bit and you will end with your device updated to HAA Installer 4.0.0 and HAA Main 2.5.7.
This worked for me! I hope it helps to anyone who has the same problem.
BR!
I think the problem is that you copied the binary file in here:
https://github.com/yaourdt/mgos-to-tasmota/tree/master/binary
Instead of pointing to the original one, that gets updated from time to time. Maybe modifying this file for the updated haaboot.bin the problem will be solved.
Thanks!
Thanks for the heads up! I didn't know there was a newer version. I'll update both HAA and Tasmota binaries over the weekend, so mg2x will install more recent versions.
The advantage of using fixed versions from this repository over latest builds is that we can test them prior to release. Linking directly to the latest binary may eventually break things and leave users stranded if there are unforeseen changes.
Hey Mark! Thank you for your answer...
In reality this is what have happened now. I mean, I “bricked” two shelly devices because the HAA Installer 3.2.0 was installed and this version of the installer was not able to install the “latest” HAA Main 2.5.7.
Luckily the solution was easy, just access the device and point it to an older version. But in this case I think that linking to the original installer could have been better! I don’t know. You have a point in your argument and usually this should be the correct way to go, but in this case the current configuration is “bricking” devices.
Maybe a solution could be point to the original files.
Another solution could be to “local copy” the installer, to test everything as you said, but I don’t know if in this case would it be possible to point to a concrete HAA Main version. Maybe this has to be done by Ravencore. What I mean is, if you do a local copy of haaboot.bin associated with 3.2.0 version and you test it with HAA main 2.5.7, maybe you should assure that your release always points to this 2.5.7 version, even if the developer of HAA main updates the version.
Problem is that HAA Installer always points to “latest” and in this case, that caused the problem.
I don’t know if I have explained everything clear. I’m sorry because English is not my mother to fit and maybe I have made some mistakes but I hope you could understand what I’m trying to say :)
I want to take advantage of the message to say thank you for all your work in this project because you have made easier the flash process for people like me with no much time :)
Thanks!
Hi @yaourdt
Thanx a lot, again m, for you sw. It is so helpful!
... just wondered if u you were able to update the haa version.
Additionally, would it be any other way to point directly always to the latest ofícial version?
Thanx!
@spam667: You are welcome! I've updated mg2haa to directly install HAA 2.5.7, so the issue should be resolved and you can go ahead and flash your devices again 😊
If you are interested in the technical minutiae: Pinning versions is good practice and I'll stick with that (copying the binaries to this repo is the poor man's version of that). Why is it good practice? If I had not fixed the version, due to a now entirely different boot process in HAA, you would have ended with a device that would have been entirely unbootable => a fully bricked device unless you had a programmer at hand. What you ended up with due to the changes in HAAs update process is unpleasant, but could be solved without attaching an external programmer.
Also, the state you ended up in happened precisely due to the bad design pattern in the HAA installer I'm trying to avoid:
Problem is that HAA Installer always points to “latest” and in this case, that caused the problem.
You are entirely right on this: Would the HAA installer pin versions, this problem could have been avoided.