Where are the config files written out?

[rlkoshak (Rich Koshak)]

@llamahunter

Is the OH2 language substantially different than the 1.x version? Any chance you could PM me some examples?

No, the Rules DSL is largely unchanged at this point in OH 2. They did make it so you no longer need to explicitly import certain obvious things like State classes and Joda.

Probably the best place to look for some example rules I’ve written with explanations is my Design Patterns thread. Start at the bottom as I’ve updated some of the patterns as I learned or thought of new things to make them simpler.

Automation/Orchestration Design Patterns

One more design pattern to add here so I can find it again and reference is future posts. group Persistence Problem Statement There are several reasons why a home automation enthusiast would want to use openHAB persistence: charting, using historical Item states in rules logic, restore previous values on openHAB restart, and my.openhab integration, detailed analysis, access to the data with external tools, etc. However, different databases are more or less well suited to each of these use cas…

Every programming language is really good at something, and the Rules DSL is really really good at looping through members of a Group. Once I realized the power of forEach, filter, and sortBy I was able to drastically reduce the complexity, increase the robustness, and improve the runtime of all of my rules. I quit measuring them but at one point I had reduced my lines of code by around 60%. I don’t think I have a single rule any longer that doesn’t fit on one screen.

I discovered that:

• if I named my Items consistently (so if I have the name of one Item I can find the name of a related Item through some simple String manipulation and a filter)
• put Items into Groups so I can easily search for Items by name
• store as much state as possible in Items instead of local vals and vars
• use “virtual Items” (I hate that name) to trigger rules

I was able to drastically simplify just about every aspect of my Rules, and the Rules DSL started to make sense. The only thing that got slightly more complex are the Items because now I need to create and apply lots of Groups to Items based on certain behavior but even that has its advantages because I only have to look one place (the Items files) to see and change what gets persisted to which database, add or remove Items from certain behaviors (e.g. to add a lamp to come on in the Morning I just add that Item to gMorningLights and now it will come on), etc.

You should see all of these concepts illustrated in that Design Pattern thread.

After making my first path through my rules applying these concepts, not only did my rules greatly simplify, I eliminated all but one lambda and all of my HashMaps. I simply didn’t need them any longer. And while I’ve not done this yet, know that you can dynamically add and remove Items to/from a Group inside your Rules. The changes won’t last past a restart but that could prove useful to you.

Now all is not completely rosey. I’d love it if I could trigger a Rule only once when one of the members of that Group receives an update (right now one update will trigger the rule N-1 times where N is the number of members of the Group). I’d also love a native way to get at the Item that actually triggered the rule rather than the hack I have in place to accomplish that. Also, I which everything were either a java.util.Date or a org.joda.time.DateTime rather than some places needing one and other places needing the other.

But over all, I think the Rules DSL excels at this sort of processing and will continue to recommend it and defend it. It’s a losing battle I’m sure but I’m OK with that.