I have been running my Hestia for almost 2 years with no issues (although my limited skills meant it took a while to get the hestia and router to talk happily to each other…).
Anyway, not sure what version I have (but it probably has a 1 in it!).
So, my question - should I upgrade, or ‘if it ain’t broke…’ - I guess the other way to ask this: is there a risk if I don’t upgrade? Do the advantages outweigh the risks?
I think that depends if you mean “Upgrade the OS on the Hestia Classic” (which is what I’m doing) or if you mean “Upgrade from Hestia Classic to Hestia Touch”. @Mark, can you clarify?
Sorry, missed this reply. My question was about updating the classic. I’ve had it running well for a couple of years, but wondered if I’m missing out by still running the original code?
Yup, TT those are the versions I’m running. I had the impression from the website that there were newer versions, but perhaps those are for touch then?
I can confirm, these are the last official ones as we moved to the Touch version but gwmngilfen has implemented and documented some brilliant new updates.
What is broken is the update check mechanism since the website update as suggested which will be fixed. @gwmngilfen are you OK to include a link to your info (please advise what’s the best) on the update mechanism page? Can this be “scriptable” as I remember it includes a few steps?
I can make it easier install for sure. At the moment I’ve noticed that it’s super-not-happy with all the wifi restarts I experience, so for now I’ve had to add hestia_mqtt to my wifi-restart-monitor script. That will probably need making more robust before it’s worth giving to non-technical users.
Once it’s sufficiently safe I can probably release it as a gem on https://rubygems.org which means install becomes “apt-get install ruby ; gem install hestia_mqtt”. With a bit of effort you could probably make it an official update
Just out of curiosity, what extra functionality have you added? I should add that I certainly don’t consider myself as very technical when it comes to this stuff - I enjoy the challenge (up to a point!) but don’t have the formal background in computing to properly understand all the steps, so I wouldn’t attempt any updates unless it was fairly straightforward, if that has a bearing on this discussion too. The risk of buggering up the heating at this time of year and having to explain why to my wife is way too high!!
Well, making it more robust is good for me too. But yes, it’s not super-high priority right now. I’ve added it to my todo list, will see if I can sort it at some point.
@Mark you can get the full overview on my blog here. The short version is that I was already using OpenHAB when I got my Hestia Classic hooked up, and since I was already using MQTT (a messaging protocol) for other things, I dove in to try and make Hestia report/react-to MQTT messages. The end result is that OpenHAB actually controls my heating now, which makes it much easier to add in additional temp sensors and so on.
I’d be happy to help you get it set up, if you are interested, but it’s only useful if you have something else on the network that speaks MQTT
You can always clone you SD card to a new one and leave the “working” one somewhere safe untouched while hammering on the cloned one. If you really mess it up, shut it down, put back the old untouched SD and it is 99.9% chance you will be back where you left it.
Actually that’s a good point, but I have a small problem. I have an 8gb card in now, but I can’t get any of the replacement ones of the ‘same’ size to accept the image: even when formatted multiple times they come up short of the original image size. I can’t remember what brands, but they are all reputable ones. Is there a way to reduce the image size, because the actual content doesn’t need that much space, surely?
I do it all the time as all of HestiaPi SD cards are 8GB but I have a 4GB lying around used for testing only and large images fit nicely, that is dd stops writing and complains “No space left on device”. Still the SD boots fine.
Mind you it saves a lot of time to write the actual data only. So I have found the following script that I run on the big image file and eliminates the empty space. As it overwrites the img file, I would advise to make a copy of the img file first.
Use with care and note that you will need to expand the SD afterwards as it will have 0 free space, duh…
Usage: ./autosizer.sh [Image_file.img]
#!/bin/bash
# Automatic Image file resizer
# Written by SirLagz
strImgFile=$1
if [[ ! $(whoami) =~ "root" ]]; then
echo ""
echo "**********************************"
echo "*** This should be run as root ***"
echo "**********************************"
echo ""
exit
fi
if [[ -z $1 ]]; then
echo "Usage: ./autosizer.sh <Image File>"
exit
fi
if [[ ! -e $1 || ! $(file $1) =~ "x86" ]]; then
echo "Error : Not an image file, or file doesn't exist"
exit
fi
partinfo=`parted -m $1 unit B print`
partnumber=`echo "$partinfo" | grep ext4 | awk -F: ' { print $1 } '`
partstart=`echo "$partinfo" | grep ext4 | awk -F: ' { print substr($2,0,length($2)-1) } '`
loopback=`losetup -f --show -o $partstart $1`
e2fsck -f $loopback
minsize=`resize2fs -P $loopback | awk -F': ' ' { print $2 } '`
minsize=`echo $minsize+1000 | bc`
resize2fs -p $loopback $minsize
sleep 1
losetup -d $loopback
partnewsize=`echo "$minsize * 4096" | bc`
newpartend=`echo "$partstart + $partnewsize" | bc`
part1=`parted $1 rm 2`
part2=`parted $1 unit B mkpart primary $partstart $newpartend`
endresult=`parted -m $1 unit B print free | tail -1 | awk -F: ' { print substr($2,0,length($2)-1) } '`
truncate -s $endresult $1