Long story short - ESP32-based HestiaPi implementation
Keeping it in the background for too long didn’t really help as we never got the time to start an open discussion about it, so people started talking about it.
Over the previous months the project has been stuck to go forward due to below issues:
Price - An HestiaPi may cost (just the parts) 2-3 times the original price
Availability - We’re sure you know what we’re talking about
Hardware limitations - Keeping up with latest OS versions and software is bringing Pi Zero to its limits and there is only so much we can do about it
We are also completely out of stock (aka zero sales) as we stopped production but our running costs keep coming out of the crowdfunding campaign earnings.
So we are considering a new model to be manufactured to accommodate all that (with a compromise).
An ESP32-based HestiaPi implementation!
Here are some bullets of what we are trying to accomplish:
Easy sourcing - Choice of ESP32 board should depend on how easy it will be for people to buy it
Standard materials - LCD, relays, connectors and PSU need to be uniquely identifiable to avoid confusion
Same form factor - Ideally keeping the same case and touchscreen (although a smaller would probably be possible)
Same UI
Instant boot
Non-volatile memory to avoid corruption due to power outages
Compatibility for both US and EU houses
Upgradable
MQTT-based communication - Allowing you to use any Smart Home system or even custom ones
Here is what we will not have:
Client-based logic - HestiaPi has been the (OpenHAB) server so far that could run on its own or even allow a bunch of smart home appliances to integrate it like many people did. As the demands have increased and many people already have their separate smart home servers elsewhere, making Hestia a client would fit the model better.
Modifying the code on the fly (SSH into Hestia and change some files and restart a service) will have to be a bit more complicated as ESP32 runs off pre-compiled code. On the other hand, the above process may be much faster than it used to be
So this is a quick sort of announcement to get ideas in and start organising the work needed to be broken down. The goal is to get as much input off the community as possible and finalise an open hardware open software product that we can take to China and mass produce it cheaply for everyone not wanting to make it themselves.
More posts will follow to thread off individual tech talks…
I feel like features could get its own entire thread at a minimum. To get us started: remote temperature sensing, support for WaterFurnace HVAC units (it uses modbus, there’s work that has been done on this that uses a RaspberryPi and OpenHAB), multiple zones, three stage heating and two stage cooling, dehumidification, and scheduling. I have many more, but those are the big ones. As for removing them, I don’t use the boost feature. I just adjust the set point slightly in the event I want the system to turn on for a bit.
I’d like the UI on the thermostat hardware to remain simple with the actual goal being that it is easy to use. Maybe not exactly the same as the ONE pixel for pixel, but I imagine it would likely be pretty similar. To accomodate additional features, I think the web-based UI needs to be easier to customize and possibly more complex, but that may be a separate conversation.
I like the current screen in terms of hardware, but I don’t have super strong feelings about it. Cheap, color, touch screen, and readily available (bonus if multiple companies make compatible ones like we have now). The little animated driving info on the LVGL page looms super impressive, so if it’s really that responsive with a microcontroller, I’m sold.
Agreed
I agree we should sort this out last. If supporting ModBus based systems (geothermal systems, heat pumps, and other highly energy efficient technologies), it will affect the power supply. I expect we’ll just be able to swap in whatever is appropriate. I like the idea of just a few simple components (resistors, diodes, & capacitor) for the US system, but for the EU, going from 220V down to 3.3V is going to require a transformer and buying a converter probably makes more sense. Fortunately, we don’t need to worry about the details of this until later.
Will soon edit original post to add core topics with links to separate threads as indeed there may be a lot of discussion going on.
Till then a few comments (keeping the same numbering as reference):
(Features): As the Hestia32 will act as a client we are not sure how much functionality will be present also as standalone. The main logic would be to report back to the whatever server (OpenHAB, Home Assistant, etc) is configured and act upon the connected hardware so for example multiple stage heating/cooling, de/humidifier may just be terminal connections and relays exposed via MQTT. Features like scheduling may stay where the rules would run, the server. Also acting as a client most likely will mean that one would need a different kind of phone app (if any) with a way to describe desired logic if they were to use without a server. This is not really the scenario we are to trying to tackle with Hestia32.
(UI): The UI shall be able to adjust to enabled/disabled features so people can remove clutter.
(Screen): The exact same screen will definitely not be used mostly because the backlight cannot be turned off An SPI ILI9341 touch LCD (TFT, IPS, OLED?) of 3.5" (or even 4" if we want to sacrifice the case design to another with a bigger screen opening) seems as a very popular option with many existing solutions. Many include an SD card reader which may be useful for provisioning, logs, export/import
(ESP Board): A fairly generic board like the NodeMCU will possibly tick many boxes. We cannot see the list of features/specs determine drastically the selection of boards that would be able to support it. More exotic boards that may include more features and interfaces increase coupling and reduce sourcing options.
(PSU): The much less power consumption (compared to the Pi) would definitely increase our options for available plugin modules, reduce heat inside the case and may (ok long shot…) allow for a single solution to cover both 24 and 220V AC.
Something else that may need a lot of thought is the development environment. Arduino or ESP-IDF? Arduino lowers the entry level for many community members to read, understand and alter the code but may be limiting in the future for more advanced features once we get an MVP out. ESP-IDF is C++ based and is the exact opposite. Maybe after we choose one, someone will port it to the other but it will be impossible to maintain in a non-manual way so we will have to pick one and stick to it.
For a central air based system the current one has way more features than needed. A lot of the features get implemented by the HVAC controller board also. Though for simplicity sake I can see creating custom builds maybe for different types of systems rather than trying to put everything into one binary and turning features on and off through settings. You ought to have a smaller load on the microcontroller and have an easier to maintain codebase: win win.
When I had the HestiaPi driving my HVAC system (I’ll get back to it eventually) this was the feature that I’ve missed the most. It definitely is a feature that distinguishes HestiaPi from the rest of the smart thermostats out there.
Mitch Hedberg had a joke that I use as a home automation philosophy:
You should never see an escalator out of order sign. Escalator temporarily stairs, sorry for the convenience.
When an elevator is out of order it’s no longer fit for purpose. It can’t do anything. When an escalator breaks it’s less convenient but it can still help you get to another floor. When everything breaks, the end devices should still be fit for purpose, if even a degraded stat.
Given that, I’d say that any thermostat must be able to perform most operations independently. At a minimum, I would expect a thermostat to manage all the core HVAC controls based on what ever the current settings are which I would expect to handle:
maintaining the temperature according to the setpoints to include multi-stage
maintaining the humidity according to the setpoints
maintaining water temperature according to the setpoints.
I can definitely see adjustments to the setpoints, enabling/disabling features, schedule, and all that sort of stuff being off the host. But those core features gotta work independently of any third party system.
Otherwise the whole system becomes brittle.
Given the capabilities of an ESP32 I’m somewhat confident that all the same control logic currently implemented as OH rules should easily fit along side any libraries and drivers necessary to drive the screen and sensors.
No opinion
Are we even going to have a web based UI?
The current screens are, based on my experience a little flakey and often do not register touches. Something better on that front would be nice.
Isn’t NodeMCU an ESP8266? Did they create an ESP-32 version when I wasn’t looking? Appears they did. Cool!
Assuming it’s the same as the ESP866 version, there should be plenty of GPIO pins and WiFi with one analog pin should you need it. I can’t imagine you’d need more than that in a thermostat unless you want to set up some sort of BT implementation (maybe Matter over Bluetooth? )
If designed correctly they could still exist in a single codebase and let compiler pick only the common stuff in and leave the exotic features to be manually pulled in with a #define, menuconfig or something.
That is correct. All basic stuff should work even without a server ever configured in or in the case of simply gone offline, the server should be notified on a second stage once it is handled locally first. So maybe we will have to distinguish what will be classified as “basic” (works as standalone) and what “advanced” (will follow orders from the server).
Hmm… thinking about it now I see no point. What I had in mind initially when I mentioned the UI, were users without an existing server or system running but needed a way to control it. I don’t see a reason to support such functionality now. So maybe provisioning and maybe initial configuration is the only reason left and this is something minimal not worth mentioning here.
I’m feeling you… capacitive touch screen (aka the screen types all phones have) with better viewing angles too would look much nicer. Need to go out checkout prices. I think the screen alone is gonna be like 80% of the total costs.
Hmmm… interesting. Haven’t really read much about it but looks promising. With your exposure from OH, how much a viable standard do you see it in a few years?
It kind of fell on it’s face outside the gate but there are enough big players involved that I think Matter could become a thing in the coming years. They dropped the ball with this initial roll out and now there are not enough companies deploying devices.
But if it does take off, everything is going to be Matter first.
That would be the way if we choose Matter but it is gotta be an additional option after typical MQTT over WiFi. That possibility strengthens the choice of ESP-IDF over Arduino IDE.
No, but I started looking at another ESP-32 based project (the “AirGradient One” air quality monitor).
In the first 3 hours I open 3 tickets on their issue tracker and still haven’t been able to compile the project yet. I believe this is just a lack of documentation, not releasing the library that works with the latest code, and odds and things like this which can be improved.
However, it does illustarate that the learning curve is a lot steeper for tinkering with ESP-32 systems than it was for getting the HestiaPi ONE working.
So I think combining forces with smeisner would make a lot of sense.
Someone pointed out that we may want to look into this hardware for the Hestia32.
It looks very nice, at least for a common development platform. The integrated Matter protocol is a feature I’ve heard some people on this forum are excited about.
An SPI ILI9341 touch LCD (TFT, IPS, OLED?) of 3.5" (or even 4" if we want to sacrifice the case design to another with a bigger screen opening) seems as a very popular option with many existing solutions. Many include an SD card reader which may be useful for provisioning, logs, export/import
)