Automation/Orchestration Design Patterns

[rlkoshak (Rich Koshak)]

Sorry for the tardy reply. I’ve been on travel then was ill. I’m just now playing catch-up on the forum. WAY behind…sigh.

@steve1

Pretty good relative to what? Yes, the Rule DSL supports event-based programming. However, it’s not any better at event-based programming than a JSR223 rule.

The requirements of defining home automation logic.

This isn’t some zero sum game where if the Rules DSL is good it means JSR233 has to be bad. Beyond the fact that the Rules DSL is the language presented as the language for OH, and JSR233 doesn’t work on OH 2 yet I’d say they are all pretty good at solving this problem. My main purpose is to defend against the sentiment that the Rules DSL is crap and not worth consideration. Not to impinge on JSR233’s languages.

Frankly, if JSR233 became “the face of OH Rules” and worked in OH 2 I’d probably jump to coding my rules in Python in a heart beat.

@steve1

With the JSR223 languages you have a richer set of options for programming techniques, data structures and for creating reusable, modular code. If you want to use OO techniques, that can done. If you want to use functional techniques, you can do that. You can even use Group-Oriented Item-based programming techniques where appropriate.

I agree. JSR233 languages are awesome. I’ve never said otherwise. The awesomeness of JSR233 languages neither adds to nor takes away from the suitability of the Rules DSL.

@steve1

And no, defining a DSL Rule per file and using file-scope variables is not the same as OO encapsulation.

I never said it was the same thing. I simply pointed out that some encapsulation is possible.

@steve1

My focus is more on the pragmatics of how to most effectively implement OH automation functionality.

And I agree. And I think I’m coming from the point of view that:

• the language should not be so complex that non-programmers need to go through a coding boot camp to define their automation logic
• the types of programming logic required for home automation is not all that complex requiring all that extra complexities that come with OO and other programming paradigms. Said another way, the problems all of those concepts and approaches to programming are rare in this domain.

@steve1

I agree that one advantage of the DSL is that it’s the “default” for OH.

I may have miss spoke. I don’t see this as an advantage. This is merely an explanation for why I use it, continue to use it, and defend it. [quote=“steve1, post:36, topic:1967”]
I believe that the Rule DSL is an inferior approach that requires even professional programmers to spend significant amounts of time to “bend to the language”. I don’t find much to like about it, especially since there are better options.
[/quote]

I find programmers are the primary ones who have the problems with the language. And that is perhaps the crux of my argument. If we limit Rules programming to only programmers as the audience then we have failed as a community.

Honestly, I don’t think the Rules DSL is all that friendly to non-programmers either, but based on my experience on this forum and elsewhere it is far friendlier to non-programmers than Python or JavaScript are.

And every programmer everywhere “bends to” their chosen languages. The Rules DSL requires no more of a programmer to bed to it than Lisp requires of a Java programmer.

@steve1

Oddly, the page you linked to shows lambdas being used in many places (and so does the “Set lights based on Time of Day” example).

So I miss spoke again. What I’m really referring to here is named lambdas (i.e. a lambda defined at the top of a rules file and stored in a val). Indeed, every call in all of code that uses are lambdas.

@steve1

However, I think that Group-Oriented programming where lambdas are used to access “fields” of data structures is a clumsy and nonperformant

I find it fairly comparable to working with NoSQL databases.

As for performance… show me the rampant problems and I’ll start to agree. Related to what I said above, performance problems in home automation appear to be rare.

@steve1

A switch statement with numerous cases that must be modified for each new scheduled action is not the way I want to implement my rules.

So it comes down to personal preference. Which I’m fine with. But I don’t use my personal preferences to denigrate other approaches. And like I said above, I’d have to see a concrete use case to truly say how I would best solve the problem. I usually try to avoid switch statements and the like where I can but when what you end up implementing is a state machine (an admittedly major weakness in the Rules DSL) sometimes it is hard to achieve.

@steve1

AFAIK, you can’t use a variable in a Rule DSL trigger.

That is true.

@steve1

I don’t want to effectively write my own scheduler by having a periodic rule trigger and then evaluating which time constraints are ready to execute.

Which is fine. It’s a different approach to solving the problem. An approach that I think would be completely beyond the reach or understanding of non-programmers.

I think of these sorts of problems like state machines where the “scheduler” is driving state transitions based on time. The state transition is the event that triggers rules or the rules check for the current state if that matters. I find this approach pretty simple to reason about, to implement in the Rules DSL, and most importantly to teach non-programmers. I would probably end up doing something similar in Python examples of the Design Patterns (which would probably be a whole different set) because of how much easier it is to teach to the non-programmers.

@hannibal29

And also I’m not familiar with the approach of the new experimental engine. So maybe I missed some opportunities to improve my code or do things more efficient compared to the current DSL rules I use.

You haven’t missed anything. The Experimental Rules Engine is an OH 2 only thing and not really ready for prime time. I suspect that in its end form it will be basis for development of a graphical Rules editing UI.

@hannibal29

The thing I was always missing with OH was the possibility to use pre-defined logic patterns (maybe from a official database) like many other home automation systems do (for example Edomi).

That is indeed a stated goal of the Experimental Rules Engine.

@hannibal29

And all the logic happens inside a “black box” (is this an object?).

And that is also a potential problem and the source of a lot of people migrating from other home automation engines. Often those products ONLY provide such black boxes which is great when the black box does what you want and major problem if it doesn’t.

And this could be an object or collection of objects (i.e. library).

This is indeed a major weakness in the Rules DSL. And I’m not trying to argue that the Rules DSL is great for non-programmers. It isn’t. I just find it better because it is significantly simpler than the other languages unders discussion.

@steve1

To follow up on the Actor discussion, note that Actor-based programming is not mutually exclusive with Object-Oriented programming. For example Akka (Java) and Pykka (Python) Actors are class instances. In that sense, the JSR223 rule objects are closer to the Actor implementation in those frameworks than the DSL Rules. However, neither one has most of the properties, guarantees or benefits of an Actor-based implementation.

I have conceeded that thinking about the Rules DSL as Actor Based is probably not helpful and will refrain from doing so from now on.

@steve1

There is an interesting possibility if someone wants to use OH with an Actor model implementation. With JSR223, one could bypass the rule engine completely and tap into the events from OH/OSGI event bus. Those OH bus events would be processed by a bridge actor that would dispatch the messages to other actors that expressed an interest in those types of events. I’ve confirmed that Pykka works with Jython and even Akka could theoretically be used although I haven’t tried it.

Someone could probably quickly prototype something using MQTT Event Bus (assuming these or other similar languages have MQTT libraries) to prove out the concept and avoid mucking around in OH internals.