Automation engine: Rule templates


(David Graeff) #1

Hello fellow developers,

I have put some thoughts into the distribution of rules, rule templates and came across one question.

You can define composite module types. A powerful concept actually, for example it allows simple branching in a rule. Self defined composite module types are quite interesting for distribution next to rule templates, or, as I suggest with this post: Inside of rule templates.

What is a module type? Any trigger, condition, action that you can select for a rule (“Trigger on fixed time of day”, “Execute other rule”) is a module type, that is either provided by openHab core or by an addon.

A composite module type is a declarative (no programming involved!) composition of multiple (programmed) module types and defines its own configuration and inputs and outputs.

Example:
You can have a composite module type “MQTT Shelly Button” that requires a broker thing to the set as configuration and internally wraps the core.ChannelEventTrigger and core.GenericCompareCondition to output ON/OFF on a “button1” and “button2” output. No programming involved at all.

My proposal is this: Let’s add a “moduletypes” key to the rule templates structure. Those found module-types are installed when the rule template is installed and can be used in any rule from there on.

Implications: A user must be able to remove composite module-types from his system again. (The REST API needs some extensions)

WDYT?

Cheers, David


(Łukasz Dywicki) #2

I would put idea even further - why not having “virtual things” / switches / relays whatever as first class citizens? Why do we need a rule to have lights switching when sun goes down and turning it off when it goes up? Its a dumb scheme astro event + output. I get that rules got accepted in community, but do they rule everything?
Why for example we can’t have a virtual thing / item / channel whatever which would calculate a hourly/daily/monthly/yearly consumption from some increasing value. A basic example a electricity consumption today is consumption from today 00:00 minus consumption from today at 23:59.

I can keep going on it and ask why each and every binding have different way of handling a “lastUpdate” channel as it couldn’t be automatically tracked at core level. Sorry, that’s different thread.


(Michael Cumming) #3

Its hard to rule templates if we do not have a well designed of Ontology of devices and locations (as we have discussed before). I agree with @splatch, and I have mentioned it before, what should be a simple task -> turn on front porch light at sunset and turn off at sunrise is a very complex process in OH.

@David_Graeff, I don’t really understand the idea of module types?


(David Graeff) #4

This is actually a very technical topic :slight_smile:
You need to know a bit of the code base and about the automation engine (New Rule Engine) and then you would know what module types are.

I don’t want to talk about theoretical topics here, but about the existing code and how to extend and distribute “Rule templates” (again something that is defined in the core).


(Michael Cumming) #5

Ok, so above my pay grade :slight_smile:

I would be interested in reading through the code - link?