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