Remote sensor HestiaPi Classic

Customization
1

As mentioned in How to access the MQTT data thread, I’ve got a remote sensor (Sonoff TH10) in place for reporting temperature. The next step is to decide how to use this with Hestia itself. I’m presenting my current plan, but I’d love some feedback :slight_smile:

So HestiaPi Classic doesn’t have any knowledge or understanding of additional temperature sensors (otherwise this feature request wouldn’t be a thing :wink:). My plan goes like this:

Data input

  • The TH10 reports temperature every 5min via MQTT
  • Thanks to my Hestia MQTT project I have a similar reporting interval on the Hestia itself.
  • OpenHAB can boost the heating via the Hestia MQTT interface
  • OpenHAB is the central brain for this approach

Controlling heating

  • Disable all schedules on Hestia - heating is now controlled only by the “boost” command from OpenHAB
  • OpenHAB can trigger a rule based on a change of either temperature sensor value
    • Must investigate sensor ‘item’ grouping for OpenHAB to make it easy to extend
    • Per-sensor set-points will be doable, but probably in a second round of hacking :stuck_out_tongue:
  • The rule will send a 15 minute boost if the temp is too low
    • Consider requiring it to be at least 1C below target to avoid on-off-looping
  • Since sensors report every 5 min, this will keep the heat on until the desired temp is achieved
  • For cooling (I have no AC) this means the heating won’t stay on for hours when not needed

Controlling water

I have a well insulated storage tank, so I’ll probably just leave the water relay on 24/7.

Thoughts? I think this will work, but perhaps there’s better ways :slight_smile: ?

2

First off…
You can modify most Sonoffs once they run Tasmota to connect to temperature and humidity sensor components (DS18B20, DHT11/22, BME280 and many more) and report back via MQTT their data to whatever IP you have setup as your broker (aka server) like HestiaPi. So you don’t to buy the specialised TH10 model if you already a basic unit, but it does provide a 2.5mm jack ready for connecting your (I think DHT22) sensor.

The “1’C” is basic way of hysteresis and you can actually have a switch item in OH2 with 2 values, 1 and 2. According to the value of the switch the value of hysteresis can change from +/-1 to +/-3. This is equivalent to the “Comfort” or “ECO” mode most modern thermostat offer these days and it will affect how soon your heating will be turning back on to re-heat your home. The actual hysteresis data is a feedback mechanism that learns, at least for radiant heating, how much more heat will be dissipated in the house and for how long after the heating is turned off so it takes that into account too towards setpoints… This is also something doable and maybe some OH users have already done it making it very easy to inherit in your system.

To your real question…
My plan is pretty much like yours with 2 additional details. Multiple setpoints make no sense if you cannot control the heating in each room independently, like stopping the heating in Room A because setpoint A is reached but keep furnace on for Room B whose setpoint is not reached yet. If you cannot stop the heating independently you, one of the setpoints will always be ignored. So my plan is to have a group of external sensors where only 1 can be active and respected at a time (or maybe all active for monitoring but only 1 active). This ext sensor’s data will be displayed on LCD/Web/App too.
My second personal touch is to actually have only 1 external temperature/humidity sensor which should be small and portable (battery operated). It should attach magnetically on the main HestiaPi unit where it will recharge wirelessly and its presence or not will programmatically control the value of the switch I mentioned above (with option to manually override). So once you remove the ext sensor from the main unit it will become the master sensor and it will give control back to the internal sensor once returned to charging position.

3

Yeah, I saw you can solder it on, but I’d already bought a TH10 with an AM2301 temp/hum sensor :slight_smile:

Oh, that’s a nice idea, I may implement that. For now a simple hysteresis will do though.

That’s true, but sometimes it’s OK to ignore a setpoint, and sometimes a specific room leaks heat more than others. In my case, I live in a cold place, with small children, and so I’ll want to be sure that their bedroom is warm enough overnight, even if that means it’s way above the other setpoint elsewhere. In other words, I’ll be ensuring $temp >= $a && $temp >= $b.

Furthermore, this can be customized by time. In this example, I only care about B during the night (children are elsewhere during the day) so the rule can be made more complex: if $time in $night_hours ($temp >= $a && $temp >= $b) else ($temp >= $a)

Also, iTead have a controllable motor, which is supported by Tasmota, so theoretically you could create motorized radiator valves which are controllable… but I have no plans on that just now :stuck_out_tongue:

There’s more you can do - motion sensors, light sensors, even on/off status of lights could be worked into deciding whether to honour a setpoint in the heating rule. OpenHab is great :stuck_out_tongue: and I’ll share my rules once I get them set up.

Oh that’s nice, good move!