Cannot connect RTI system after upgrading to QS 13.2

This has been a nightmare. Back in version 9.4 and below (and Illuminations before that), we had a good thing going. The AV guy asked me how to connect using KBP to the address using a Lutron driver on his RTI system and all I had to do was giving him my keypad number (220) and buttons 1-6. It was easy and we used lutron:integration to log in.

After upgrading to 13.2, it all failed. At first I found the hard way that I couldn't use lutron and integration anymore. I decided to use one of the old log-ins instead and that didn't work either but I found out that all my old telnet login passwords had been deleted as well. Now, even after I picked new passwords (where the software thought my passwords were weak and I had to pick pick random passwords to make one that Lutron thought was strong), I still can't connect.

What has changed in 13.2? Can we still do Key button presses? If I wanted to send a command to press keypad 220, button 1, how would I do that? I don't do integration and have been working with the AV guy on the job and he has tried every driver he has and it just does not connect.

Making some progress.

Apparently, you have to delete all your old Telnet logins completely and put them back in. Also, the QS system locks you out after 10 failed attempts.

Did that and now we can manually telnet into the processor with a client. Still not connecting but it seems like an RTI problem.

Hi SparkyCoog, in the 13.0 version of Homeworks QS we removed the default telnet usernames for security reasons. Once you add in a custom login and transfer all you should need to do is change the telnet credentials in any 3rd party systems that log into the Lutron system.

For testing the RTI connection now, you can verify that the Homeworks system is accepting connection is to use Command Prompt and log into telnet through there. Once logged in you can send test commands to the processor to verify communication. An easy command to send is simply "gettime" and the processor will respond back with the current time set to the processor. You can also send any command from the Integration Protocol Guide and control loads, or trigger scenes.

It's all working now (thanks to tech support) but this whole thing started because I was adding one switch and replacing one 6D dimmer to a 6NA dimmer for a new LED fixture. It was a job that would normally take 2-3 hours and since it had been a few years since I serviced the system, I decided to upgrade the firmware like I had done without issue before and it turned into a week of going back and fourth with the AV company, an unhappy customer, and many hours spent that I won't get paid for.

My point is that this was completely unnecessary because it is a closed system without anybody from the outside having access. A stranger would have to have access to the home network which the AV guy has secured already, just happen to know that the house runs homeworks QS, and also know what commands to send it. And WORST case, if they they did that, they would do what? Turn off the kitchen lights? It's overkill.

Let's assume that this is in fact a security risk and you guys are trying to be proactive - was deleting existing programming from a working system without any warning the way to do it? Why not send an email to everybody warning them that upgrading to version 13 woukd disable all existing integration?

On top of everything, the algorithm that determines a weak vs. Strong password is absolutely frustrating and random. Somehow a 15 character alphanumeric plus symbols password is considered weak but is simple 10 character based password was considered to be medium. What is the logic there?

I'm sure your intentions are good but I don't think you had the installer in mind here. At this point I would be very worried to even touch the lighting on a house that has integration because I would be on the hook for fixing what breaks.

I hope you reconsider and allow the use of the old lutron: integration password. You can give warnings, make me sign a liability paper, or anything else but you have to understand that the AV in many houses was done many years ago with the original guy nowhere to be found but people still add dimmers and other components without wanting to change the other parts of their house av.

This is why I currently have 10 versions of QS software on my laptop. I will not upgrade any system unless its absolutely necessary. Yes its not as bad since I am the Lutron and Crestron programmer for our jobs, but less things I have to modify the better. I get the security concerns, but it should be an option to keep the old logins (with maybe an obnoxious reminder when you open the program that you are not secure), especially on a version upgrade. New QS programs from scratch then yes its ok to ditch the old insecure login. That way it doesn't break functionality.

Situations like Sparky's I would think are all too common where the control system integrator has moved on and not accessible for many possible reasons, or the original control system code is not available and the Lutron programmer does what they think is the right thing and upgrades to the "latest and greatest" and breaks everything.

johnmax, I used to do the same but the early versions of the software (and RA2 especially) was really buggy, in particular in respect with finding the processor, and uploading to wireless devices and each upgrade seemed to help with all that so that's why I thought this time, there would be more improvements as well.

What's a bit disheartening to me is that the industry has really pivoted towards favoring companies that do AV and lighting together whether they are actually experts in both fields, but I still think that lighting/electrical is a different discipline. We used to deal with another company with a lighting system and but they too moved on and want to compete with whole home systems and so far, Lutron is the only company who has stuck to their guns on the topic and not tried to be Crestron or Control 4. In the past, we used to do the electrical and lighting automation and give detailed information to the integrator in case they wanted to tie in lighting to their system. Some did and some didn't but anytime a light doesn't work, I am the one who gets the call so if things get tied together a little too much, the customer is kind of out of luck unless the original AV company is still around.

I'm sure there are many on here who do whole home automation so no disrespect intended but I still favor a more modular type of system where the lights work no matter what and can be modified without affecting the AV system. We feel we're very good with lighting and electrical and don't want to get into AV but hopefully we can still work on high end systems and don't get stuck with Caseta...which is a great system but some customers have a burger budget while others want lobster.

Yup I get where you are coming from. We don't do the electrical side on half our Lutron jobs (even though we do have an electrical division that does sometimes does it if we win both bids), but usually we always get the programming end. Which means when the lights don't work we get the call instead of the EC. And sometimes its programming and sometimes its electrical. But with this specific Telnet issue, it always comes down to our problem since it doesn't work from our end- many times the EC if they did the Lutron programming doesn't really care because their side is working fine and its our problem because they decided to upgrade firmware thinking it would be better for the client. Our motto with any firmware is if it doesn't add anything desperately needed or have relevant fixes, then leave it alone.

Even with doing that the lights are always separate from AV- they work on their own. Even when lutron changes the 3rd party logins and my Crestron cant control them, they always still work from the Lutron keypads. Luckily for the client on the Lutron side if an AV company does the programming and they disappear, you can almost always extract the program from the processor.

I just wish Lutron would stop adding these "features", or give us to keep things as they were. Let us choose so we all don't have pissed off clients and waste peoples time fixing what wasn't broken in the first place.