Axing telnet w/ new API not publicly available? No RPM support? What are you thinking

Guys, it's incredibly stupid to release an update that removes the main form of integration (Telnet) when the replacement integration method (the new "LEAP" API) isn't even publicly available yet. I am a potential customer that was planning 80K of Homeworks QS and shade purchases over the next two months, and this is seriously making me reconsider my purchase. We were going to be using the QS controller and RPM panels and I need to have this product support my home automation system (Home Assistant, an open source product which uses the telnet based system). If the LEAP API specs were available, the open source community could add support for it, but if you are planning it to just have it be a closed API, then forget it, I will be cancelling my purchase and going with something else. As it is now, we already have one RPM panel placed and wired in, and I have to figure out what to do about that. No way I am putting in a QS system that will be obsolete the day it goes in.

Just as a side note, I am a software developer with around 20 years of experience. Removing integration methods this quickly (given the number and complexity of outstanding integrations) seems incredibly unwise. The better option would have been to: 1) depreciate telnet support (put a warning when logging in) for starters, 2) for a period of 1 or 2 years, keep telnet available, but disable it by default in new installs and remove the default users for new installs, 3) make the LEAP API publicly available ASAP, to allow partners and end users to switch over to this during this 1 or 2 year window, 4) after 1 or 2 years, totally remove telnet support. That way, you give plenty of notice and minimize angry partners and confused, angry customers. Moreover, you could even transition the telnet API to be ssh based (using public key auth in place of passwords) so you could keep the API structure while fixing the security issues. Existing integrations would then be much more straightforward over having to rewrite to support a totally new API.

I have been singing Lutron's praises for almost 2 decades but I feel that the way they're handling the rollout of QSX and turning their back on existing installations is very hostile. The various sales people at Lutron have always had a certain bravado and swager that we're dealing with multi-million houses whose owners can afford the best of the best so sell sell sell, and that was the case in the 2000's when only multi-millionaires could afford these systems and just wanted things to work but the landscape is very different now than it was 10 years ago. There are many choices and customers are a different generation and do their research and actively program the system through the app and do their own integration with Alexa and the like so I hope Lutron doesn't expect customers to throw away perfectly fine systems over marketing decisions. Through out the years, the one consistent thing about Lutron has been to provide a smooth upgrade path from one system to another.

I had one customer who had the Original Homeworks installed there god knows when. It was on its last legs and we had planned on upgrading it to Series 8 Illuminations system but then Homeworks QS came out and it was a complete no-brainer to upgrade to that, considering the job had a mixture of wired and wireless keypads. That job has had a satisfied customer for 9 years now and the audio/video company that links his system to it has all kinds of remote controls and integration stuff tied in to it and they all use Telnet. None of them are Crestron. Telnet has been solid. This is a closed network and there is zero chance of someone from the outside getting in the network so they didn't need to remove the default user name and password so that broke the system once but fine, we want to make sure nobody physically comes to the house, breaks into the network and changes the dining scene so I can live without having a default credential but why o why remove Telnet all together when there is no comparable service for it yet? Yes, Crestron and the other big 3 or 4 names will likely make their system work with Lutron but no doubt it will require the customer to buy more things they don't need, but what about the hundreds if not thousands of other products that use Telnet and won't be changing? Surely Lutron doesn't expect customers to just throw everything out when it's time to change processors?

Now the above house will probably be ok. It only uses QS links so MAYBE the AV guy can come up with a way to use the new protocol somehow by the time QS processors are gone and they only sell QSX...I have a feeling it's sooner than later but I digress. I also have another customer with 7 full RPM panels and at least 40 keypads in an Illuminations system. That system is one lightning hit away from being gone and then what do I do? Yes, they sell QS right now but for how long? They had that system for about 12 years and would understand having to pay a few thousand bucks to upgrade their processor and some old wireless devices but if QS is gone and QSX doesn't have RPM or legacy keypad support, it will easily cost over a $100k to replace all the panels to DIN rail. That is not reasonable. And yes, I know that for NOW QS still around but version 16 doesn't even support it so going forward it's a dead processor walking. It means they risk not getting anymore updates. It means they can't have access to new dimmers that come out later because version 15 doesn't support it. It's a dangerous precedence. I also gave a bid for a LiteTouch system before this was announced and now I would have to redo that entire bid for DIN panels because it's obvious RPMs are too long for this world.

If any employees (especially those with product decision making powers) are reading this, I implore you to not make us decide between a soon to be obsolete system and a nascent system that lacks basic features. What I find disturbing is that during the presentations of QSX, the speakers casually brushed aside any concerns for removing features and saying things like "well, DIN rails are better, why would anybody go with RPMS now?" except they forget they've been selling them for years and years and they're in place. And with removing Telnet they casually say "well, Telnet has been around since the dawn of the internet so this new thing is better" again, ok fine, but A. Telnet has been around because it works and B. The new thing isn't used anywhere. There are serious concerns that need to be addressed properly.

