I’m looking to design a thermostat that can control cooling based on some function of dew point. The idea is in the summer, 76 might feel cold if the humidity is low while 73 might be hot if the humidity is high.
Can anyone give some insight as to how hard it would be to modify the Hestia logic to cool based on dew point instead of temp?
Any other thoughts on this idea or why it wouldn’t work?
Thanks,
Yeah, this should work just fine. There are a couple ways you could go about it, but it should just be a matter of updating a little JavaScript or Python code or a shell script.
The first option is to change the rule that controls when the HVAC comes on to calculate the dew point and make its decision based on that instead of just the temperature. The only thing that might be a little strange about this approach is that the temperature will still be the thing displayed on the screen. So you may see the air conditioning turn on before the temperature gets above the cooling set point.
You’d need to change the “Heating/Cooling Check” rule in OpenHAB to calculate the temperature delta (from set point to actual temperature) to be based on the set point and the dew point. I see in other places the humidity is accessed via items["MyHumi"], so that should help get you pointed in the right direction. You may also want to know whether the temperature is in Celsius or Fahrenheit, which should be in items["TempUnit"].
The other approach would be to replace the temperature with the dew point. This has the advantage of having the screen show the current dew point instead of the current temperature. It’d be a little more intuitive to see the set point and the dew point on the screen since these are the numbers that are determining when the HVAC turns on. On the flip side, it means you’ll never be able to see the actual temperature.
It’s been a while since I looked at it, but I believe the script that gets called by OpenHAB is getBMEtemp.sh, which gets the information from bme280.py. If I’m wrong, then it might be calling bme280C.py or bme280F.py instead. I always get confused about why there are extra files there that are not used.
At any rate, the point is that if you just have the script calculate the dew point and print that out instead of the temperature, that will also have the effect you’re looking for.
As a side note, you could also consider using the Heat index which was developed to measure human comfort level instead of calculating when water will condense.
Just go with whatever you are… comfortable… with. 
Thank you for such a well thought out answer and I like your idea of using heat index as an alternative.
Is there a current build list? - I thought I had found one at some point but I can’t seem to find it anymore.
Section 6.2.1 of the owners manual has a Bill Of Materials (BOM) with links to where you can buy the parts.
I just went through all the links and it looks like there are a couple I need to update.
For the solid state relays, I can attest that the Panasonic AQG22205 are a compatible replacement.
The sensor that is linked to is a BMP280 instead of a BME280. Either will work, but the BMP280 does not have humidity sensing. On the other hand, it’s also far cheaper than the BME280. If you’re calculating the heat index, obviously you’ll need the BME280.
Finally, while the extra long headers from AdaFruit do work, I’d highly recommend getting these ones from Mouser instead.
Oh, and you can use a Raspberry Pi Zero 2 W instead of the original Raspberry Pi Zero W. The Zero 2 is the same price, will boot faster and be more responsive when using it, but the reset button won’t work because they replaced the reset pin with a reset pad. You can reset the thermostat by just flipping the HVAC breaker off and back on, but if you really want that reset button to work, you can use this pogo pin to make contact with the pad.
I’ll work on updating the manual to better document the make and model of part (for parts that have that info) and update the links to the improved parts. Thanks for asking the question that got me to notice the docs being out of date.
The way the rules switch between degrees C and degrees F is by changing out which of those scripts get called. OH is configured to call getBMEtemp.sh. But when you change the units it actually replaces that script with the appropriate C or F version of the script. So only one is used at a time but all three are needed to be there to change between units.
Long term I had plans to rework that stuff to use UoM in openHAB instead but needed a newer version of OH to really make the changes in how it works worth while. The default version of OH 2.4 had some bugs (a couple which weren’t fixed until OH 4.0 really).
@Peffersp, if you’d rather do it in JS the rule to do it in would be “Process sensor changes” I think.