briankelly63
Active Member
I love the creativity that everyone involved in HA manages to come up with when it comes to making a product do what they need it to do for a given situation. There's a number of ways to work around this problem and many others. Like most people that frequent this forum I could easily implement what you suggested. Another example is the M1 rules language, its very primitive but certainly I and many others have written rules that are able to work around most of those limitations. The downside is that it simply shifts the burden for a fix to somewhere else in the process and those efforts are sometimes repeated over and over. If that modified keypad develops a problem one wouldn't be able to change it out as quickly as an unmodified version. A primitive language doesn't always "flow" very well and it becomes difficult to follow the logic of the statements. It also limits the ability to make quick changes without disturbing some cleverly crafted element of the prior code.
In terms of this thread, I was more focused on Elk's change / revision process, where the product was both today and in the future. The lesson learned for me is that I am unlikley to see features added quickly or often and some things will never be added based on current platform or certification limitations. I still see the M1 as a valuable component in an overall HA solution but I will shift some of the focus for the functionality I need to other components based on this lesson.
In terms of this thread, I was more focused on Elk's change / revision process, where the product was both today and in the future. The lesson learned for me is that I am unlikley to see features added quickly or often and some things will never be added based on current platform or certification limitations. I still see the M1 as a valuable component in an overall HA solution but I will shift some of the focus for the functionality I need to other components based on this lesson.