Lutron HomeWorks QSX keypad not triggering motorized shades
by SmartHomePro2026• 8 replies• 3515 views
Hey everyone,
I've been pulling my hair out on this one for the past two days. I have a HomeWorks QSX system installed in a client's home, and one of the Palladiom keypads on the second floor has stopped triggering the Sivoia QS motorized shades in the master bedroom.
Here's what's weird - the shades work perfectly fine from the Lutron app and from the Pico remote. The keypad itself is communicating (I can see button presses in the processor logs), but the shades just don't respond when triggered from this specific keypad.
I've already:
- Verified the programming in the Designer software
- Checked all integrations and button assignments
- Power cycled the processor
- Confirmed the shades are on the correct link
System specs:
- HomeWorks QSX processor (v17.8.2)
- Sivoia QS Triathlon shades
- Palladiom keypad (satin nickel)
Any ideas? I'm about to just delete and reprogram the whole keypad but wanted to see if anyone has run into this before.
Replies
ShadeGuyMikeNaN hours ago
Have you checked if there's a conditional or timeclock event that might be overriding the keypad commands? I had a similar issue once where a vacation mode was active and it was blocking certain shade commands from local keypads but allowing app control.
IntegratorPro_TXNaN hours ago
Quick question - when you say you can see button presses in the logs, are you seeing the actual shade command being sent, or just the button press event? There's a difference. Check the integration report and make sure the button is actually assigned to a shade group action and not just logging the press.
LutronCertifiedNaN hours ago
This is a classic QSX gotcha. Check your shade group assignments in Designer. With the 17.x firmware updates, there was a change in how shade groups handle multi-zone commands from keypads.
Go to Setup > Shades > Groups and verify that the master bedroom shades are in a group that the keypad button is actually controlling. Then check the keypad button programming - make sure it's set to control the GROUP, not individual shade addresses.
Also, export your database and look at the XML. Sometimes the Designer UI shows correct programming but the underlying database has corrupted assignments. I've seen this happen after firmware updates.
If the XML looks good, try this:
1. Delete the button assignment
2. Save and upload to processor
3. Re-add the button assignment with the shade group
4. Save and upload again
This forces a clean write to the database.
OP_JeffSystemsNaN hours ago
@LutronCertified - You might be onto something. I did update the firmware about 3 weeks ago. Let me check the XML export and the group assignments. I'll report back.
AVInstallsDailyNaN hours ago
Also worth checking - is this a raise/lower button or a preset button? I've had issues with preset buttons not recalling shade presets properly if the preset was created before the shades were fully commissioned. The preset saves a "null" position essentially.
OP_JeffSystemsNaN hours ago
UPDATE: @LutronCertified was right on the money. Exported the database and found that the shade group reference was pointing to an old device ID that no longer existed. The Designer UI was showing the correct shade group name, but the underlying link was broken.
Deleted the button assignment, re-uploaded, then re-added it fresh. Working perfectly now.
This must have happened during the firmware update. Really frustrating that Designer doesn't flag these orphaned references. Thanks everyone!
SmartHomeSteveNaN hours ago
Good to hear you got it sorted. I'm adding this to my post-firmware-update checklist. QSX is solid but these little database quirks can waste so much time.
LutronCertifiedNaN hours ago
Glad that worked! Yeah, I always recommend exporting and doing a diff on the XML before and after major firmware updates. Learned that one the hard way on a 200+ device estate. Lutron support is aware of the issue and supposedly it's addressed in 17.9 but I haven't tested that yet.
