Debian 12 (bookworm) image testing (v1.5-dev)

I have a new HestiaPi image based on bookworm that is ready for testing:

As with all previous releases, this will work with either a Raspberry Pi Zero W or a Raspberry Pi Zero 2 W.

This update is mainly just the same software as before, but on a newer version of Debian. The motivation to update is that the Long Term Support (LTS) on Debian 11 (bullseye) ends on 2026-08-31 whereas Debian 12 (bookworm) has LTS until 2028-06-30.

The default username is pi and the default password is hestia if you want to SSH into it.

However, there are some issues with the v1.4-dev image which have been reported, reproduced and resolved:

Here’s what I’d like from the people who read this message:

  1. Flash this image onto an SD card (ideally not the one running your HVAC, as you’ll want to be able to go back to that after testing)
  2. Swap this image in for the v1.4 image in your thermostat and try it out. It should work as well as the previous one. No additional features have been added.
  3. Report back here in this thread. What was good? What was bad? Did you even notice any difference?
  4. (optional) Swap the v1.4 image back into your thermostat so you’re running an image that has been properly tested and not the new image

If testing goes well (which seems unlikely on the first try, there’s almost always something that can be improved) then we’ll submit this image to @HestiaPi for final review and hopefully it will become the new v1.5 or v1.5-dev image.

If testing reveals issues, I’ll try to reproduce them, fix them, make a new image and then we can start this whole cycle over again.

When it comes up on its own network, sometimes it does not see all the available networks - and sometimes it does.
When it sees the network I want to use, and lets me select the SSID and give it the passphrase, it will drop its connection, but it does not seem to be trying to connect to my AP (AP doesn’t log any connection attempts). It does not restart the UI.

If you SSH into the pi while it is in AP mode (when the IP address of the pi will be 192.168.4.1), can you manually run nmcli device wifi connect YOURSSID password YOURPASSWORD and get onto your wifi? You should be able to the connection attempt on your AP, and I’d expect it to show you if it gives you an IP address.

If that fails to connect, that will make this issue easier to troubleshoot. It’s hard when the only network connection needs to be severed to run any tests. The way I’ve been dealing with this is to attach the screen directly to the headers on the pi and plug in a USB micro to USB-A (socket) adapter and then a USB network adapter into that. That gives me a wired connection so I can stay connected via SSH while running commands to switch from one wifi mode to another.

Also, if there are any non-alpha-numeric characters in your password, please let me know so I can try to reproduce this issue. They shouldn’t cause any problems, but if they are, I can take a look at the turnkey code and see if I can fix it and submit a patch upstream.

As for the listing of SSIDs, the command that turnkey is running is iw dev wlan0 scan ap-force. The only explanation I can think of here is that there might be a race to get the wifi driver loaded before it tries to get the list of SSIDs and sometimes it wins that race and other times it does not. You should be able to see any errors of that nature with journalctl -e, likely on lines containing rc-local.

If you want to follow along in the code, it’s in /home/pi/scripts/raspberry-pi-turnkey/startup.py. It’s helpful if you can read python code, but even if not, you can still see the commands (arguments to the subprocess.check_output and subprocess.Popen functions) and get an idea of what the code is doing.

I immediately lost the connection. No attempts to connect to the WAP were logged on the WAP.
Is there any way to activate the USB ports as RNDIS gadgets, to have a network connection that won’t go away?

Yes

All you need for this is a USB network adapter and a On The Go (aka a mirco-to-USB-A) adapter.

It was easier for me to set it up as a RNDIS device - so now I have an interface that won’t go away on me.

The WiFi connection just goes away after a bit. I’d upload the dmesg from the device, but I don’t see how to upload a text file.

I don’t see any way to attach a file on this forum, but you could put it on something like https://pad.riseup.net/ and then link to it from here. Using the default (60 days) should suffice for us to sort this out.

Hopefully we can figure out what I can do differently so I can reproduce this issue and come back with a fix.

Hi all ,

Looking to build a a second hestia stat for my remote building . I have been running hestia pi for years but wanted to update to bookworm . V1.5 is working very well and openhab works well . I have even traded out my bme280 for a bme680 to get aqi index. It displays well in openhab on basic dashboard but I can not figure out how to add this to the 3.5 spi display .

Thank you for the feedback about the v1.5 image.

I’d be interested in adding instructions to the owner’s manual so others can add bme680 support to their thermostats.

The code for the LCD UI is here and can be modified (if you’re familiar with nodejs and lint). I’m not familiar with either, and that ecosystem is very complicated, so I found making changes in that was pretty daunting for me.

@HestiaPi Do you have time to test out this image and see if it is worth promoting to an official 1.5 release?

Yes, I will make time and test it too.

Just tried it on the crowdfunded hardware most people have and although the provisioning works (filesystem expanded, reboot, WiFi details entered fine, reboot, connects gets IP and shows it, UI loads) it is unusable. Touch is almost not responsive. Web is OK but relays never get to trigger. ssh’ed into it. After 10h “idle“, top shows 1.68.

I have a Pi Zero 2 W somewhere (header soldered?), I’ll try to spin and report back hoping its that.

