Automation engine: Rule templates

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

2 Likes

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.

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?

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).

Ok, so above my pay grade :slight_smile:

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