Hardware
As someone who stocks parts and ships kits and adsembled thermostats, I’m very interested in having a unjversal solution that works for everyone (or as close to it as we can get).
Not being able to use the pi boards with pins already soldered on is a drag, but changing that would require a different PCB design. I’d be happy to switch, but I have a bunch of the existing boards that I need to use first.
Also, I actually designed a new PCB in KiCAD the other day. It uses the solid state relays and has the pi flipped around so the top-side headers can be used. I haven’t gotten any boards made, so I don’t want to publish the design until it has been tested, but that’s going to cost $50 +shipping, so that probably won’t happen until I am through my existing supply of PCBs. If someone wants to have them made, I’d be willing to privately share the design.
I strongly prefer the the solid state relays for a number of reasons:
- Traditional relays require surface mount soldering (with the existing clicky board), which has several implications
- fewer people can build their own due to lack of skills or equipment (stencil, hot plate, solder paste, etc.)
- takes a lot longer to hand build each unit
- the current PCB design has SMT components on both sides, which means it’s not as simple as applying solder and putting it on a hot plate and being done with the SMT components
- they make noise
- the clicky PCB is not compatible with many of the clicky relays; an extra small version of the relays is required.
I understand the reasons for all these things, and if robots were mass producing the hardware, most of these concerns would be irrelevant. If we made the LEDs through-hole, that’d make it more palletable.
About the reset switch, the original board with the pogo pin works with both the zero and the zero 2. This makes the pogo pin more universal than either a male or female header. That is, as long as the pins remain soldered to the back of the pi. If you put a dab of solder across the hole in the pi zero, the pogo pin will make contact (and with the zero 2 this isn’t needed because there’s already a pad there). Of course, this conflicts with the desire to be able to use a pi with pre-soldered headers.
I looked into normally connected, through hole momentary switches at a 90° angle and all I found were large pushbuttons going for about $9 each. Not interested. With a different circuit, a tactile switch could be used, but then we’d need another relay or transistor.
The other thing I’ve seen done on circuits is to just short power to ground, which drops the voltage going to the pi to zero. I’m concerned about a potential safety issue if someone were to hold down reset button that it could damage the supply of the 5V (be that the 240V line, the 24V supply, or a standalone 5V adapter). We could put a resistor in there to limit current, but then the pi voltage won’t drop to zero. Maybe there’s some resistor value which would limit current to not cause a safety issue no matter how long the button is held down, and still drop the voltage enough to cause the pi to cut out?
I’m not sure on the best way to acomplish a universal reset switch. Suggstions welcome.
My desire for a model/version/revision/edition/name is to make it clear to people what they have and determine which software images they can run. Making it a release date works as long as we never give anyone a choice between the pi zero and pi zero 2, or silent relays and the clicky ones. But if the 2024-01-01 has a pi zero, the 2024-02-01 has a pi zero 2 and the 2024-03-01 has a pi zero, that’d be really confusing. The description could explain this, but it seems like the later version took a step backwards (when maybe it’s just a parts availability issue).
Contrast that with something like this:
- HestiaPi One (HP1-silent-1-US)
- HestiaPi One (HP1-silent-1-EU)
- HestiaPi One (HP1-silent-1-U)
- HestiaPi One (HP1-clicky-1-US)
- HestiaPi One (HP1-clicky-1-EU)
- HestiaPi One (HP1-clicky-1-U)
- HestiaPi One (HP1-silent-2-US)
- …
If a model were added in the future that used a pi3 compute module, it could be something like HP1-silent-cm3-US.
Everything built up to now should fit in somewhere in this scheme. I think we could build a guide to allow people to determine their model number based on a visual inspection of their thermostat.
Software
Then we get to the software. 
None of the thermostats sold with the pi zero will ever be able to run OH3 or later, and most of those units were soldered in place, so they’re not upgradable (without significant effort).
I am passionate that these users not be abandoned and have to use software that is not getting security updates. Supporting them will be a large effort, but people on this forum have made alternative firmware images and even UIs for this hardware platform, so it’s clearly possible.
Even setting aside legacy hardware support for a moment, the growing memory requirements of OH are also a bitter pill to swallow. The fact that we also need to fit an entire web browser, with a JS engine into this same 512MB or RAM makes it even worse. Simply put: I don’t see any way to continue using OH without upgrading hardware.
It’s hard to imagine fitting a full size pi in the existing case. It’s pretty tight in there as it is. Going with a compute module might work, although I haven’t looked into whether the socket can be hand soldered, practically speaking. The other option would be to switch SBC manufacturers, which is an even larger change with a large number of possibilities!
Summary
I’ve digressed from the topic of whether to give this new build a new model number, but I’ll try to summarize my thoughts nonetheless.
For legacy hardware, I think we are at the point where we need to find an alternative to OpenHAB. Hopefully whatever we find will be lightweight enough that we can run midori browser for the local UI.
For next generation hardware that can run OH4 and a web browser (w/ a JS engine)… I don’t know.
All of this is more than I have time to take on by myself. The task I had mentally queued up was to get the same versions of everything running on Debian 12 (32-bit). That’s a big enough task to keep me occupied for a few months worth of my “free time”. Finding a solution to the legacy support problem is a close second priority on my todo list. Actually, now that I know OH2 is unofficially EOL, legacy support might be my #1 priority.
You’ll notice that adding a huge number of features such as multiple sensors for a single zone or multiple zones, or RS485 based HVACs is so far down the list, they didn’t even get mentioned except as this footnote. 
)