Issue of the topic: rules creation for ventilation variation depending on temperature/weather/forecast
Hi,
In my house I have a dual-flow ventilation system which allows me to heat-up or cool-down the incoming air using the calories of the outgoing air.
The first rule I have created is basic and look only into the inside and outside temperature:
rule "Ventilation flow depending on temperature"
when
Item Ventilation_extract_temp changed or
Item Ventilation_input_temp changed
then
if (Ventilation_extract_temp.state > Ventilation_input_temp.state){sendCommand(Ventilation_airflow_setting,100)}
else(){sendCommand(Ventilation_airflow_setting,50}
end
The second approach I have looked into is using a defined setpoint for each parameter important and associate a flow value. For example:
Limitation of this is the need to create many lines for each change of condition… So it leads to a rule with too many lines and something which is not easy to modify/improve.
So I have been looking at a way to make a rule with the following design
flow setpoint defined by the product of coefficients (for example inside temperature will have higher impact on the flow than the outside temperature) and a base flow
variation depending on the season (needs to heatup as much as possible in winter, but cooldown as much as possible in summer)
setpoints defined by items which can be modified by user without touching the rule
implementation of hysteresis
take into account the 3 days weather forecast (not to cooldown the house too much if the weather is changing the day after)
List of items which can be used in the rule are:
Ventilation_airflow_setting //current air flow setting
Ventilation_extract_temp //Temperature of air extracted by the ventilation
Ventilation_input_temp //Temperature of air input from ventilation
Temperature_livingroom //Temperature in the livingroom (ideally between 22 and 25°C)
Humidity_livingroom //Humidity in the livingroom (ideally between 30 and 55%)
CO2_salon //CO2 level in the livingroom (Should be lower than 2000, ideally lower than 1000)
Temperature_max_day1 //Forecasted max temperature day +1
Temperature_max_day2 //Forecasted max temperature day +2
Temperature_max_day3 //Forecasted max temperature day +3
Temperature_min_day1 //Forecasted min temperature day +1
Temperature_min_day2 //Forecasted min temperature day +2
Temperature_min_day3 //Forecasted min temperature day +3
Weather_station_solar_radiation //sun intensity
Night_mode //night mode (if night mode on, maximum ventilation flow is reduced)
Switch_away //Out of home switch (if away ventilation can be reduced)
Blind_livingroom //Is now used in a different rule to reduce the sun heat entering the livingroom
Of course I am not asking for someone to write this rule, but any directions or general writing recommendations will be welcomed.
Yes, there is a lot to do and which could make a big difference on the overall confort of the house.
So with your approach should it be one rule for each module/categories? Or still keep it all in one rule?
And if it is different rules managing it all, how to make sure that there are not several rules reacting to same conditions but in different directions?
I’ve no idea how many rules you should have. you are almost certain to run into disaster trying with one mega rule.
I cannot teach the art of design, but I think you should be looking for abstractions.
At its simplest, you might create ‘demand’ virtual Items with choices 'heat/cool/do nothing" , “lots/middle/little”
A thermostat rule acting on temperature changes might modify the basic function. "It’s above 23C, cool’
A rule acting on weather forecast might modify the how-much. “We’re cooling now, but it’s forecast cold, so only do a little”
A device controller rule acting on demand changes might issue the actual instructions. “Turn on chiller. Turn on fans at level 3”
It’s a complex system, but you can build it in chunks. The hard part is getting your ideas into workable processes. Making a clearly defined process into rules is the easy part.
I understand your approach and see how it could make it easier to manage.
However, I have only one output, i.e. the ventilation flow setpoint anywhere between 20 and 100%.
So heating and cooling is done the same way, by increasing the flow when outside temperature allows.
I’ll second rossko57’s suggestion. Don’t try to do it all in one Rule. Break the problem up into parts and implement a Rule or Rules for each part of the problem.
Look at the https://community.openhab.org/tag/designpattern posts. There will likely be a number of approaches there that might make solving each part a little easier and/or maintainable. I suspect use of separation of behaviors, and perhaps a state machine would be applicable.
Use Groups where possible. For example you can replace
Group:Number:MIN MinTemp
// in the Rule
if(MinTemp.state > 26
You have MIN, MAX, AVG, and SUM available for numbers. You can simplify a lot of comparisons in this way.
Start small and get something very basic working. Then gradually add new features. For example, I wouldn’t try to add in forecast until last.
The Astro binding should tell you the seasons. Hysteresis is simple enough.
I’d consider looking into implementing something like this using Jython rules. If you do than there is a lot of code out there already that you can leverage without needing to copy/paste/edit. For example, I have a hysteresis implementation in https://github.com/rkoshak/openhab-rules-tools as well as most of the existing design patterns. There is also a generic implementation of a state machine among the design pattern posts.
