Current and Correct Documentation of Syntax for Things and Items Needed

[rlkoshak (Rich Koshak)]

@jeffsf

Thanks for the pointers.

Happy to help. This stuff is complicated and it takes a bit to get the concepts straight.

@jeffsf

Yes, I’ve already run into situations where I’ve apparently needed to import from java.lang.Math (max showed up as an error in my very early attempts at rules

Access to static methods and members uses “::” (e.g. Math::max(myNumber)). Why is it different? Who knows. You don’t have to import Math or anything else from java.lang.

@jeffsf

as well as finding out that the Item state is a “proprietary” BD

I don’t understand.

@jeffsf

expect that I’ll end up using lambda expressions and closures where I can.

I recommend looking at the Design Pattern postings. Coding in the Rules DSL is particularly challenging for programmers. The Rules DSL has a lot of features built into it that can make for some very terse and simple logic. However, if you try to code it as if it were an OO or procedural language it will fight you every step of the way and you will hate life.

As an example, see this example written by a C++ coder and my response with a much simpler approach:

An Approach for Better Light Timers

edit: I’ve updated the code to show the final form of what I have in my rules file, having to work around limitations of the language caused it to diverge from my original idea, but it works well and makes the rest of my rules far more maintainable and readable. I have been annoyed with how setting up timers for turning off lights is done in OH. Mainly for two reasons; having two different triggers in different .rules files (front porch lights on door open and also when a new Presence is detec…

Alternatively, if you don’t mind waiting (how long I don’t know) for the JSR233 binding to be upgraded to work with OH 2 you can code your rules in Jython, JavaScript, or Groovy if that is more your speed (I happen to appreciate the Rules DSL despite its many flaws).

But some rules of thumb for success with the Rules DSL:

• avoid trying to create data structures, use Items and Group membership instead
• avoid using named lambdas, combine Rules and use Separation of Behaviors and Group processing instead
• take advantage of the resources OH provides (e.g. use Persistence rather than keeping timestamps, use Groups and Associated Items instead of Maps

Obviously these are all rules of thumb, not strict dictates. But I do treat the creation of data structures (which is awkward in the Rules DSL to put it nicely) and excessive use of named lambdas as code smells. There needs to be a good justification for using them.

@jeffsf

Still haven’t found the code that parses the flat-file format, but still looking.

It may not be that obvious. My understanding is that the actual base is Xtext (or maybe Xbase) with a custom grammar. There may not be actual code that you will find, at least not code that you will find useful. You may only find the grammars that these third party libraries use to define the langauge. Look for .xtext or .xbase files.