New Elk Firmware

Everyone has made some good points but I would zoom out to the macro view and take a different look. My disappointment relates to mis-set expectations. I've seen many, many responses from Elk whether they be by phone, email, private message or posts that have indicated that a requested feature / function has been "added to the list" or "its already on the list". We need to know the timeframe of "the list".

My expectation, especially for minor items is that these requests should be in the next major release. Is this latest release a "major" release from Elk's perspective? If so we have a problem. If its a minor release please say so then we can move on to a discussion about priorities. There is no doubt that some of the things they are adding are very complex on such a low level platform but its not fair to the users to spend all your time and energy on the complex additions and overlook a boatload of small one's.

Ok now back to the micro level... Example: How difficult is it to add the ability to control the backlighting of keypads via a rule. If your not a programmer or firmware expert please don't make up a long line of excuses as to why this is hard, needs more memory or could break ten other things. ITS SIMPLE, the basic control structure is already in place and the functionality exists in the keypad. It can already be set it just can't be changed programatically. Even the lowest level is too bright at night in a bedroom and if you turn it off after inactivity (to make it go dark) then you can't see it at all during the day.
 
Being on the suggested feature addition list generally means that when enough people ask for the feature, it could be added. When one person asks for a feature and it is added to a consideration list, does not mean it will be in the next software release.

To understand the complexitity of adding a perceived simple feature like keypad backlight control from Rules involves these considerations:
1. ELKRP software changes, ELKRP protocol to M1 changes and documentation.
2. M1 software changes.
3. RS-485 data bus protocol changes and documentation.
4. Keypad software changes.
5. UL retesting evaluation. If UL retesting is involved, the answer is probably NO. Ask Digger!
6. Documentation and manual changes. Obsoleting printed manuals.
7. Training procedure changes.
8. Technical support training.
9. Evaluation of code space required. Some features just can't be added.
10. Perceived value of the feature against cost to add the feature.
11. Beta testing and field support.
...

Adding keypad backlighting control from Rules is a complex feature change. I would guesstimate this feature will cost $50K to add. You be the judge!

Some people have commented "Why updates are not more often". Other people complain that they are too often now. If a major issue is found, the update will come out very quickly. "It would be nice to have" updates are spaced out.
 
Now just for the record-

I posted the following comment

I was kinda looking for more RCS thermastat support


I have asked Spanky in the past about looking into why the RCS OS21 outdoor sensor is not working. This sensor is supposed to be treated just like all the other RCS T-stats .

I asked about it on Jan- 3 2009 and here is the reply from Spanky

----The RCS outdoor temp sensor has not been added to the data protocol into the M1. I will see if it can be added in a future release.

Thanks.


On Jan 3, 2008 I posted another question about this same type of issue and here is Spanky's reply

---Just give me time. I am working on it!


On Sept. 3, 2008 I aslo asked Spanky this question

spanky-

have you had any time to work on this?

i am needing to add a second os 21 sensor to my attic.


steve

I did not get a reply.


So from my point of view, I have given Elk plenty of time for a straight answer.

All I need is a simple -- Here is the fix or we are too busy and are not going to fix it. Either way I am happy, but don't string me along promising a fix that is never going to happen.



Sorry for the rant


Steve
Edit- I think I even asked about the OS 21 in late 2007. Since that is when I purchased it
 
Being on the suggested feature addition list generally means that when enough people ask for the feature, it could be added. When one person asks for a feature and it is added to a consideration list, does not mean it will be in the next software release.

To understand the complexitity of adding a perceived simple feature like keypad backlight control from Rules involves these considerations:
1. ELKRP software changes, ELKRP protocol to M1 changes and documentation.
2. M1 software changes.
3. RS-485 data bus protocol changes and documentation.
4. Keypad software changes.
5. UL retesting evaluation. If UL retesting is involved, the answer is probably NO. Ask Digger!
6. Documentation and manual changes. Obsoleting printed manuals.
7. Training procedure changes.
8. Technical support training.
9. Evaluation of code space required. Some features just can't be added.
10. Perceived value of the feature against cost to add the feature.
11. Beta testing and field support.
...


