New Elk Firmware

[Steve]

Wow, what's with all the negativity in this thread? Elk announce a new firmware release like they have for years and they get blasted because every feature and upgrade ever asked for is not in it? I have to say, this is very 'anti CocoonTech' behavior. Elk is still a relatively small company and I'm sure they have to prioritize projects like everyone else. Also, I'm sure Elk, like many other companies have been burned by pre announcing things then getting nailed when something happens and dates slip, so they all are going to a practice of not announcing things until they are ready. Who knows, Elk may have a whole slew of new things ready to be announced at any time? I don't know, it's just weird to see this reaction to Elk.

And I also have to comment on:

I like the CQC model a lot better - customers get to have a lot of input and see what's coming.

And what model is that, a Beta discussion thread on the CQC forums? Are you saying customers don't have alot of input to Elk? It seems from the replies in this thread alone there has been alot of input to Elk. And see what's coming? Yes, Dean does talk about new stuff and ideas far in advance sometimes. But what if it never happens? What if the feature talked about turns out to not be what somebody wants? And there are many things that make it on the 'list' but get bumped sometimes for years because of constantly changing priorities. A great example is the ability to 'pause' a driver so you don't have to remove it and reinstall it just to use the serial port (like for running UpStart when the UPB driver is loaded, or Nuvo config software when the Nuvo driver is loaded, etc). This is no different.

I use both M1 and CQC and could easily complain about things in both, but as a whole they are great and I love and recommended them both.

So why don't we all take it a little easy on these guys, bitching about features that didn't make it into a given release is not going to get it there any faster. The last thing I want and I'm sure you want is David/Spanky (or any mfg) to say the hell with CocoonTech which I'm sure is a thought that would cross his mind when reading through this thread.

 

[Sacedog]

 

[electron]

I am a little surprised as well. The Elk M1 is not just another software package where having major bugs is an acceptable risk. The Elk M1 is a full blown alarm panel first, home automation controller second. You can't just implement every request like that, without doing major testing, making sure that this one tiny change/request doesn't affect any other components, after all, your life could depend on this device. Then you also have the potential issue of hardware limitations (all these requests take up more memory and cpu cycles).

It would be nice to see Elk implement every feature request (and they have implemented many of our requests, just look at the W800RF32 support as an example), but that's just not feasible.

 

[comet48]

Wow, what's with all the negativity in this thread? Elk announce a new firmware release like they have for years and they get blasted because every feature and upgrade ever asked for is not in it? I have to say, this is very 'anti CocoonTech' behavior. Elk is still a relatively small company and I'm sure they have to prioritize projects like everyone else. Also, I'm sure Elk, like many other companies have been burned by pre announcing things then getting nailed when something happens and dates slip, so they all are going to a practice of not announcing things until they are ready. Who knows, Elk may have a whole slew of new things ready to be announced at any time? I don't know, it's just weird to see this reaction to Elk.

And I also have to comment on:

I like the CQC model a lot better - customers get to have a lot of input and see what's coming.

And what model is that, a Beta discussion thread on the CQC forums? Are you saying customers don't have alot of input to Elk? It seems from the replies in this thread alone there has been alot of input to Elk. And see what's coming? Yes, Dean does talk about new stuff and ideas far in advance sometimes. But what if it never happens? What if the feature talked about turns out to not be what somebody wants? And there are many things that make it on the 'list' but get bumped sometimes for years because of constantly changing priorities. A great example is the ability to 'pause' a driver so you don't have to remove it and reinstall it just to use the serial port (like for running UpStart when the UPB driver is loaded, or Nuvo config software when the Nuvo driver is loaded, etc). This is no different.

I use both M1 and CQC and could easily complain about things in both, but as a whole they are great and I love and recommended them both.

So why don't we all take it a little easy on these guys, bitching about features that didn't make it into a given release is not going to get it there any faster. The last thing I want and I'm sure you want is David/Spanky (or any mfg) to say the hell with CocoonTech which I'm sure is a thought that would cross his mind when reading through this thread.

"Who knows, Elk may have a whole slew of new things ready to be announced at any time? I don't know, it's just weird to see this reaction to Elk."

And neither does anyone else. That's the problem. I also use CQC and Elk, and with CQC, I know exactly what's coming. With Elk, I have absolutely no idea whether some of the significant problems I have with the product are ever going to be addressed. There are some functions best done in the elk, and others in CQC. I'm being forced to do things in CQC that are best done in the Elk because of severe limitations in the product.
Elk acknowledges user requests, but doesn't let us users know what it is and is not going to implement.
Personally, I think the latest update is really pitifull!!!!!!!!

 

[Helheim]

The new audio equipment commands are in this M1 update for Russound, Nuvo, and Proficient. ELKRP and M1XEP has to catch up to use the commands. They will be in an upcoming ELKRP and M1XEP software update.

The ELKRMS configurator software will be shown at EHX.

