HestiaPi ONE revision 2?

Customization
1

I’ve been experimenting with various components over the past year or do and I think I have some concrete improvements. To be clear, I stole pretty much all the ideas from this forum, so the only credit I deserve is ordering a bunch of components to see which ones actually work.

I’m trying to figure out how to distinguish this revision from previous ones, or if this version even should be clearly distinguished.

1000004761
10000047611920×1440 273 KB

It’s just two changes, a 2x20 female header and a pogo pin (or 1x1 female header). However I think each is important.

The 2x20 female header makes the Raspberry Pi easily replacable. This makes it both more repairable and upgadable. The latter is particularly important since only the Pi Zero 2 W can run OpenHAB 3 or later.

That brings us to the pogo pin. The Pi Zero 2 is not actually pin compatible with the original Zero W, despite their marketing claims. The 2 replaced the reset pin with a reset pin on the back of the board. Until the 2x20 female header was added, there was not room for a pogo pin, but now there is.

The pogo pin I am using is just barely long enough. If the Pi is not fully inserted in headers, it will not make contact. The pin also has to be perfectly vertical when soldered in place, which is harder than I expected. These points aside, it does work, which restores the functionality when a Pi Zero 2 is used.

If using the original Zero, the pogo pin can be replaced by a 1x1 female header to accept a male pin that would be soldered onto the pi.

Finally, the female header also lifts the pi up just far enough to power the unit with a USB cable. This means for all those houses without a common wire, they can power it with a standard USB cable. No more need to make a custom cable, thread it through the case before soldering it in place, or figure out what connector could make it detachable, but still slip through the holes in the case.

So my questions are:

  1. Do we give this build a different model number to indicate it is repairable, easily powered by DC power, and uses the Zero 2 W instead of the Zero W?
  2. And if so, is it a “revision”, and “edition”, a “version” or something else?

Maybe if it uses a Pi Zero 2 it should be called a “HestiaPi Two” instead of a the “HestiaPi ONE”?

After all, at some point the software will diverge (namely when OpenHAB drops 2.x support) and the old units will be stuck at an EOL OH2 while the Zero 2 based units will be able to move along to OH 3 or 4. I am not looking forward to that change, but I acknowledge that it is coming and if we can minimize confusion with distinct names now, I think it makes sense to consider doing so.

Parts list & supplier

Side note

It is worth mentioning that the clicky edition of the ONE can not take advantage of the pogo pin because the pi was flipped to sit upside down in that edition. This just means no pogo pin and no ability to reset when using the Zero 2. It’s not a huge deal, but kinda a bummer.

3 Likes
2

Well done @hestia_hacker !
A few thoughts:

  • For people with header already soldered (sticking upwards) this needs a modification (remove header, solder new one from the bottom) which can be dangerous without enough desoldering skills
  • If you keep the original header (sticking upwards) and flip the pi to face the PCB one of the USB connections is free to be plugged in from the top for external power. I realise we may have kept this a secret since we were trying to get factories for PCBA.
  • We have always tried to offer universal solutions and the pogo pin option leaves some people out
  • We dropped the solid state relays (although sexy) for below reasons
    • They dont click (duh) and can confuse users or make debugging harder
    • They only switch AC currents which is hard to grasp without RTFM
    • For HVAC, 24V AC was not within the operating ranges I believe (75 to 264 VAC for the G3MB-202P) although it “worked”
  • A more universal solution was considered back then for the reset functionality. Something that would cut the power straight away one way or the other

Regarding the name… putting all the essential info in the name is quite hard. We would put the release date as the “name” and the rest in the description. We have never had a strict naming convention so it is not fair to apply it now on your design so let’s talk about this.

3

Some comments concerning openHAB.

As far as the OH community is concerned, OH 2.5 is already end of life and had been so for quite some years now. There are still a few who pop up on the forums asking for help with this or that but for the most part support is very limited because pretty much everyone has moved on. Even OH 3 is seeing fading support already.

There is definitely no back porting of patches to 2.5.12 (the only version of OH 2.5 still available from the OH download pages, long story but we lost everything before that when bibtray sunsetted). In fact, bugs are not being back ported even to OH 3 so your next target should be OH 4 if you care about being supported.

Also note that the version of Java (1.8) OH 2.5 requires is challenging to get running for newer versions of Raspberry Pi OS and is itself end of life iirc.

The 4 core CPU on the Pi 2 W is a great improvement but it’s still low on RAM. Unfortunately Java 17 causes OH 4 to require even more RAM than OH 3 does, exacerbating the problem.

