Automation/Orchestration Design Patterns

[scurrier03]

I definitely had you in mind while writing this post since all of your posts about patterns are what got me thinking about this and because I see many of your posts have an academic mind set (I mean that in a good way).

Here’s an example of what motivated my post. It seems that when manually locked or unlocked, Z-Wave locks send an alarm message instead of updating the status of their lock “switch” (I don’t know the proper term).

@chris

At least for my Yale, it doesn’t send updates when the door is unlocked/opened (this is annoying). I think this is also true of other locks. Instead, they send an alarm message - we can of course decode this, and display it, and this is something on my hitlist, but it won’t allow the lock status to be directly updated (probably) - you could use a rule to link it to the lock though (probably).

So now it gets pushed onto me to handle that in my rules. I’d rather model my lock outside of my rules and interpret a “manually unlocked” alarm message as updating the status of the lock switch to unlocked. Maybe that “outside of my rules” place would be event-driven, but it seems like a good place to use OO.

So how would you handle this kind of scenario? I think you’d say that you’d create a proxy for the lock switch and change it’s status to “unlocked” when the manual unlock alarm message comes in. Maybe I just need to get over it, but I’d prefer to see the ability to replace the thing’s actual item with the proxy item and never have to look at the messy actual thing item ever again. If that was possible, then there wouldn’t be the clutter of non-ideal Thing items hanging around and the complexities of the Thing would effectively be hidden/abstracted from the rule design process. This kind of separation of concerns is what led me to my OO thinking.

Do you agree that there is room for improvement related to these kinds of scenarios?

To respond directly to some of your points:

@rlkoshak

I don’t understand what you mean about being spilled across Items and Rules. I see nothing that an OO approach would do to change this. Nor do I see anything sipping you from organizing your rules in a way too avoid this.

I am referring to the way that rules do not really encourage proper separation of concerns and isolation from change. I have no doubt that rules can be used to do many things, but that’s kind of the problem. Rules and Items do nothing to encourage proper modeling of the problem they do not acknowledge the patterns that we know exist in this space. You are even perhaps implicitly acknowledging this point by posting patterns to stand in place of the lack of structure to the current rules.

It’s kind of backwards from what I’d like to see. I’d like to see the default rules paradigm be tailored and structured to make it easy to separate concerns and to isolate change, with the option to go to a less constrained rules language like the current one if your needs somehow can’t fit that common mold. Today, the user is pushed into the deep end right off the bat, free to hang themselves in complexity if they are not careful or don’t understand certain programming principles. I can’t see that standing up well in the long term. But I can see why the strategy of a project would start with the powerful language and then see what patterns develop to know how to design the eventual tailored, default language. To be clear, I’m not knocking the project, just trying to plant a seed on the idea of making things better.

@rlkoshak

I don’t know what you are referring to by “recipes and templates”.

I’m referring to Kai’s post here.

I probably should have started a new thread for this.

Overall, I think I need to gain more experience with designing complex rules before I go totally second-guessing everything. Then my ideas would be tested and I would at least be able to put a finer point on the problems I perceive.