Turn heating on for one hour - parallel to manual

Setup, Configuration and Use Scripts & Rules
1

I’m wondering if there’s a better solution for this.

I have an workshop outside in which I do store some sensitive stuff. So I want the temperature inside to be above 5°C, if possible. So, I’d write a rule, which triggers heating = "ON", if the temperature drops below 5°C and stops, if temperature is above 10°C.
So far so good.

But if I’m inside working, I’d like the temperature to be 20°C. :wink:

So, I’d trigger a “automatic heating”-item and let the rule decide, whether automatic is ON or OFF, so the rule can distinguish between a heating = "ON" triggered manually and the one triggered “automatically”? Or is there some other magic trick possible to avoid having loads of “automatic”-proxy items?

1 Like
2

I think I miss your point.

but you ‘just’ need to distinguish about ‘your’ presence within the workshop or ‘your’ manual mode within the heating rule?!

3

use cases in short are:

  1. keep workshop above 5°C at all times (and stop at 10°C)
  2. keep workshop around 20°C, when heating was manually started (in that case: don’t stop at 10°C)
4

In the upcomming 5.1 release there will be possibility to get to the source of the event that triggered some action. So you will be able to distinguish if some command is triggered by another rule or if it comes from UI.

Here an example (first command from my testJsRule and second from MainUI):

[openhab.event.ItemCommandEvent] - Item 'TestSwitch1' received command ON (source: org.openhab.automation.jsscripting$rule:testJsRule)
[openhab.event.ItemCommandEvent] - Item 'TestSwitch1' received command ON (source: org.openhab.ui=>org.openhab.core.io.rest$admin)

I don’t know which Automation language you use for your rule, but for example in javascript scriptiong you can check the documentation for event object here (look for eventSource):

1 Like
5

How I would do it is with a rule that triggers on changes to the temperature and changes to the automatic heating Item.

if the auto heating item is ON set tgtTemp to 20
if the auto heating item is OFF set the tgtTemp to 10
If the temperature < tgtTemp - 5 turn on the heater

const currTemp = items.WorkshopTemp.quantityState;
const tgtTemp = (items.AutoHeating.state == "ON") ? Quantity("20 °C") : Quantity("10 °C");

if(currTemp.lessThan(tgtTemp).subtract(Quantity("5 °C")) items.Heating.sendCommandIfDifferent("ON");
if(currTemp.greaterThan(tgtTemp)) items.Heating.sendCommandIfDifferent("OFF");

The only tricky part is managing that heating Item. I’d do that from another rule. I assume you are using motion sensors or something like that. But every time the temperature changes or that heating Item changes the rule will trigger and figure out whether it need to turn the heater on or off and send the command if needed.

The logic that controls the heater doesn’t really care what triggered the rule, just the current state: current temperature and your presence.

You could even further simplify this by having a target temperature Item and instead of using an auto-heating Switch Item, just set the target temp in an Item based on the same logic you use to set that switch. The only difference is you’d use 10 °C for OFF and 20 °C for ON.

Then the logic of the controlling rule just becomes:

const currTemp = items.WorkshopTemp.quantityState;
const tgtTemp = items.WorkshopTgtTemp.quantityState;

if(currTemp.lessThan(tgtTemp).subtract(Quantity("5 °C")) items.Heating.sendCommandIfDifferent("ON");
if(currTemp.greaterThan(tgtTemp)) items.Heating.sendCommandIfDifferent("OFF");
1 Like
6

I do something similar with my landscape lighting, turning the lights on or off based on a value from a light sensor but allowing an override on the sitemap. This might be a good starting point for your use.

Items

Switch LandscapeIlluminance "Landscape Illuminance %s" {channel="weatherflowsmartweather:tempest:HB-99999999:ST-99999999:illuminance"  [profile="system:hysteresis", lower="1000 lx", upper="4000 lx",  inverted="true"]} 
Number LandscapeOverride "Landscape Override"

Sitemap

Switch item=LandscapeOverride label="Landscape Lights" mappings=[0="Off", 1="On", 2="Auto"]

rules

// When the system initializes default LandscapeOverride to "auto" and 
// gLandscape based on the value from sensor's illuminance 
rule LandscapeInitializeRule
when System started
then LandscapeOverride.postUpdate(2)
	 if (LandscapeIlluminance.state == ON) {
	 	gLandscape.sendCommand(LandscapeIlluminance.state.toString)
	 } else {
		gLandscape.sendCommand(OFF)
	 }
end

//  Turn the lights on or off based on the sensor's illuminance only if in "auto" mode
rule LandscapeIlluminanceChangedRule
when Item LandscapeIlluminance changed
then  if (LandscapeOverride.state == 2) {
   	   gLandscape.sendCommand(LandscapeIlluminance.state.toString)
	 } 
end

//  Turn lights on or off based on the sitemap's override switch
rule LandscapeOverrideChangedRule
when Item LandscapeOverride changed
then if (newState == 0) {
	    gLandscape.sendCommand(OFF)
	    return
     }
	 if (newState == 1) {
	    gLandscape.sendCommand(ON)
	    return
	 }
	 // newState == 2 (auto)
	 gLandscape.sendCommand(LandscapeIlluminance.state.toString)
end
1 Like
3 state switch
7

Thanks for all the answers. Great stuff!

I guess I wait for 5.1 and try the “where did it come from” eventSource. I’m using JavaScript, so that should be easy.
And also Rich pointed out, that the need for an “override”-proxy-item could be avoided, if I used the “targetTemp”-value. If it’s > 10, it would mean: manual trigger, if it’s 10, then automatic.
(only thing is, the AC I installed in the workshop only allows upwards of 16°C. That’s why I need the “if it’s 10°C, stop heating”-part in my rules.
so I guess it’s still a proy-item at least for “targetTemp”, which is NOT the targetTemp of the AC unit…)