Use without OpenHab and Mosquitto?

I’m finally getting around to adding some humidity management to my HestiaPi Touch ONE. I’ve got Relay4 wired up to my remote valve so that I can dynamically run my chiller loop across my coils and now I need to work on the software. I understand how to get into the OpenHab setup and start creating what I need, but want to simplify if I can. It would be different if I used the other features, but this is just for HVAC control - no other smart devices in the home. I want to make it as simple as possible. So can I just shut the other services down and write my own script to manage things? Is there anything special to setting the GPIO pins on/off to manage my relays? https://learn.sparkfun.com/tutorials/raspberry-gpio/all shows sample code like:

>>> import RPi.GPIO as GPIO
>>> GPIO.setmode(GPIO.BOARD)
# Try to turn on my fan
>>> GPIO.setup(18, GPIO.OUT)
>>> GPIO.output(18, GPIO.HIGH)

Thanks for any advice.

That does not sound right… Mind sharing a video or something to get better help identifying the issue?

Yes, you can shut down OpenHAB, Mosquitto, and/or kweb (which is what provides the UI on the LCD screen) if you are going to be writing your own control software.

How to control the relays will depend on what version of a kernel you’re using. The older versions allow controlling the relays from /sys, but the newer distros don’t (they have a new system to deal with them). As long as you (or the library you’re using) is controlling the relays in a way that is compatible witb your kernel, you should be good to go. There’s no special requirements for our hardware.

I’m not sure what hardware you’re using, but if you have the original Pi Zero W, you might want to consider upgrading to the Pi Zero 2 W. All units can be upgraded, but the original HestiaPi ONEs from the crowdfunding campaign will require desoldering the pi. Later revisions made the Pi a socketed component for easier upgrades.

The biggest performance stress is the limited amount of memory available (512MB). If you don’t need the UI on the LCD, disabling kweb will relieve a lot of contention for memory. I can’t quantify how much faster it will reboot since I’ve always maintained support for the LCD UI in all my builds. It still won’t be an instantanious boot up, but it might let you keep using OpenHAB for the controls without any of the issues you’ve reported with the system locking up. It should also make the OpenHAB web UI more responsive.

I can tell you from first hand experience that the rules are more complicated than they first appear when you get into fan control, boost mode, comfort vs eco mode, stage 2 heating, a possible delay on said stage 2 heating, and so forth. There’s a lot there. If you don’t care about all of that, writing a replacement will be much easier!

I’m sorry to have added that remark on performance when I wasn’t prepared to detail and debug it. I retract it.

No worries. We are here to help either way.

One tip we have seen many times is that a low quality SD card can cause very strange behaviour including the symptoms you are seeing. A low-effort attempt is to move to a new good quality SD card (Kingston is usually a good enough one) and leave it running for a month or so. If you stopped seeing issues, maybe that was it. Otherwise come back here with more info.

The Hestia32 may be a good fit for you when it is out in a few months.