I have good news, I’ve now built a HestiaPi image on Debian 9 (stretch) and confirmed that it works on on my thermostat. Now I’m asking for others to make sure it works for them.
Download from here:
This should be functionally equivalent to the 1.2-dev image. This means that there no improvements should be expected (yet). It also means that if a feature works for you in the 1.2-dev image, it should work here.
I will also be attempting to upgrade to Debian 10 (buster) and then 11 (bullseye), however they are proving to be a little more challenging. This Stretch image is important because if things are broken here, I want to address them so I know what was broken because of buster versus what was broken because it only worked in jessie.
Thanks hestia_hacker got it loaded on my dev HestiaPi and will update you with my results.
Update:
The Good:
It seems to start up and get into the thermostat mode after I fixed my network issues
Issues maybe?:
Networking seemed to be stuck on 192.168.4.1
a. I tried to find the wifi HESTIAPI AP but could not find it.
b. Next I tried to edit /etc/wpa_supplicant/wpa_supplicant.conf still stuck on 192.168.4.1
c. What did work was to keep my edits to wpa_supplicant.conf and edit /etc/dhcpcd.conf
allow-hotplug wlan0
iface wlan0 inet auto
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
I tried to test the heater relay for conductivity, and that seemed not to work correctly after I adjust the temp up to turn it on I did not get any conductivity?
Does anyone know of a way to turn the relay on and off to test it? This hestiapi is a new build many I did not solder something correctly.
Thanks for helping test. The HESTIAPI AP should show up within a minute of it displaying the screen telling you to connect to that network. It’s hard to debug when you don’t have a network connection, but if there’s anything in any logs that might help explain what might be going wrong, we can go from there.
You should be able to both toggle a relay and determine if it is on or off. These are controlled by the GPIO pins, which can be accessed by SSHing into the pi and doing something like this:
cat /sys/class/gpio/gpio12/value # see if it's on or off
sudo su -
echo 1 | /sys/class/gpio/gpio12/value # turn on
echo 1 | /sys/class/gpio/gpio12/value # turn off
The pinout is documented on the wiki, and I believe relay 1 (GPIO 12) is heat, but you can test them all out individually.
Everything seems to check out. I was able to confirm that the gpio pins were working (conductivity check did not work but when I use a 5v power supply it checks good). I did see the Hestiapi AP, but the pi rebooted before I could connect to it and set up wifi going back to my old way of setting in the file system.
@hestia_hacker Side note I have a pi zero 2 w Hestiapi pi set up to test this stuff on also will try that sometime, but I think stretch is too old to run on pi zero 2 w
Pi Zero 2 compatibility is on the roadmap, as is later versions of Debian (Buster, Bullseye). I’ll be glad to have help in testing those when I get there.
Stretch feels heavy. 1h later and load average: 1.37, 1.79, 1.87 this is reflected on the WiFi provisioning process. You need to be (very) patient, but it worked fine
Original provisioning page on mobile phone has a very handy section with a short url (to find the IP it will receive after reboot) which unfortunately does not work (domain/service used is not around anymore). Please remove as in original 1.2
Please remove history entries. I believe packitupandgo.sh in scripts directory does that among other things not needed here.
(my) LCD may need different calibration data as bottom icons - and + work, but top icons and (i) do not respond.
Text cursor icon appears (shouldn’t, nor standard pointer cursor) and it appear in different point to where I pressed (which is most likely related to point above)
Will update this post with extra findings as I go…
I’m not sure what to do about the slowness of the stretch image to speed it up.
Where can I find that short URL? I looked here but didn’t see any shortened URLs
Done. I’ll do some internal testing and then push it out to the public repos
Interesting. It worked with my hardware. If we can’t detect the hardware and use the right settings, is there some way we can make it easy for users to make fixes?
That should be addressed by xset -nocursor, which is called from /etc/rc.local. Perhaps if we find a fix for number four this will resolve itself.
1 true
2. Possibly here is where message var is created and shown in index.html on the phone
4. Not sure… so far with “mass” production, same settings worked for all but the LCD was the same model everywhere
5. Do you not get the text cursor?
2: I believe this is fixed now, but I didn’t notice it before so I wasn’t sure where to look
4: I’m using the HestiaPi I got in the kickstarter project for hardware testing at this point.
5: No. Well, mostly no. If I click like a sane person, I do not get a cursor. If I mash the screen like a maniac, it will show the cursor (not just like a double click, but something like a quadruple click will make this happen). When I then transform back into Jekyll and click normally, the cursor disappears again and the system works as desired. This same behaviour is the also present for me in the 1.2-dev image.