To me it sounds like they have done a fair bit so I don't know how it's pitiful??

 

[Digger]

I am a little surprised as well. The Elk M1 is not just another software package where having major bugs is an acceptable risk. The Elk M1 is a full blown alarm panel first, home automation controller second. You can't just implement every request like that, without doing major testing, making sure that this one tiny change/request doesn't affect any other components, after all, your life could depend on this device. Then you also have the potential issue of hardware limitations (all these requests take up more memory and cpu cycles).

It would be nice to see Elk implement every feature request (and they have implemented many of our requests, just look at the W800RF32 support as an example), but that's just not feasible.

Maybe what people dont realize is that a software program is not usually controlled by 3rd party agencies like hardware/software combinations that are used for "other than automation".

Making changes to a product like the M1 that could possibly have a suttle effect on the burg or fire side of the product may need to be resubmitted to UL or another agency. That can take many months to a year and is VERY expensive. Even changes in the installation instructions would have to go back to UL and cost thousands and take a few months.

If the changes are bug fixes or just affect the automation end then they dont always have to go to UL.

There are a lot of things that can affect the ability to release changes, improvements etc to a product like this. I do this for manufacturer and I find it best to batch things together and submit to UL or ETL as in the long run it is faster and more cost effective. To have to spend $10K or more to have functional testing done on a panel is not easy to swallow.

Not saying the above is actually affecting the ELK M1 but it very well might be in some cases of the feature requests.

 

[comet48]

Well, if they keep adding functionality at this rate, they won't be winning any more "Product of the year" awards

 

[mustangcoupe]

How about improvements to the rules, like an "else" command. Or improvements to UPB's so they are actually usefull, like the ability to determine the actual status, and confirmation of receipt of the actual command. Or support for thermostats from rules, where the thermostat is not actually attached (virtual thermostats), or support for more than 20 custom settings.
Elk provides great - perhaps the best - support for existing products. However, when it comes to any forward looking features, it's like a black hole. I like the CQC model a lot better - customers get to have a lot of input and see what's coming. This really is disappointing.

I beleive the UPB would be in the serial expander not the controll (could be wrong though) so maybe there is still hope

and remember the limitations are greater with Hardware then software.. you cant just open up the ELK and stick in more memory or hardware that may be a limiting factor as you can with a computer baised system like CQC.

 

[Steve]

"Who knows, Elk may have a whole slew of new things ready to be announced at any time? I don't know, it's just weird to see this reaction to Elk."

And neither does anyone else. That's the problem. I also use CQC and Elk, and with CQC, I know exactly what's coming. With Elk, I have absolutely no idea whether some of the significant problems I have with the product are ever going to be addressed. There are some functions best done in the elk, and others in CQC. I'm being forced to do things in CQC that are best done in the Elk because of severe limitations in the product.
Elk acknowledges user requests, but doesn't let us users know what it is and is not going to implement.
Personally, I think the latest update is really pitifull!!!!!!!!

But seriously, tell me 1 hardware company where you know everything they are working on. Can you tell me right now what is going to be in the next release of HAI's firmware? As has been stated, you just can't compare making changes in a software package to a hardware products firmware. And the memory limitation in the M1 is real. Why do you think there are split revisions of firmware. There is virtually no space to add any new functionality. What would be pitiful is a company putting out a product and not supporting it or not caring about their customers and real bugs and problems they have. If there is a critical problem with the M1 I'm sure Elk would address it quickly but it may not be possible at all to add new functionality.

Let's use some real examples you brought up.

How about improvements to the rules, like an "else" command.

Sure, that would be great, but that is a core change to the way their whole logic engine works and would require significant changes. And, its probably not even possible due to memory constraints

Or improvements to UPB's so they are actually usefull, like the ability to determine the actual status, and confirmation of receipt of the actual command.

What is Elk not doing here that you want to see? There were threads about status in regards to links where Elk does not know a devices status if it was changed by a link - but that's not an Elk problem, that's a UPB issue. The only way to fix that is will polling, which is exactly what the CQC driver does. But imho that's not really feasible or even desired in the Elk - plus again, I'm sure there is no memory space left to implement something like that. But there is a workaround, and thats simply to let the M1 see all the links and make the changes. Instead of having a direct link from UPB device to device, have the M1 see the link then change the desired device. Doing it that way the M1 will always know the correct status.

Or support for thermostats from rules, where the thermostat is not actually attached (virtual thermostats),

Not sure what is being asked for here

or support for more than 20 custom settings.

I'm going to go out on that limb and say memory constraints here.

Perhaps it would be helpful to you or others for Elk to say what they "can't" do in the M1 so you are not disappointed when it doesn't show up in a future release. Like maybe they can say due to memory constraints they can't do more custom settings or add 'else' or other options to the core logic.

