Good morning.
I tried reflashing my HestiaPi One and it keeps failing. My thermostat is effectively dead. Please help.
I upgraded my wifi and changed the SSID, I am still broadcasting 2.4 Ghz. When I tried connecting the HestiaPi to the new SSID, it kept restarting with the original boot sequence. The device worked fine offline, but I wanted connectivity. So, I tried re-flashing the image with Balena Etcher but the image kept failing. I tried both mirrors and verified the MD5 checksum to no avail. I have tried two separate SD cards and have the same issue for both.
As an aside, I tried an Open Habian image and that imaged without issue. So, I believe my issue is directly related to the image itself. Can someone please help me troubleshoot this and/or provide another mirror link to give it another go?
Thank you in advance.
It sounds like you’ve already gone through many of the things that usually resolve these issues: verify the checksum, re-flash it, and try a different SD card. And even went beyond that and tried the mirror and another Raspberry Pi image, too.
I agree it seems like your hardware is fine and it’s an issue with the image/flashing ptocess, but I use the hestia-pi-ONE-v1.4-dev-bullseye-6185.img.xz with every unit I build, so this one is quite the puzzler.
When you say it “kept restarting with the original boot sequence”, that was before you flashed it, correct?
And do you mean that it would boot up and ask you to connect to the HESTIAPI access point, and then switch into the thetmostat UI after about 500 seconds? So it’d work only in offline mode.
After flashing the card, when “the image kept failing” does this mean it failed to boot at all, or that it went through the new thermostat setup and then only worked as an offline thermostat?
I use dd in Linux to flash my cards. If you can tell me what opeating system you are using Etcher on, I can download that software and try to reproduce the issue. Also, if you can let me know if you are using a Raspberry Pi Zero W or Zero 2 W, that will help me make sure I’m doing things exactly the same as you.
I also noticed that the installation page mentions Windows not being reliable at flashing images, but I do have one Windows machine that I can use to see of that’s the case if you’re using Windows.
I think we should be able to get to the bottom of this.
Note First time using the Blockquote tool, so I apologize in advance if the formatting is wonky.
Thank you for the quick reply. I apologize for my delay in responding, I just got home from work.
I used the same mirrors from the link you posted for the latest 1.4 dev version.
“When you say it “kept restarting with the original boot sequence”, that was before you flashed it, correct?”
Yes. Everything worked fine except logging into the new wifi and trying to install OpenHab Cloud Connector.
“And do you mean that it would boot up and ask you to connect to the HESTIAPI access point, and then switch into the thetmostat UI after about 500 seconds? So it’d work only in offline mode.”
Yes
“After flashing the card, when “the image kept failing” does this mean it failed to boot at all, or that it went through the new thermostat setup and then only worked as an offline thermostat?”
The image kept failing to be written to with Balena Etcher, please see the screenshots.
I’m running Pop OS, but am unfamiliar with the dd command. What arguments & flags are you using? I wonder if the image does not agree with Balena Etcher and that is the problem.
Based on the screenshots, it looks like you need to delete the partitons (sda1 and sda2) so you have only unallocated space, then flash the image to that unallocated space. You’ll also need to decompress the image before flashing it.
To decompress the image:
xz -d hestia-pi-ONE-v1.4-dev-bullseye-6185.img.xz
That should give you a hestia-pi-ONE-v1.4-dev-bullseye-6185.img file. I expect that to be able to be flashed with Etcher (I should be able to confirm this tomorrow).
If you want to flash the card from the command line with dd:
sudo fdisk -l /dev/sda
Make absolutely sure /dev/sda is the SD card! If there is any doubt, do NOT run the command below. If you overwrite the wrong drive, your computer will no longer boot.
sudo dd if=hestia-pi-ONE-v1.4-dev-bullseye-6185.img of=/dev/sda conv=fsync
Thank you for your commands. I was able to run through it on my own using dd. It seems Balena Etcher was the problem for me. I did not use the conv=fsync argument though.
It’s unfortunate I was unable to pipe xz into dd like you can with gunzip though, that would have been a time saver.
Ok. I am back into the first boot sequence of the HestiaPi, but is still will not connect to wifi and I’m stuck in a wifi loop (if I attempt login). So, now I’m starting to think it may be my wifi settings. I currently have 3 access points, 2 in range of HestiaPi. All with 2.4 Ghz, 5 Ghz, & 6 Ghz broadcasting with WPA3/WPA2 personal passcode.
Other than requiring a 2.4 Ghz signal, does HestiaPi have any specific restrictions for networking? I don’t see much on the Github page. Thank you again for all the help.
Update: I just tried connecting the HestiaPi to my original wifi setup/settings to no avail. It simply restarted without connecting again. I wonder if there is a problem with Rasberry Pi Turnkey.
The decompression and flashing with dd can be combined. I’m not at a computer right now to verify it, but this should do it:
xz -d < hestia-pi-ONE-v1.4-dev-bullseye-6185.img.xz |
sudo dd of=/dev/sda conv=fsync
The conv=fsync just makes sure all the data is written to the card before it returns. If you “safely remove” the SD card, it’s not needed.
As for wifi requirements, the only limitation I know of is the 2.4GHz requirement and I think I remember someone saying it has to have a password.
I’ll have to write up some more documentation about debugging turnkey. If you connect to the AP and then SSH into the pi, you can look at status.json and look at wpa.conf (both are somewhere under /etc, but I can’t remember the subdirectories). I’ll get back to you with the details on these.
At least we know the wifi chip is still working correctly since I can ssh into the local host. I did not find status.json in the /etc directory, but under home scripts. If there is another file of the same name located elsewhere, I could use some help finding it. The find command and I don’t always get along. The outputs are below.
sudo cat /home/pi/scripts/raspberry-pi-turnkey/status.json
{“status”: “hostapd”}
sudo cat /etc/wpa_supplicant/wpa_supplicant.conf
country=GB
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
Yeah, the status is in the home directory. And of course the wifi config was rewritten when it couldn’t connect. The startup code should make a backup of the wpa config before overwriting it. That way we can see the config that didn’t work, which caused it to flip into the wifi setup process.
I had some thing come up in my life that require my full attention. I’ll be back to try to come up with some mods to make debugging this easier as soon as I am able.
OK, I was able to sit down and review how turnkey works again. The short version is that you should edit /etc/rc.local to make a copy of wpa_supplicant.conf before running turnkey. That way you can see if it has your credentials before it gets overwritten. Something like this:
cp /etc/wpa_supplicant/wpa_supplicant.conf /home/pi/wpa.conf.`date +%Y-%m-%d_%H_%M_%S`
That way if it reboots several times you can see the revision at each boot.
Hopefully the config file will help is figure out next steps. Maybe the conf file isn’t written out correctly and you can manually correct it to get onto your AP?
If that’s the case, we’ll want to figure out what’s going on there so we can get it fixed upstream (in Turnkey).
How Turnkey Works
/etc/rc.local calls ~/scripts/raspberry-pi-turnkey/startup.py
startup.py will check to see if wifi is connected to an access point. If not connected (nor in hostapd mode), it will enable the HESTIAPI access point (enable_ap.sh).
On first boot, your device will not be connected to your home AP, it’ll overwrite wpa_supplicant.conf with the defaults and then triggers a reboot. Then it’ll boot up in hostapd mode, which brings us to where we are now.
When you use the web interface (http://192.168.4.1/) to select an access point and enter a password, it will check to make sure the credentials are correct. If not, it’ll notify you the password it wrong. If they’re good, it’ll write out wpa.conf, set the status to disconnected and then run disable_ap.sh, which will trigger a reboot.
Upon reboot, it should detect that the pi is connected to an AP and get you out of this loop.