Hmm, it looks like both the boards I was using for testing were Pi Zero 2 W boards. I thought I was switching back and forth, but seems I don’t have an original Zero W anymore. I’ll have to buy one next time I place an order so I can test with it. I’ll put a bright sticker on it so I don’t lose track of it this time!

I remember the load average with the previous image being high, but the touch only had about a quarter second lag. If it’s more of a laggard than that, that’d have gone too far, let alone the relays being non-functional.

If you pop in over SSH and see anything else that we can disable, let me know. My guess is that it’s things that are core to the O/S like the kernel or systemd that have changed, but I’d love to be wrong.

Hi Hacker ,

Been still working on ui to get air quality added . I Got it to show up on info page . I hooked up my relays today and noticed they are not clicking . no change on output board either . I even did a fresh image and got the same result . Am I missing something ? reading up on gpio it seams a lot has chnged when going to bookworm

Pi Zero 2 W performs identical! I can only change temp setpoint on the screen so touch (driver, hw, calibration data) is working.

top gives similar values as before.

Sorted by running time (shift + t)

by cpu (shift + p)

by memory (shift + m)

relays don’t work.

Why is it working on yours though? Sometimes dodgy SD can cause weird issues but I tried 2 different Kingston ones. Also reflashed your image fresh from my previous attempts (Zero “1” W).
Weird…

I don’t actually have an HVAC system that can be controlled by the HestiaPi anymore.[1] My current system is a WaterFurnace which uses a serial (RS-485) connection between the thermostat and the HVAC. No relays. No 24V A/C power.

I’ve been testing with a standalone 24V A/C power supply and using the UI to tell me if the solid state relays turn on or not. Clearly that was a mistake. :person_facepalming: Sorry about that (and that’s why I insist on other people testing before we cut a release).

Relays not triggering

I see what @cheeseyone1 means about using /sys to control GPIO being deprecated in 2015 and since the usual /sys/class/gpio/gpio12/ no longer exists in bookworm, that’s apparently when they removed it.

I can get to work with switching over to gpioset (e.g. gpioset 0 12=1), but this new gpio system is no longer stateless. Based on what is in the gpioset man page, as soon as that gpioset command returns, there’s no guarantee that the pin will stay high. According topinctrl, it does stay high in practice (at least with the Pi Zero 2), but I can’t verify that it really flips the relay in our circuit. Meanwhile gpioget resets it to zero before reading the value (which is then, of course, zero) so I’m not sure what the point of that utility is… it’s always going to report 0!

If someone can confirm that running gpioset 0 12=1 will turn on relay 1 in real life, and that pinctrl get 12 returns the accurate state, that’d make me more confident in my ability to find some solution here.

Backward compatibility

Backward compatibility might be tricky here too. I see gpiod was around in bullseye, and it looks like it was introduced in buster (2019). That gets us compatibility with 1.3-dev and later, but 1.1 was based on Jessie (and I believe 1.2-dev was as well).

Although, I suppose if anyone is still that far back, they’re probably not going to upgrade to the latest code from the hestia-touch-openhab repo either, so maybe it’s not a big deal to update those rules?

Laggy touchscreen and/or web

As for the laggy touchscreen, I’m not sure how to explain that part. It’s responding fine for me on the Pi Zero 2 W. No issues with the web interface either. I’m seeing similar load averages to @HestiaPi but that’s only like 50% of the capacity, since it’s a 4-core CPU.

I’ll try to convince some local friend to use a HestiaPi so I can use their house as a testing ground now that I can’t use my own.

Footnotes

[1] This is something I intend to fix by making the HestiaPi compatible with WaterFurnace, likely using GitHub - ccutrer/waterfurnace_aurora: Library for communication with WaterFurnace Aurora control systems. There are a lot of other things that need to happen as well, but since I’m personally affected by this one it’s reasonably high up on my todo list.

gpioset 0 12=0 and gpioset 0 12=1 do turn relay on and off . gpioset 0 12=0 turns relay on

Yeap. Instant click high and low:

pi@raspberrypi:~ $ gpioset 0 12=1
pi@raspberrypi:~ $ gpioset 0 12=0
pi@raspberrypi:~ $ pinctrl get 12
12: op -- -- | lo // GPIO12 = output
pi@raspberrypi:~ $ gpioset 0 12=1
pi@raspberrypi:~ $ pinctrl get 12
12: op -- -- | hi // GPIO12 = output

Do what I did: build a test jig. Get a transformer that puts out between 12VAC and 24VAC (a doorbell transformer is perfect for this). Get 4 LEDs, and 4 resistors of about 1kOhm. Wire that up to 6 wires - common, 24VAC, and the 4 LEDs in series with the resistors, and you have a test jig.

1 Like

Did something very similar with the Crowdfunding campaign manufacturing 1000 units by hand.

My differences due to the fact I wanted it to make the 1000 times repetition easier, safer and more reliable:

  • Used 24V AC mini lighbulbs
  • Used concave pogo-pins on a custom PCB aligned perfectly on the solder points along with long metal rods guiding the PCB movement
  • Custom image on a test SD running demo screen with touch enabled to test, reading the sensor and switching each of the 4 relays on and off one a time