Why is the Elk M1 so popular?

Well, not to rewind this thread at all, but got told some info in my "real job" that has an interesting parallel to this thread.

2- The system would need to support a large number of devices and support them DIRECTLY. The problem with connecting a bunch of different subsystems together is that the limitations of each subsystem becomes a limitation of the overall autmation setup. If, for example, you depend on an ELK panel to provide your interface to RCS thermostats, you will only be able to access those thermostat features that are supported by the ELK firmware. If ELK decides they don't want to report manual changes to thermostat setpoints in their firmware then that information is forever unavailable to the PC controller.
A true PC based automation system must support the direct attachment of most devices to PC ports without depending on the business priorities of any other company.

As if the universe was out to reaffirm my fear of "quiltmaking" different companies together, at work I was just told yesterday that the two companies I hired to build me something have a disagreement on how to support a given feature. We're currently in the middle of development, way past rqmts & design. These are 2 tightly integrated business partners, combined methodologies, joint proposal, etc., and this mess is now in my lap. Plus, they're claiming the way their contract reads, neither of them are actually responsible for this issue. I'm going to have to go to the CFO and ask for another month and $1M just to accomplish that which we thought we had already paid for. Either that, or get in a real ugly legal battle, which in itself will delay the release by much more than 1 month. Even if I end up not paying the bill, i'll miss the fiscal year-end, which means it comes out of next years budget so I'm still hosed financially.

I may be a DIY'er, but I don't like to take unecessary risks. I generate plenty of risks myself, I don't need anybody else forcing their risks on me. Life's too short for that.

With any luck, I still have a job tomorrow, and have the $$ to continue this HA work.
 
The PC based HA controller is perhaps the best bet for the future but only if you are interested in developing deep scripting and programming skills.

Almost none of our customers ever do anything other than fill in dialog boxes, so I think you may have a misconception about PC based systems. Now, you can certainly do extremely powerful logic if do want to write CML macros in CQC. But you don't need that in order to do a complete system. I'd imagine that fewer than 5% percent of our customers use any CML macros at all, and of those I wrote those macros for some of them, because they just needed a little helper macro to make something easier to do.

I have some quite elaborate macros in my own system, but just becasue I can and I find that the easiest way to do some things, and to acheive a certain level of flexibility that I like ot have.

In CQC, there are two levels of 'doin stuff'. There is the 'Action', which is a dialog box driven thing, where you just compose the steps you want to do. One of the things you can do is to invoke a CML macro, if you want to. The macro can be just one step that invokes a CML macro that does all the work, if you want to do the whole thing in a macro. But mostly it includes no macro invocations at all.

The biggest limitation that we've had is that at the Action level, we'e not had conditional logic. That will be taken care of in the upcoming 1.7 release. At that point, even a quite large and complex system would be doable without writing any macro logic.
 
IVB,
As anyone involved in software knows, NO ONE writes all the code. Dean I am sure doesn't either. He uses both commercial and freeware and Microsoft developed (by MANY independent developers) software components and widgets in CQC. Dean Glues it together to form his application. A lot of development issues is to get these components to play in the same sandbox together. Dean has undoubtedly done a ton of Custom Code to glue things together. He may have done that very nicely, but that's not the point here.

Since we are bringing in related topics, at a recent enterprise level company, they had a content authoring system that was glued together by custom code. The system became unsupportable by any vendors. The solution was to purchase 4 "out of the box" commercial content management solution components and to do some slight XML integration between the pieces.

Up time has been drastically improved, total cost of the system was 1/10th of the prior due to less custom code and continual maintenance is 1/2 of what the Custom system was. And the features that were now available to the business were fantastic in this "Best of Breed" approach. It is now considered that company's industry's best authoring content management solution. So, lots of perspectives.

The situation you are in is not uncommon either.
 
Dean Roddey said:
The biggest limitation that we've had is that at the Action level, we'e not had conditional logic. That will be taken care of in the upcoming 1.7 release. At that point, even a quite large and complex system would be doable without writing any macro logic.
Conditional logic is pretty important. As is the ability to duplicate existing functionality like 80+ hard-wired inputs and phone system paging. I'll take a look at the 1.7 release when it comes out.
 
IVB,
As anyone involved in software knows, NO ONE writes all the code.
As HA is increasingly a "production" system that is mission-critical and needs to be up 24x7, the question isn't who writes the code, but rather who takes on the risk of creating a stable system.

The solution was to purchase 4 "out of the box" commercial content management solution components and to do some slight XML integration between the pieces.

I'm happy that it worked out, but in that model, the purchasing company owned the risk as they did the integration. The fact that it worked out ok means that the risk was succesfully managed & mitigated. They may have felt comfortable taking on this risk as the cost savings were large, but they certainly took on the risk.

In the single/OEM'ed company model, I know exactly who to go to if there's any problems. They've taken on the risk.

Regardless of how skilled folks are at managing/mitigating risk, given the choice between taking on risk and not taking on risk, that needs to factor into the decision.
 
In terms of our software, there is one piece of third party code, which is the standard JPEG libraries. Otherwise, we use nothing but fundamental operating system services. Only in a few places do we use any sort of higher level operating system services, such as a little OLE to provide a web browser wrapper. But otherwise, that's why we have almost 700,000 lines of code, because we want to control the quality and have extremely high integration.
 
Tink said:
I believe (but am not absolutely sure without checking) that everything HomeSeer offers except for working with Internet content is available via the point and click device and event interface pages. Events are created, triggers (what causes the event to run) are assigned, conditions (things to check before actually executing the event) are added, and then actions are added all with a point and click interface.
I agree that HA software like HomeSeer and CQC do make it easy to create events via point and click. But simple events only - basically one liners. I see this as a serious fault of PC-based HA software. I agree with Upstate that scripting is almost mandatory if you want to do anything beyond turning on a light when a motion sensor trips.

I don't mean to champion hardware controllers, but hardware controller programming interfaces (like Stargate) allow you to assemble very complex events via point and click - i.e., multiple, nested if/thens with multiple conditionals, multiple parameters, multiple commands and nearly every possible combination of conditionals/parameters/nests. In other words, I can create a 40 line event via point and click. I can't do this with HomeSeer without using scripts. Why not?

Mark
 
Here is how you build commands in MLServer 3. The click and create you mention.
 

Attachments

  • AutomationRules.JPG
    AutomationRules.JPG
    56.1 KB · Views: 41
yeah, a bit off track but not completely. The original was why is the ELK so popular. That then became a comparison of StarGate to ELK. Then, it turned to software vs. hardware controllers. Then one of those differences was that hardware devices like the StarGate were better because of the method to program conditional events. My post was to demonstrate that that feature is not restricted to the Stargate.

So, just following with the meandering of the thread.
 
IMHO it is so popular since it is a great panel (ok maybe not THE BEST but at least close) and it is well supported by ELK. I would bet some peoples opinion is that it is the best. My opinion is that it is the best I have seen (not that I have seen all).

Worth every penny to me and I am a cheapskate.........
 
Give us a few more days and we'll make it to Mongolian Yak's milk and whether it has more nutrient value than coconut milk.
 
Well, I mean come on. I wouldn't even hang out with someone who disagreed with me on the Yak's milk vs. coconut milk issue. There are limits to my tolerance you know.
 
Back
Top