OpenHAB has a simple rule language. Thats fine. But for complex scenarios, i would like to abstract my logic into objects. Having a base class Room and extending specific Rooms from it, would allow reuse of rules in multiple rooms. everyone knows that OOP has its advantages, so if i want to write my rules in OOP, how can i do it?
the openhab rules language does not support OOP?
using the MQTT plugin could be one solution to this?
or creating an custom java plugin for your rules?
more ideas?
Note that the JSR233 binding that @steve1 points you to does not yet work in OH 2. I hope progress is being made.
Indeed. It also has its disadvantages. And except for the very valid argument that “it’s what programmers are familiar with” I’m not convinced it is necessarily a superior approach for event driven systems like OH’s existing Rules DSL (or Asterisk, or Freeswitch, or Tasker…there is a reason the telecom industry invented Erlang). Notice I’m not saying the Rule’s DSL is superior itself.
I would like to understand what you are trying to abstract though. I’m not really seeing anything in my or other’s home automation examples that would lend itself to a “Room” base class that would really add anything. Every room seems to be different. I love hearing about different use cases though.
There are other ways to organize one’s Rules though and I might suggest an organization (OO or otherwise) based on functionally rather than physicality. Instead of having a Room and extending the Room, why not a Lighting and extend that for each of your Rooms? I have found this approach allows for the most amount of reuse in the Rules language as it exists now and suspect it would work well in other languages too. Largely this is because Rules that need to do similar things end up colocated and can leverage the same constructs. Finally it lends itself more to consolidating some of the more abstract things like Time of Day and other state machines.
Ultimately, if OO is the way you absolutely want to go, the JSR233 binding is the answer.
Glad you are asking 
. i dont think my idea is completely new, so there may be already something i could build on. also, i would like to hear your feedback. excuse me if there is already something like that in development. i used OH 1.8 before and iam not up to date with OH2 development.
All lamps i have in my house are hue compatible and i was planning to smart control them. i was thinking many days about how to make my existing light switches smart, so they could react differently in the morning (white light), evening (warm white) or night (dimmed) and depending on the type of room and the activity in it. then i realized: in a smart home, what do i need light switches for? the new plan is to create a system that is so smart, it manages all lights by itself an no one needs to touch a switch just for having some light. i want to use motion detectors to decide, which lights to turn on. but the motion detectors need to be much smarter than the regular switch-on-motion-and-stay-for-3-minutes ones.
i have a hallway that connects the livingroom with the bath. if people are in the living room, the system should keep the light on the hallway on but dimmed down to 10%. (its a smart led lamp anyway, energy usage at 10% is very low). when someone enters the hallway, the system should turn up the hallway lights to 50% and turn the light of the bath from 0 to 20%, as someone enters the floor coming from the living room, its likely that he also goes into the bath. if he really enters the bath, bath lights go up to 100% and floor light stays on 50% for some time, as its likely that the user is in the bath only for 1 to 4 minutes. if he stays longer (not using the toiled but taking full bath) the floor light can dimm to 10% over time).
the key part on this is to have a good presence detection. the system needs to know where people are in the house and where they (most likely) move to. presence detection can be made by only motion detectors, by the “find” tool for wifi positioning, by door/window contacts or by devices (television) used and more. a system like this is very complex and would be even harder to create and maintain using the stock OH rules.
after thinking some days about this, i also think that there is a other problem with OH and its rules. or at least an area that can be improved a lot to make peoples homes smarter and easier to setup. OH does a great job with its easy initial setup, its bindings and their configuration. but when starting to write rules, i realize that writing rules is often not so easy as it seems. people start with easy “if this than that” rules and possibly end up with something close to the the “Mother-of-All Light-Off Rules”. so my conclusion on this is, that simple rules are easy to write for everyone, but really smart rules require a lot of skill and time to create. more than you can expect from the most people i know that use OH. having a lot of sample rules helps here, but one still has to understand how they work.
coming back to my auto-lights example from above, i also think that if i put days and weeks into creating such a system, it should be reuseable by other users. so instead of writing rules for my devices, i would like to abstract the rules away from the actual devices and their capabilities, so everyone could use and improve the logic i have created.
i could imagine this: after installing OH and setting up bindings, a user is asked to tell OH how his house looks. so what rooms are there, how they are located to each other and which device is within which room and so on. this configuration can be very advanced to reflect the real world best as possible.
after that, you can install “skills” (yes, the term from alexa, but i like it as it fits good in this case). i.e. there could be a “auto-lightning-skill” that does what i described above. the skill reads the configuration of the house, so it knows which motion sensors are in which room and which lights it needs to connect to. there can also be a “presence-detection” skill by itself, that just utilizes all available devices to detect presence in the rooms and be used by other skills.
so instead of writing rules myself, as OH user, i can install a skill that, kind of, creates the rules for me.
and as the skill is abstract logic, other developers can easily contribute to the skill, no matter what hardware they use.
other possible skills are light-switch-skills, window-contact-heating-control skills, washer-is-done skills, smart-doorlock-skills and so on.
people then can see “oh, there is a washer-is-done skill, i want this, what kind of hardware to i need to have it working?”. so non-coders should be able to have a smart house with nice skills without touching code or worrying about how it works from the Item/Value point of view. the skills can also have their own config options to adjust it to the personal taste of each user.
what do you think about this idea? Its basicly “abstract the logic from the devices/Items” and “create an appstore/repo for it”.
my initial question was a bit missleading. i do not really want to make rules OOP, i dont want to write classic rules. i would like to create a more complex processing that reads and pushes events by itself.
Again, I recommend you consider the JSR223 interface for OH1 (PR of OH2 version of JSR223 is being reviewed now). I don’t know if you looked at the link I posted, but it allows you to write scripts to control and extend OH using languages like Python (Jython), Javascript and Groovy. I use JSR223 with Jython and I’m able to package my automation functionality into reusable, parameterized components. Several users in the forums have also reported significant performance improvements after switching to JSR223 Jython from the Rule DSL.
For home automation the primary need is event processing. Sometimes that means triggering actions from events. Other times it means doing event data processing (correlation, filtering, persistence, statistical analysis, etc.). I think the Rule DSL is an awkward and inflexible way to implement this type of functionality. Languages like Jython allow you to create your own event processing DSL. For example, you could use Python metaprogramming techniques to define classes where the methods are triggered by events. This could be implemented by generating “rules” or it could actually process events directly from the OH event bus and bypass the OH rule engine altogether. In many cases you can even bypass OH bindings and “virtual items” and directly process events from sources like HTTP, TCP, UDP, JMX events, subprocess execution, filesystem changes and so on using a JSR223 language’s libraries. It’s also possible to integrate advanced functionality like the Esper Complex Event Processing framework or the Apache Camel framework.
Thanks for the Answers. JSR223 sounds indeed like what i was looking for, and i did not know about it before. i will take a deeper look into it and test the PR on OH2.
rules-ng: i did see this wiki page, but it did not tell whats different with rules-ng. reading the forum post, it looks like its indeed a abstraction of rules from devices archived by templates. it also states that its possible to write scripts or use some kind of modules for advanced functionallity, but i am not sure yet if it is what i am looking for.
what do you think of the idea (i wrote above) to define ALL important facts of the house (floors, areas, rooms and devices in rooms, location of rooms, type of rooms, …) in a central configuration, so that modules can use this to apply logic to the house/rooms?
i.e. a window-contact-heating module (which turns the heating off if the window is open) could look up all rooms that have window contacts and heating control in them and apply rules to them automatically without having the user to explicit configure each room. the module could automatically handle multiple window contacts and heating devices with zero configuration of the module itself, just with the central configuration that draws some kind of “map” of the house that tells it how items relate to each other. this specific example could possibly done with item groups, but very limited.
I like the idea of a home/environment model that is more detailed than hierarchical groups of items. Unfortunately, since most rules operate on items you’ll need to define the items for the generated rules. In OH1, I haven’t found a way to do this from a script. You may need to dynamically generate items files as a workaround. In OH2, I’ve been able create and remove items directly from JSR223 scripts (with the PR code).
That is the goal I always push every one to try and achieve. Just make sure you have a backup in case there is some edge case your rules don’t handle. Switches do have their place.
The motion sensors don’t need to be smarter. What you do with the motion events is where you build the smarts. You will find lots of examples on the forum.
Look into the reelyActive stuff. I’ve a tutorial on how to integrate it with OH through MQTT. It uses BTLE to track devices through the house. If you couple that with Find and motion sensors and algorithms like Wasp in the Box you should be able to fuse these sensors fairly easily.
And I really don’t see the problem with the Rules DSL for implementing something like this. Use Groups to aggregate multiple sensors and use Wasp in the Box algorithm and you should have a pretty reliable method of detecting presence in individual rooms. Both are well understood and easy to implement in the Rules DSL.
That is true for any sort of system. OH is not immune to this. The Experimental Rules language under development is hoping to address some of this by having reusable rules. So, theoretically one could put their Lights into a Group or something like that and use someone else’s rule.
That is the main goal of the Experimental Rules engine.
Its in the works. You can try it out by installing the Experimental Rules addon. But it is really primitive right now and there is little documentation or support yet.