To add even more woes to the situation, the newer JS rules engine has an issue where the first run of a rule takes up to 30 seconds to start with the only solution being to use 64-bit OS and Java which increases the demands on memory even more. This excludes Blockly as an option to rewrite the rules in because Blockly compiles to the newer JS.

The current Hestia Pi rules are written using Nashorn JS which is also long past end of life upstream and it provides a nearly decade old version of JS (ECMAScript 5.1). So the rules will need to be ported to something else.

Since neither JS add-on is suitable I’d recommend jRuby or Groovy. We’d need to experiment to see which has the lower memory requirements. The whole reason we moved off of Rules DSL in the first place is still there so it’s not an option. HABApp or something custom is worth looking into as well. Even if it’s a separate app, it might have lower memory requirements over all.

No matter what, auditing the bundles installed in OH and eliminating those not needed (e.g the LSP server) is going to be a must as well.

The good news is that with UoM improvements in OH 3 and especially OH 4 a bunch of the rules and special logic in Hestia Pi can be eliminated greatly reducing the rules complexity. jRuby is also very terse which will drastically reduce the amount of code as well. Even the newer JS add-on will improve readability if the code.

4

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. :face_with_diagonal_mouth: 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. :sob:

5

Just to be clear about OH’s release cycle. There is a new release of OH every six months. Very significant bug fixes will be back ported to previous versions of OH but only one version back unless it’s something like the log4shell vulnerability.

Given this, any version of OH older than a year should be considered EOL (that means OH 3.4 should be considered EOL). There is really no concept of LTS in the openHAB project. The only versions receiving updates are the current release (OH 4.1) and the next release (OH 4.2 which will become the current release in a week or so).

For the most part, the openHAB that shipped with HestiaPi in the first place was near EOL even before HestiPi One was initially released. As of now, OH 2.5 hasn’t seen an updated in over four years and even if there were a level 10 CVE against it, it wouldn’t be updated.

I was happy to contribute to the project to make the rules run better, but OH has always been not the best choice for this application. It’s release cycle is too fast and it’s resource requirements are too high for an embedded application like this.

1 Like
6

I started looking for a more suitable hub that will work with the existing hardware and it’s tough going. Here are the ones I looked into and what the biggest problem is.

  • OpenHAB (requires FPU)
  • Home Assistant (requires more memory than the pi zero has)
  • Homey (turned out to be a closed source product, not open source software)
  • ago control (the FAQ asks “is it real?” and the answer links to a non-existent download page)
  • Calaos (no longer maintained; last blog post is from 2015) website, hardware requirements, documentation
  • pimatic (no longer maintained), too bad too because the installation page specifically mentioned running on the pi Zero
  • Homebridge (Apple-only project code repo)
  • EventGhost (Windows only software)
  • PiDome (unmaintained, last commit was Feb 2020 :skull_and_crossbones: )
  • Nymea docs (only supports the Pi Zero 2, not the original Pi Zero)

There are also some which require further investigation, starting with the top contenders:

  • MyController: code repo, website, forum (specifically mentions supporting the pi zero, says it only uses 50MB of memory!)
  • RaspberryMatic: code repo (runs on a Pi Zero)
  • Gladys Assistant: code repo, docs (runs on a Pi Zero)
  • HomeGenie: code repo, website (runs on a pi, but not sure if it’ll run on a Pi Zero)
  • domoticz: code repo, download, owner’s manual, forum
  • FHEM: code repo, download, docs
  • ioBroker: code repo, download, docs (most of the documentation is in German, which I can’t really read; does support community plugins)
  • Jeedom: code repo, website (most of the documentation is in French, which I can’t read at all; the open source edition may not allow any plugins)
  • Smarthomatic: code repo, website (doesn’t control devices, focuses mainly on custom hardware created by the project’s author. Looks interesting for people who want to have an open source home, but doesn’t seem to fulfill the goal of connecting existing commercial devices together)

I plan on investigating these further, starting with MyController. If it looks like it’d suite the needs of the HestiaPi project, and run on the original HestiaPi ONE, I’ll post back here with how I plan to proceed. If anyone knows of any projects that I should also look into, let me know and I’ll add them to my queue.

I’m both looking forward to having a better image to run on the ONE, and also dreading the amount of work involved here. :sweat_smile:

Edit to add: I found some more to add to my list of projects to investigate and one more that doesn’t support the Pi Zero so we don’t need to investigate it.