Some people have commented "Why updates are not more often". Other people complain that they are too often now. If a major issue is found, the update will come out very quickly. "It would be nice to have" updates are spaced out.




Obviously you need to do things via a release process. The complaint here is that there wasn't much in the last release.
BTW, your docs are really great. Personally, I think you could do away with the printed manuals. PDF's are fine with me.
 
Although not happy, I appreciate Spanky's response. Its VERY telling and informative and will force me to re-think some of my M1 use in the future. Elk needs to remain agile and run circles around other platforms that have greater core functionality. This also demonstrates why a PC based, software solution is better for handling the complex rules processing or client interface HA functionality of an installation. The M1's small, compact and efficient platform is very appealing but its clearly running up against functionality limitations. Perhaps its best as a security / fire system and hardware interface to other systems. The product development cycle for firmware intensive / small processor platforms with very complex low level functionality can be long, complex and tedious. Memory is cheap so thats no longer a good excuse, the M1 could have a USB jack where you plug in a 4gb flash stick which contains all the configuration info and provides space for the M1 HA functionality.

I'd suggest that the M1 be available in a two tier model that reflects the different uses the M1 is applied to. One that is UL certified, core function oriented, super stable and sees relatively infrequent updates. The second tier would not be UL Certified, frequently beta'd features, frequent releases etc. The second tier would take advantage of the technical user base expertise and input. Functions could be developed and debugged using this model and features could ultimately be folded into the UL version as deemed appropriate. The ProdDev. model Spanky describes is way too long, complex and expensive for HA features. As much as I appreciate Spanky's responses, he's the Chief Engineer, I'd like to hear from their founder or marketing people regarding guidance on this product in terms of its envisioned application and future. Sometimes companies have a tendency to want to portray their product as the swiss army knife of the industry. That just leads to a lot of disappoint customers.

This really depends on the direction and resources ELK wants to apply to this product, you could make an argument either way depending on how you "see" the M1. I must point out that’s its taken a long time for the HA and Security Fire panel manufacturers / industry to add functionality and reduce proprietary limitations, its still way behind other industry segments. We are at a classic point in the transition a product makes when its starts out as a small, self contained appliance vs. a full featured high customizable product that needs to interface to a lot of different "standards". We see that problem with the M1 relative to audio interfaces, plc standards, several wireless standards etc. There's no combination that’s fully functional! I don't mean to imply that its all Elk's fault it just demonstrates the larger problem. I think there is a fork in the road for the application of the M1 vs. other solutions. The new release we've been given started this discussion but its been simmering for some time.

Thoughts?
 
As much as I appreciate Spanky's responses, he's the Chief Engineer, I'd like to hear from their founder or marketing people regarding guidance on this product in terms of its envisioned application and future.


Just to clearify...

Spanky is now as his signature says the "heard leader"....

Which in real terms is President. http://www.cepro.com/article/steele_takes_...elk_products/K3

in my mind who better to be talking to?

Im not sure if there was an official announcement here on CT, but I know it was mentioned it in chat one day. The CEPro is the only article I can find quickly.
 
Thoughts?
Sounds to me like your expectations were never set right from the start. Either something you were told or misinterpreted.

The Elk line of products like the EZ8 and M1 are alarm panels first and foremost. That is their history and roots (Moose products). So, you have to understand the core is a security panel and everything that is required for that. Yes, it needs to be rock solid reliable, UL listed, etc to meet the market demands for that. Elk then took you standard alarm panel and took it further to include automation capabilities. Will the products ever compete with a software package that runs on a pc, or even a dedicated HA/non security device - nope, not gonna happen. The M1 is for people that want a great security system combined with a decent set of super reliable HA capabilities. Thats why many people supplement the M1 with software. You use the M1 for its core competencies and mission critical devices and then software for the rest. That is a very powerful and satisfying combination.

