Today I had a fuse blow on my air handler and the reboot time of the thermostat turned 10 minutes of troubleshooting into a morning lost. I’ve had other minor frustrations as well. I’m not really a big fan of using a different UI on the phone than the screen (the temperature arrows in openhab are backwards form the screen’s buttons), and I’d like to be able to set the config entirely from the screen without the need for wi-fi or a phone. The last part is important if I want to isolate my IOT devices to their own LAN.
So the feature set would look something like:
Minimal Linux image for fast boot time, ie Alpine Linux or Arch Linux
No high memory usage overhead. Replace OpenHAB with a simple gpio adapter and config storage written in Rust.
Ability to set everything from the LCD that you normally would from OpenHAB, but with the addition to even configure the GPIO pin functions in case you have a custom HestiaPi board like me with additional GPIO pins - No need to edit a “default.rules” config
Similar interface to the official Hestia Pi UI, but with the above mentioned features added to the info/menu screen. Likely just fork the one touch UI and extend the menu out
Accessing from the phone gives you the same UI for a consistent experience
Is this a project others would be interested in using and contributing time to help test?
Not really answering your question but another approach I’ve had at the back of my head for some time, is a wifi-enabled microcontroller-based thermostat (“instant” boot, smaller size) with a touch LCD and MQTT and another Pi (3 or something) somewhere convenient with a power brick and another touch LCD (or not) running OH and anything else needed communicating with the microcontroller-based thermostat.
That’s a fair point. If you had an arm-based microcontroller is would be powerful enough to drive a touchscreen. You’d essentially have a low-power pi but without the OS layers as overhead. And having onboard flash memory instead of the SD card you’re less prone to data integrity issue. I think it’s fair that if I’m rewriting a significant portion of the software stack I should explore the hardware options more and consider alternatives there.
Not arguing against your plans, but I’ve been working on a rewrite of the existing OH configs and I’ve got the start time from power on to fully functional to 10 minutes. It’s still too long but I don’t think I can shrink it any further without better hardware or not using OH.
It’s not the memory that’s the problem with OH though for HestiaPi, it’s the fact that the RPi 0 only has one CPU.
But I would second the idea that if you are looking to go so far as to replace the whole software stack, reviewing the hardware would be warranted as well. I think using a micorcontroller makes for a reasonable approach. I imagine an ESP32 would be powerful enough to drive the screen and the relays. It might even be able to run on it’s own without an RPi controller at all. The code to drive the thermostat is not processor or memory intensive. A microcontroller could easily handle it. It’s the UI that would be tricky I think.
It will be though a non-smart thermostat. Internet connected but pretty isolated. And then you would have to reinvent the wheel for the UI, the phone app and integrating with other technologies and appliances…
For a personal project sounds fun and not so hard but if you want other people to find it “easy” to adapt and integrate on their use cases then an existing platform IMHO is the way ahead.
I will defend HestiaPi’s approach in that I have a thermostat that for the most part gets the job done.
If I redo the software I’m leveraging the hardware this community has already developed and improving the ecosystem overall versus forking myself out to an approach that will rest solely on my shoulders. Having a more “hardened” image could probably even open up the device to people who are less technically inclined and don’t care about the integrations, but care enough to not buy a privacy-invasive alternative from one of the big guys.
