I would like to get rid of the web interface to solve the delay problem. I don’t need so many options because I’ll control my HestiaPi from smartphone app, only ON/OFF options (I still don’t understand how BOOST mode works) and Temp./Humid. reading/setting. I found a convenient python class to send openHAB messages (sorry for bad terminology, I’m still new to this world) and I know I can build a simple GUI app in python. Easy!
The GUI app I wrote is not showing up, I think because another GUI app is working: it’s the “OS”, the one that make Chromium appear on display. I think I can detach an app from screen (or terminate it) and start my own, but I’m not sure how this can be possible.
If someone have information about this topic and want to contribute, maybe I can speed-up the development. I’m going to do research by myself.
Thanks in advance.
Ok, I found a solution here:
And remember to change the color of your string to a color different from the background or you won’t see anything!
Sorry to alert the forum for nothing, but if you have suggestion, you are welcome!
This script is the “Loading” screen you see after boot and before the actual GUI loads.
With the help of
it is checking if OpenHAB loaded completely and redirects to:
which is the actual HABPanel GUI.
HABPanel is an easy way for people to modify with drag and drop the LCD GUI. It is heavy and runs “only” on Chromium. If your solution is not web-based getting rid of Chromium and HABPanel will speed things up.
Boost is like a sleep timer. It is turning ON the respective function (say, heating), starts a countdown and turns it OFF at the predefined period.
This is a good starting point, thanks!
I manged to start my app on top of Chromium. I can see the result, but I’m not able to terminate a python3 app, nor come back to Chromium. Do someone knows how to kill python app with a CLI command?
I started building my GUI with ZEROGUI, but I discover is a library written for children (and if you see the result, you can guess it!). Plan to switch on a tkinter GUI for a more professional result.
Added a slider to set temperature and checked the responsiveness of the system. It’s good, but not excellent. May be I need to top some app in the backround to have a better result.
I’ll keep you update.
If you don’t kill Chromium behind it you are wasting too many resources. From the previous script, run this line over SSH:
pgrep chromium | xargs kill -9
and carry on with your GUI. Just by doing that, do you see a difference in responsiveness?
I changed something in the code (dropped zerogui in favour of tkinter) AND kill chromium, so I’m not sure who made the actual responsiveness so good, but it’s good enough!
At this point I can read the room temp. and print it in a text box. Even the temp. setpoint slider is working well and now it’s time to start thinking about HOW the new interface will LOOK.
I would like to have feedback from other users. A little modification will not involve so much work, so if someone have an design suggestion, please let me know. My original plan was to let everything as simple as possible like the openhab interface, but only in one page for the HEAT function.
Please let me know what do you think will be indispensable and I’ll evaluate it.
This is the other alternative solution done so far:
Note the alternative software, IOThermostat, was modified to work with OpenHAB by @Greylinux. Or if you think that’s too much still, you could send in MQTT commands directly with MQTT Dash Android app for example, which I suppose works for both types of install.
I didn’t find the time to investigate, but it seems to be another web-interface… I should investigate also the openhab / Mqtt thing I didn’t understand very well.
My plan is to send the same http command the hab panel sends, but using a non-web interface. Do this make sense? Is the same thing IOthermostat is doing?
FYI Both HestiaPi and IOThermostat installations use MQTT for communication/control. OpenHAB can use MQTT as well.