I think David has been alot more communicative to us us then many others over the years and he will tell us whatever he can so why don't we ask nicely instead of saying a new firmware release is pitiful just because it did not contain the things you were personally looking for. I'm sure there are alot of happy people that were suffering from things now corrected, and don't overlook the stuff that is in there that is related to peripheral products upgrades not released yet.

Edit: Was typing while Todd posted, I guess we were thinking some of same things/hence the duplication.

 

[comet48]

The model I want to work is to use CQC to set parameters in the Elk and then have the Elk do the work. I like this because if the PC goes away for a time, which they all do, then everything continues to operate via the Elk.
It's currently a real problem with CQC and Elk - the elk driver does not support counters, so we are limited to 20 custom settings and outputs for binary switches. I've used my 20 custom settings already, so I have real problems. One could argue that cqc should update the driver, but the reality is that they are a 1 engineer company.
You can assess and change thermostat settings in the elk from CQC or ElkRMS, but you can't access these settings from elk rules unless a physical thermostat exists. So for keeping track of for example pool temperature settings, instead of using an elk thermostat, one has to use the limited custom settings.
In dealing with lighting systems like UPB, elk assumes that the command worked. No confirmation of reciept. The protocol supports it. Elk does not. This and other UPB issues have deen discussed in detail in threads here. Sparky took it under advisement, as he does with lots of suggestions here. However, I don't see any action and unfortunately I have no idea whether any of these issues will ever be addressed.

 

[Steve]

Yes, I would argue supporting Elk counters in CQC in a CQC problem, not Elks Just because CQC has 1 main engineer doesn't mean ELk is like Microsoft either. They also just have a handful of engineers. It's really the same with CQC as with Elk in that regard. I understand you are frustrated that maybe the Elk driver doesn't have all the features you want, but there are other things in CQC (like ability to pause a driver) that I have been waiting for for years, but I don't complain to CQS every time a new release comes out that doesn't have it. These guys are doing what they can with the priorities they have, its really that simple.

But what about outputs? Could you use those as binary switches to do what you need?

I don't know exactly what you are trying to do with the stats and temps, but I will concede that is an area that Elk has received alot of feedback and the panel is weak in that regard. I too would have like to see a more robust offering in that regard.

That said, my view has always been the same (or at least similar to yours). I want the Elk to do all the stuff I deem critical - stuff like security, lighting, etc. I got CQC as a nice interface and to do the other nice to have supplemental stuff. When I look at stuff like pool settings, I consider that one of those nice to haves, and my wife is beating me up to get it - the simple display of the pool temp on the touch screen. Knowing Elk does not have or support a proper probe (without having to diy my own solution with epoxy, etc), my plan is to get a datanab device and use it with CQC. While I also worry about a pc solution I do have to say my CQC server has not been down a single time in over 2 years except for my own doing, so I am pretty comfortable adding things like that to CQC only. I know Elk did just make some changes to HVAC support at least for the Omnistat2, so maybe there is more good news in that respect coming.

WRT UPB, if there is something supported in the protocol that could be implemented in the XSP code space and it would make a big difference in usability, then I agree it would be nice to see Elk support that or comment on it. But I can't comment further without knowing specifics.

 

[icellama21]

Of course Elk has a really big business incentive to keep their release schedule quiet. When a platform is maxed out (split firmware is one indicator), the competition has just updated everything and jumped way ahead(HAI), and releases/news/products are at a trickle, it all points to either impending bankruptcy, or in Elk's case, more likely a major engineering push. I highly doubt there is much more they can fit into the M1, and who knows where the next expansion will be, but for now we wait. Spanky has told us that elk will continue to support the M1G regardless of what the future holds.





EDIT: Since I have no clue what elk is actually doing, I don't want to be alarmist and offer predictions.

 

[comet48]

That's probably a pretty good read on the situation. They certainly didn't expend a lot of engineering effort on that "upgrade".

 

[mustangcoupe]

My concern is about the future. Of course Elk has a really big business incentive to keep their release schedule quiet. But I have an incentive not to install a 2006 era M1 if a new panel is only a few months away. When a platform is maxed out (split firmware is one indicator), the competition has just updated everything and jumped way ahead(HAI), and releases/news/products are at a trickle, it all points to either impending bankruptcy, or in Elk's case, more likely a major engineering push. I highly doubt there is much more they can fit into the M1, and who knows where the next expansion will be, but for now we wait.

I think you need to go back to your other thread you started a few months ago.... especially Spanky's response about the M1 Standard http://www.cocoontech.com/index.php?s=&amp...st&p=105923
I think they will always support the M1G even if we see a M2



I think what we really need, and maybe this is in the works (we never know) and maybe this is the major engineering push you are talking about is a coprocessor connected to the databus hub which can extend the flexibility of the M1.

 

[Spanky]

Have you ever seen a duck gliding slowly across a pond, but under water it is pedaling like mad.

The new software release is 5.1.14. The last public release was 5.1.8. This forum has many beta testers that have received beta software update versions in the last 6 months.

New stuff is in the works.