At a minimum Lutron needs to come out and say for sure how long QS will be around. Don't give this "it's not going anywhere" or "we'll still support it for 10 years". That's a non-answer. I can probably still get a Series 8 processor too if I write a big enough check but it's still an obsolete processor. Installers and customers alike need to know how long QS will be around AND supported with updates for new products. Lutron also needs to come out and say whether RPM, legacy keypad support,and Telnet will ever be added to QSX or has that decision been made so someone with a current system that needs those has the choice of upgrading to QS or just changing directions. What I'd really like is for QSX to do everything QS can do...It's only code. What does Lutron lose by adding those things?

Sparky you are 100% right here. as far as the Telnet integration, what they really should have done was leave Telnet in place with QSX until the Leap API integration is available to utilize, and then have the option of disabling it thru a firmware release. Right now I think the only 3rd party that has any integration with QSX is Crestron, and it is very limited. Yes they (and others) are working on it, but its not happening overnight. As the Lutron and also Crestron programmer for my company, I have had to steer sales dept away from QSX because we don't know when we can tie the two systems together. Instead we are pushing them towards Crestron lighting which is more feature rich, and will be supported for a long time- I still have 20 year old systems that are fully supported with them. If we had the option to do Telnet for now we could get by. I do understand its not the most secure protocol, but as you said with a properly secured network the chances of any foul play are almost none.

We also have some HWI systems that we are quoting upgrades on since the processors seem to be dropping like flies lately. And I have to tell the sales guys NO QSX only QS because they chose not to support RPMs which is a crock of **** honestly. At least support them and charge the license fee or whatever frivolous charge for the customers that gave you all that money already. Just plain stupid.

To be honest, I thought the license fee was complete BS too because they were already paid for but fine, if that's what it would take, I could at least have the option. My biggest beef is that all this is an artificial limitation that smells of marketing majors instead of engineers. The code base for QS is already there. They just need to modify it to fit QSX's hardware which seems more than powerful enough to handle it given that it's got the bridge built in. They just didn't want to do it. The scary part about not having RPM support is that if the Leap API is the future, they're depriving new HWI upgrades from that. It's kind of a paradox - If telnet is bad, why is it the only option for HWI/LiteTouch upgrades and if it's good, why isn't it included in QSX? IMO, both QS and QSX processors need both Leap and Telnet support.

A lot of this is because Lutron doesn’t feel they have to care. What are people going to do, really? That is the environment Lutron has enjoyed for years. Now there are competitors, lots of them, and it’s something Lutron needs to adjust to. But many legacy companies (yes, Lutron is a legacy company) just dig in deeper and entrench further in the old ways when this kind of thing happens. That never works long run. Crestron lighting competing in the high end, countless enthusiast systems competing in the middle, and Apple/google/amazon competing at the low end... yikes! The days may be numbered if Lutron keeps making these stupid choices. The system is also seriously in need of more modern switches and controls. Why is fan control still so problematic these days. Crazy. Patent is up on some stuff too so competitors may eat in other areas as well. I just dealt with a stupid Lutron thing tonight so I’m on a roll with their shortcomings but really they need to rethink their strategy for a modern world.

Is the new API also going to be used for Radio RA2 integration? I have my RA2 integrated with Control4 currently. Thanks.

What Lutron has to understand is that even in the high end market, customers are very engaged and smart about it. apologizes to the "with it" Baby Boomers, but 15 years ago, the type of person who would have a lighting system in their mansion was an older baby boomer who couldn't care less about how the system worked as long as it worked and what they had in their neighbor's mansion. Customers now are a different generation and VERY into this stuff whether it's $20 wifi dimmers, Caseta, Ra2, Vantage , Homeworks, whatever. To be honest, some customers I've met know the ins and outs of Alexa integration better than I do. Hell, there are people who use Home Assistant on their own.

In other words, they know enough to walk away from Lutron whether it's to the other dealer systems or roll their own so Lutron has to be more open, not less. They're not Apple, there is no cult following here. I fully admit that I was wrong about Caseta...at first I thought it was just a toy system but to Lutron's credit, they saw the DIY market coming and got a start at the right time with that. What they're doing with Homeworks now though doesn't make sense to me. At a time where the high end systems have to be more open and work with more things, they're taking away features and at this rate, may put the customer in a difficult position of having to replace their entire system. "I can't use my RPMs or legacy keypads? Ok, let me get my Crestron dealer and get a quote on that since I already use that for AV and this way we cut out the middle man".

I'm all for change but taking away existing features is NOT the way to do it. What's the downside? It's only a few Kilobytes of legacy code.

The new LEAP protocol used for integration is a modern API that offers many benefits over Telnet including faster setup for integrators, richer data, the ability to scale larger, the option for cloud-based or local integrations, enhanced security and uniformity with other Lutron systems. We are working with our major partners first to develop drivers and Control4’s driver is now available in beta. We are open to working with partners across the industry and expand the availability of drivers for other equipment. If there is a specific integration you are interested in, please forward your request to hwsupport@lutron.com and we will get to the correct parties for consideration.

4 months later, is there any progress to publishing the LEAP API? I don't really see much point in keeping it under wraps. Lutron should WANT everyone to use their API.