Hi everyone,
I would like to migrate my heating control from its current platform to openhab. At the moment, it is implemented in Perl and works great! Well… after I stuffed some “leaks in my heating”… memory leaks 
. But the previous plattform is outdated and needs to go offline.
Concept used so far
The concept used so, I actually would like to preserve… below some details on it… it’s so cute and flexible 
at least from my point of view
Structure
As a basis one can define a structure the rules are applied on
- rooms (which basically are only containers) for …
- heating pairs as pairs of temperature sensor plus heater.
-
relevant windows and doors in the room that should not be open when heating is on
(heaters, sensors and doors/windows are refered to by their KNX group address)
# Room definitions (Default values)
$usage_conf->{ rooms } = [];
$usage_conf->{ rooms } = [ # Array of all rooms
# A first room
Wiregate::CrossPlugin::Room->new(
'EG-WZ', 'Wohnzimmer / Kueche', # id, name
[ '3/0/1', '3/1/1' ], # doors
[], # windows
[ # heating_pairs
# A heating pair in EG-WZ
Wiregate::CrossPlugin::HeatingPair->new(
1, WG_HT_FLOOR, # id, type
'1/2/23', '1/4/6', # temp_sensor, heating
-0.4 # offset to default temperature
),
# A second heating pair in this room
Wiregate::CrossPlugin::HeatingPair->new(
2, WG_HT_RADIATOR,
'1/2/20', '1/4/7',
0 # no offset used here
)
]), # End of room "EG-WZ"
# ....continues with the other rooms....
Rules
On top of this one can define heating rules with the following features / attributes:
- temporal scope: active from and to (relative to either recurring events like a wake up time or an absolute date-time)
- priority: using a number to resolve rule conflicts
-
affect on heating pairs (i.e. what to change)
- by referencing any number of rooms and/or heating pairs via string matching these can be selected
- an abolsute or relative temperature change can be applied
# A rule (heating extension)
Wiregate::CrossPlugin::HeatingExtension->new (
'SwitchOff', 'Alles (fast) aus', # id, name
# Note that the month starts with 0 (i.e. substract one...
WG_RT_SPECIFIC_DATETIME, timelocal(0,0,8, 19,3,2019), # active from
WG_RT_SPECIFIC_DATETIME, timelocal(0,0,9, 27,3,2019), # active to
[
# change temp for all heating pairs in all rooms to 17 degrees absolute
{ room => '*', hp => '*', temp_abs => 17 }
],
100 # Priority 100 (rather high)
),
# A second rule - with relative time to a recurring event
Wiregate::CrossPlugin::HeatingExtension->new (
'Nachtabs', 'Nachtabsenkung', # id, name
WG_RT_GODNIGHT_TOMORROW, -30, # from ref, offset mins
WG_RT_GETUP_TOMORROW, -45, # to ref, offset mins
[
# Changes applied to specific rooms and heating pairs with
# different target temperatures
{ room => 'EG-WZ', hp => '*', temp_abs => 20 },
{ room => 'UG-KO', hp => '*', temp_abs => 19 },
{ room => 'EG-AZ', hp => '*', temp_abs => 20 },
{ room => 'OG-BA', hp => '1', temp_abs => 21 },
{ room => 'OG-BA', hp => '2', temp_abs => 21 },
{ room => 'OG-KN', hp => '*', temp_abs => 20.8 }
], # array of changes
0 # Rather low prio
),
# More rules follow ...
Furthermore
- the system can turn off the heating, when relevant windows or doors are opened. And obviously can turn them back on again when they are closed again.
- can react on changes of items (here: KNX group addresses) instead of iterating over everything every minute
How to move to Openhab
I used (Perl) classes when implementing this, which to me looks like a good way to ease the implementation. Actually, I would have preferred Java but that was not available 
.
So far, I setup my openhab and had it running for some time now. I applied a number of rules that work as expected / I’m happy with. Ok, I admit that I could just write some 100 lines rules code with all this factored out (i.e. no config files, all coded out, etc.), but this does not feel right (do I sound nerdy…?). And I would love to preserve the flexibility I had so far. And who knows, maybe someone else can make use of it, too…
From what I understand, I need to implement automation modules (https://www.openhab.org/docs/developer/module-types/).
And now my (first?) questions…
- I haven’t found a ready-made piece of software for this, so I strongly assume there is no out of the box solution… (that’s why I post it here)?
- Is the automation modules the right point to start?
- Cutting the config into pieces and defining how to configure things seems to be a tricky part. Is it possible to use nesting, arrays and hash maps in configs (in the tutorial, it does not look like it… https://www.openhab.org/docs/developer/module-types/#module-type-provider)?
- The new piece of software would hook its trigger-condition derived from the read configuration into the rules engine using programmatically created rules, I guess (cf. https://www.openhab.org/docs/developer/module-types/#programmatically-define-rules)?
- But how can I resolve rules conflicts (priorities)?
Hoping for some hints & examples so I don’t stumple to far around… 
Thanks!
BR,
Alex
). It actually took some time to get back to this and make some progress, but now, I have a first version ready. 
