# of Elk rules/CQC Events

[IVB]

As posted in my other thread, i'm going to start using the Elk in concert with CQC to perform actions based on lack of activity in a room.

I started taking some notes about what Elk rules/CQC events I'd want in my system.
I got this list off avsforum about automation event examples. The author has about 50 high-level events there, some certainly less than useful.

My quick thoughts lead me to believe i'd probably have at least 50, closer to 100 different rules in either CQC or the Elk when "all is said and done". Not that i'm pretending I'll ever be "done" with CQC or the Elk

How many rules or events do you have in your system? Do you notice any performance issues, testing problems, or general brittleness once it gets higher?

It's be nice to know if I'm descending into a rathole of insanity like when I tried to build a quiet HTPC, or if I'm beginning to unlock the synergies possible by using an automation panel and HA software engine.

 

[Squintz]

I don't have many events on either of the systems but in theory the Elk should perform better that the PC simply because it is not sharing processes. I use motion detectors to control my lights and I have them on a timer on the elk. The lights come one instantly and go off on a 30 second delay as the rule I wrote tells it to do. Every now and then I will notice that a light does not shut off for some reason but I am not sure what that reason is. It has happend so few times that it does not even bother me.

I think the smart thing to do is to load as many task as possible onto the elk. This way if something should happen to your PC such as a HD crash you will have most of your logic still available to you. Use CQC for the Media repository stuff and touch screens.

 

[Steve]

I think the biggest problem with the M1 and a large number of rules is the organization of the rules in RP. This has been squawked about alot. Lots of suggestions have been made like tabs, expanding trees, etc. When you just have to scroll down thru a bunch of rules it makes things tougher. Yes, you can move them around, but that is little consolation. I'm sure many others would agree this needs a group squeek.

 

[Squintz]

I would agree that the process of designing the rules is a little slow and painful. I actually like homeseer old 1.x gui for designing events. I have not played with CQCs event designer very much. Once i get the rest of my sensors installed I will probably have a play with it.

 

[Guy Lavoie]

What's missing in the Elk rule editor is room to put comments. I noticed this right away since I'm used to programming the Ocelot controller, where every single program line has a place beside it to add comments. The comments are stored with the project files but not loaded into the controller itself. Having comments would make it a lot easier to quickly go through the rules and look for something specific. With the Ocelot you can even search for a text match in either the rules or the comments. This would be a nice addition to the Elk.

 

[IVB]

ok, so net net: No performance, stability, or other issues with creating tons of rules on the Elk side. (dean - can you speak to upper bound on the CQC side? I can think immediately of 20+ CQC triggered events I'd want, only maybe a dozen scheduled events)

However, the user presentation, GUI interaction design, and management of this may be difficult.

If so, that's great news, as it says to me that the infrastructure is there, and just needs that final polish to be simple. I can deal with that.

 

[Dean Roddey]

There's almost no overhead for scheduled events (other than the overhead of running the actual event itself), since all that's going on most of the time is that a scheduler thread is just looking at the list and seeing if the top event in the list is ready to go. If so, it queues that event up for a worker thread to process and checks the next one.

For triggered events, there is more overhead in that each incoming event must be evaluated to see if it matches the filter criteria for any of the configured triggered events. But as long as you are careful to only set up those fields that you really want to send event triggers, and where possible to only do so when the field changes to a specific value that you want to trigger off of, that will minimize how often that evaluation must be done.

 

[elcano]

I agree with the comments above. But in addition to the organization/documentation of rules, you will have problems with memory. The M1 has a limited amount of memory. On the other hand, with the lack of OR conditions, you have to be very creative to cramp the logic is as few lines as possible - but it is still a challenge. So you will have each automation task spread in a group 3 - 5 rules (except for very simple ones), which will take about 3 - 5% of the memory capacity of the M1. If you multiple that you will not be able to fit your 50 rules there.

My recommendation is to always adhere to the same principles: Put the mission critical rules in the M1. Put the more advanced and convenience related rules in computer software solution. Not that the computer is not reliable (not the topic here), but because the M1 should be (whenever possible) the gateway to the hardware world that you want to control (lightning, sensors, relays, etc.).