I’m a Ph.D. student doing research on Programming Language Design. My work focus on the implementation of high-level programming abstractions to coordinate groups of heterogeneous actors (e.g., IoT devices).
As domotics enthusiast, I would like to use Smart House Automations as the primary use case for my DSL.
I started recently working with OpenHAB for the automation of my apartment, and I found very useful the series of publications titled "Design Pattern: ________ ".
As motivation for my work, I would like to know how frequently you guys used those pattern on your home automations.
I mostly interested in these patterns:
Design Pattern: Working with Groups in Rules
Design Pattern: Motion Sensor Time
Design Pattern: Associated Items
Design Pattern: Event Limit
Design Pattern: Expire Binding based Countdown Timer
EDIT#1: If you don’t use the rule DSL, and instead you solve similar situations to the ones tackled for the “Design Patterns” using an alternative language (e.g., Python or JavaScript). I will appreciate if you can share some of your solutions
EDIT#2 Any comments about current limitations (rule’s expressiveness) that you have faced trying to do some automation are also welcome!
I would have, but my answer would have to be D) None of the above. Although I’ve read and learned from many of the design patterns, as an experienced (20+ years in C++) programmer but new (less than 1 month) openHAB user I realized immediately that the Rules DSL was going to be a limitation for me personally, so I immediately went the JSR223 route, and started learning python instead. Most of the rule-based design patterns don’t apply then, but you can instead approach the problems using normal programmer problem-solving methods and design patterns.
Could be possible that you share some solution where you solve one of those situations using Python or another Language?
Right now, I know how to solve similar situations using the rule DSL, but I’m also interested to see how people using JSR223 solved them. I am trying to find current limitations in the expressiveness of the automation rules .
The only limitation I’ve found is that it’s so rapidly evolving that the documentation doesn’t always keep up. Or sometimes the documentation changes so fast that I can’t keep up.
But, people on the forum have been incredibly helpful. In this crazy world we live in these days, it warms my heart and renews my faith in humanity that there’s still a place with pay it forward as the primary guiding principle, that actually functions!
OpenHAB itself appears to be limitless. If it can’t already do it, you can make it do it, at least if you know how to program.
As the author of all of those posts I feel like I should chime in. And I’m really interested in the results.
I would remove the first DP. It is really misscategorized as a Design Pattern. It is more of a tutorial for how to use Java’s (it’s not even something specific to the Rules DSL) streaming List operators to do some common stuff one may want to do within openHAB. But since the survey is already live I guess it’s too late.
The “How many rules use this pattern” part is a little hard to answer for some DPs. For example, if you use Expire based timer for Motion Sensor Timer, you need at least two Rules. Should both Rules count?
Group Based Persistence doesn’t really require Rules so I expect you will largely see 0s for that answer.
I’m a bit ambivalent about the Rules DSL. It is just simple enough for non-programmers to pick up reasonably well without needing to go take a course in programming. But it is very opinionated and restrictive in ways that frustrate people who do known how to program tremendously. I think the direction Scott and company are taking with annotations and the helper libraries for Jython, JavaScript, and Groovy Rules is the right way to go. I believe they are now as easy to pick up for non-programmers without putting the programmers in a straight jacket.
So my advice for any DSL developers out there, if you will have people who already know how to program use your language, do not eliminate standard programming concepts like:
the ability to define one’s own data structures or, even better, classes
the ability to define real methods/functions that behave properly (e.g. have a stack)
make or have the ability to make methods/functions thread safe
there needs to be an IDE with code completion
From a practical perspective, I’m not sure I would recommend straying too far from the “standard” languages, especially for an opensource project. The burden of documenting a wholly new programming language in such a way that both new developers and those new to developing can learn the language. If you use a standard language than there are books and tons of third party tutorials that you can point to and not have to write yourself.
It is a project on the back burner for both scott and me, but many/most of the design patterns are not specific to the Rules DSL. We plan on writing JSR223 versions of all of them as part of the effort to make the JSR223 the new default rules. Scott has already written a great version of Time of Day in Jython.
While some of the DPs are there to work around limitations in the Rules DSL, most of them them are to deal with limitations/design choices in how OH works and therefore they apply equally well to all the languages.
A couple examples off the top of my head include:
Working with Groups in Rules (you are still dealing with the underlying Java List Objects in JSR223)
Expire based Timers
Time of Day
Associated Items
State Machine
Rule latching
Group based persistence
Separation of behaviors
and I could go on. Just because you are using Jython to code your Rules doesn’t mean that you are not still dealing with an event driven system using Items and Groups. Admittedly the way these patterns would best be implemented in Jython et al will be drastically different from how it’s implemented in Rules DSL. And it doesn’t mean they will all still apply. But most of them should.
Probably the biggest limitation is the inability to define truly global variables, data structures, and functions/methods. Rules DSL has support for lambdas but the problem with lambdas is they have no stack and they are not thread safe. If you have the same lambda called twice in a row so that both are running at the same time, they will stomp on each other. The lack of truly global variables/data structures means that we have to use Items and Groups instead.
And this will probably be the biggest difference between JSR223 and Rules DSL design patterns. JSR223 can use data structures and truely global variables and classes instead of needing to put everything into Items.
It was actually your “But it’s just a bunch of hacks” section that pre-emptively steered me away from Rules DSL and into JSR223 :).
But, when you mentioned that the design patterns apply as well, it occured to me that I just haven’t automated that much yet. I successfully migrated to openHAB from the system I used previously, and rewrote the scripts I had written for that system… but that’s it. Other than that it’s been pretty much all nuts and bolts so far. Wall mounted 433 MHz remotes to control lots of different things is wonderful, but not automation per se! It’s nothing you couldn’t do with an angle grinder, more switches, and lots of wire… just a lot easier.
So, I’ll definitely be reading more design patterns in the future.
Yes, maybe it is not the best survey. I just want to know or to have some knowledge about how frequently those Patterns appears in your automations, that info could help me a lot.
You are right, that question is a bit too hard to answer, as I said I just want to have some numbers. I don’t need an exact number.
My point here is to know how often you require to save previous states of an item or the timestamp of the last update in order to determine X condition that may trigger your Rule.
For example: Every day I get a report of how much electricity I spent during the day. One of my rules consists in to notify me if I spent more than X threshold in the last three days.
You are right, that’s why my DSL extends Elixir/Erlang with a single abstraction that I call it “Pattern”. Patterns extend the actor interface (receive) to react to correlated messages, instead of a single message. So, developers can use everything that the Elixir/Erlang language supports, NO restrictions
That’s true, it doesn’t matter if you use the Rule DSL, Jython, JS or Groovy, you have the same problem to solve.
That’s why I chose an actor-based language , I’m using Elixir/Erlang.
Thanks for your comments and I will let you how the survey ends
Well, that’s a different question entirely. The DP provides a way to identify which Items get saved to persistence but it is by no means the only way and use of this design pattern in no way implies that historic data is being used in Rules.
, I’m using Elixir/Erlang.