If you expect anything different from Elk then you will be disappointed. Maybe you want something more like a dedicated HomeSeer Pro device or a Cortexa or Control4/Elan, etc. But any hardware security/automation panel you pick, whether it be Elk/HAI or any other, you are going to have the same constraints that David mentioned above. So yes, maybe you should rethink your usage of the technologies so that you will not be disappointed any longer.
 
Wow, what's with all the negativity in this thread? ... I have to say, this is very 'anti CocoonTech' behavior.

Not to be rude and hostile and negative myself, but you're joking, right? How much hostility by what % of the top 10 posters was there over CQC's price increase in 2006? Their decision to implement an annual maintenance fee? How about the insteon thread? (there's many, just pick one).

I've seen more than 1 highly negative "humble opinion" about a manufacturer who announces something new. And that attitude breeds company; when folks see that happening, they feel justified in continuing that mentality.

Apologies if this post offends, but the truth hurts.
 
I do understand what the M1 does best. I think this discussion will help to solidify limitations of the M1 for current and especially prospective owners. It will certainly position its functionality in the larger HA picture. Despite all the suggestions and threads dealing with future features I've never seen anyone from Elk reset and reduce expectations. When people are told its "on the list" or being added sometime in the future, as I mentioned, that can certainly lead you to believe these are reasonable and implementable features. Lack of clarity on this point is why there are so many threads from newbies trying to figure out whether the M1 is appropriate for HA and to what level vs. a fine, very expandable Security / Fire / Entry system.
 
My thoughts/opinions are based on feedback I have received from new users of the M1G and my own.

1. Many people have told me it is a lot more than they were expecting. Personally I am still adding new things to my system and I have not hit my limit 4 years into this but I am not using it with any software (yet). I have not found anything I want to do but cant. Partly because I work in the industry and probably dont expect it to do cartwheels when the dog barks because it will trip over its own wires.

2. I have never had an Elk product go bad nor have I received a return for an Elk Product that I have sold. I fully believe that a few have had problems out there but I suspect we dont hear about it because they are so few and far between and god forbid it happens Elk takes care of the customer well.

3. Other than HAI how many other companies come close for this type of product (alarm and automation)? Do Elk and HAI play a game of leapfrog? I think they do and thats awesome for us no matter which you use (they are both great).

4. To have the representation of ELK and now HAI here is priceless as they say. If you had an HAI product and asked for a new feature I think the results would be similar (they would get to it ASAP but that is hard to define in this industry).

5. Neither ELK or HAI are a Smarthome type company. Both seem to bend over backwards to help customers and to make QUALITY products. Cant say for sure if one is better than the other but possibly depending on how you look at it. Each company has its strengths.

I could have a free alarm system from another company (anything I want and always the latest) but while it is an excellent product for what it is .... it is not an ELK and I spend the money on Elk Products and never worry about it.

I can probably make a list of things myself I would want. I try adding similar things to what the ELK does to products from another mfg I work for and I get screamed at as if I am a lunatic for thinking customers would want it. Bottom line is ELK does LISTEN and does IMPLEMENT features few others do, just not as fast as we all might want sometimes. Its just not that easy unfortunately as you need to work with the outside forces that govern things sometimes.

Isnt it awesome that the President of ELK is an Engineer and not a pencil pusher or bean counter? Not saying anything bad about any previous President of ELK but it really is an asset in my opinion. A perfect choice to in Spanky's case.

Do we see reps from Ademco, Napco, GE, DSC etc here listening and interacting let alone a higher up? Maybe but I guess I missed them.
 
I have nothing personally against Elk, its people in general or Spanky in particular. Properly applying hardware and software to real world HA challenges requires a complement of products. Knowing where they are,where they are going and the areas in which they excel is what helps us architect systems that address client needs while mainitaining the best possble balance between customer satisfaction, cost and profitability.
 
My thoughts/opinions are based on feedback I have received from new users of the M1G and my own.

1. Many people have told me it is a lot more than they were expecting. Personally I am still adding new things to my system and I have not hit my limit 4 years into this but I am not using it with any software (yet). I have not found anything I want to do but cant. Partly because I work in the industry and probably dont expect it to do cartwheels when the dog barks because it will trip over its own wires.

2. I have never had an Elk product go bad nor have I received a return for an Elk Product that I have sold. I fully believe that a few have had problems out there but I suspect we dont hear about it because they are so few and far between and god forbid it happens Elk takes care of the customer well.

3. Other than HAI how many other companies come close for this type of product (alarm and automation)? Do Elk and HAI play a game of leapfrog? I think they do and thats awesome for us no matter which you use (they are both great).

4. To have the representation of ELK and now HAI here is priceless as they say. If you had an HAI product and asked for a new feature I think the results would be similar (they would get to it ASAP but that is hard to define in this industry).

5. Neither ELK or HAI are a Smarthome type company. Both seem to bend over backwards to help customers and to make QUALITY products. Cant say for sure if one is better than the other but possibly depending on how you look at it. Each company has its strengths.

I could have a free alarm system from another company (anything I want and always the latest) but while it is an excellent product for what it is .... it is not an ELK and I spend the money on Elk Products and never worry about it.

I can probably make a list of things myself I would want. I try adding similar things to what the ELK does to products from another mfg I work for and I get screamed at as if I am a lunatic for thinking customers would want it. Bottom line is ELK does LISTEN and does IMPLEMENT features few others do, just not as fast as we all might want sometimes. Its just not that easy unfortunately as you need to work with the outside forces that govern things sometimes.

Isnt it awesome that the President of ELK is an Engineer and not a pencil pusher or bean counter? Not saying anything bad about any previous President of ELK but it really is an asset in my opinion. A perfect choice to in Spanky's case.

Do we see reps from Ademco, Napco, GE, DSC etc here listening and interacting let alone a higher up? Maybe but I guess I missed them.

:) :hesaid: :hesaid:
 
