I was asked to post my email discussion with HestiaPi here. I will then continue it in a subsequent post.
What happens to the HestiaPi Touch when the power goes out for up to 2 weeks and then comes back on? Does it save all its custom user-programmed parameters and last operating state in non-volatile memory (for some maximum period of time), and then resume all previous operation automatically without needing any attention from the user?
user-programmed parameters > YES
last operating state > NO - Imaging having heating ON and getting a power network failure but you are leaving for a 2-weeks holiday. You wouldn’t want to get the heating started while on the plane. So on reboot, everything is OFF unless you have hardcoded it to start something as default.
The PCB appears designed for a 9V battery backup, but the battery terminals are unpopulated – if I populate them myself, then will the 9V battery backup function conventionally?
Not sure where you see that. There is no battery support. Pi even Zero is not really a battery operating board when we are talking on a 24/7 operation.
I cannot find an image of the “translucent” case – is translucence achieved by applying a matte finish to a clear plastic (by molding, etching, beadblasting, etc.) or by using a “smoky” light-colored plastic? Or, is it actually “transparent” instead of “translucent”?
We use translucent plastic on a 3D printer
Can I write the mathematical algormithm of how the present and past (historical) temperature, humidity, and pressure data turn on and off the heating and cooling myself? I was planning to build my own thermostat some day so that I could do this, since I have never found a pre-built thermostat that optimizes along both dimensions of comfort and efficiency the way I believe it can and should. If your thermostat allows this then it would save me a lot of trouble.
Absolutely. You can write in python, javascript, bash, openHAB and mostly anything available for Pi. The 4 mentioned are only the ones we have used for sure.
last operating state > NO - Imaging having heating ON and getting a power network failure but you are leaving for a 2-weeks holiday. You wouldn’t want to get the heating started while on the plane. So on reboot, everything is OFF unless you have hardcoded it to start something as default.
But that is different from how traditional mechanical thermostats work. Imagine at the beginning of my 2-week holiday, my power went out for an hour and then came back on. If the heating does not resume automatically, then when I come home I will find my house flooded and my posessions destroyed because the water pipes burst because they froze because there was no heat to keep them warm. You are saying that in order for your thermostat to work like a traditional thermostat, I must change your code?
Not sure where you see that. There is no battery support. Pi even Zero is not really a battery operating board when we are talking on a 24/7 operation.
I marked up an image from your website. I guess they are things that look similar to a space for a 9V battery and terminals but are really not.
Yes I see your point though. I think we are facing the two sides of the same coin. There is an easy solution though. We can store the active state (and its temperature) whenever it changes (and clear it on a proper shutdown) and on boot read and apply these settings and state. Then on the UI there should be a button to choose what to happen when resuming from a power failure, ON, OFF or last state.
Never thought of that . This is the hole for the wires to come out from your wall to the HestiaPi. The picture you see is from the mains-powered model. The HVAC model runs of 24V AC and uses a different power supply with different PCB footprint. The unpopulated pins are for the 24V power supply.
MQTT does not know anything about the underlying system which is what makes it great to interface different systems. If you change ‘localhost’ to the IP of your system you can link them together. Make sure your topics (in the .things file) match though as this is equally important.
That’s was my assumption, thank you for clarifying! My last question hopefully, should I upgrade the MQTT binding from 1.XX to 2.XX? And is this setup through GUI or terminal? Thanks for all the help, I’ve been trying to get this up and running for a while now.
The latest release has version 2.4 for MQTT already. If you don’t use the latest release, I would advise you to do so as it has many improvements. I’m not sure it is advisable to upgrade just the MQTT especially as there are many changes. OH forum is a better place for these questions (and ready answers).
I’ve used the same image with no problems for testing. I just built my final product and booted the same image and I get this image. I can access via ssh and web ui, not sure what’s going on.
Did you run an update? The “loading” screen is loading the UI at the end in a frame. The loading screen is accessed as “file://” (webserver is not loaded at the very beginning) when the UI is “localhost” (OH fully loaded). Older Chromium browser had a flag we set on startup and ignores this warning. Newer Chromium (if you run an update).
See this Lcd boot page error
Yes, with different issues. Now, in the web ui I’m getting intermittent connection issues “waiting for connection” no temperature reading, and on reboot it’s stuck on loading at the HestiaPi screen.
I’m sold.