...Thanks for the update Elk Products....


When there is a product out there that is the end all, be all product of the HA /Alarm industry someone please let me know...

Otherwise, I think the Elk is the closest thus far. This is without even talking about the support you get here or on the phone with thech support. ESPECIALLY if you are Joe Homeowner...Most companies don't even want to be bothered with you if you haven't been trained or work for an approved integrator with trained people employed there.

Keep up the good work!
 
Adding keypad backlighting control from Rules is a complex feature change. I would guesstimate this feature will cost $50K to add. You be the judge!

At $50k, I guess I won't be seeing this for quite a while. Too bad as it's one of the features that would make things better for dealing with keypads in bedrooms and other places. Any chance of getting ASCII protocol additon to support the keypads so they could be managed from an external source?

And while I'm at it :) , any chance of getting an ASCII protocol additon to pass strings to another serial port. Like "WRITE TO SERIAL PORT 1 xyz<cr><lf>"
 
Adding keypad backlighting control from Rules is a complex feature change. I would guesstimate this feature will cost $50K to add. You be the judge!

At $50k, I guess I won't be seeing this for quite a while. Too bad as it's one of the features that would make things better for dealing with keypads in bedrooms and other places. Any chance of getting ASCII protocol additon to support the keypads so they could be managed from an external source?

And while I'm at it :) , any chance of getting an ASCII protocol additon to pass strings to another serial port. Like "WRITE TO SERIAL PORT 1 xyz<cr><lf>"

If you are only concerned with dimming the backlight on a single keypad, why not open it up, remove or cover the LED, and add an LED attached to an external driver. You can then use ELK rules via contact closure to set the LED to dim or bright, etc. You can buy LED drivers pretty cheaply, at least for low-current single LED applications, or build your own with a few dollars in parts.

As for elk, I think a better solution is to have a few modes of brightness for the keypad(maybe this already exists?) for bedroom uses that are controlled only by the keypad. Avoids the need to mess with the M1.
 
Back
Top