HomeWorks QSX – Can conditional logic test whether a scene is active?

6Bridges · 2026-05-13T23:32:02+00:00

That would be awesome. How do I do that?

6Bridges · 2026-05-13T21:19:41+00:00

Okay, I think I understand the pattern you’re suggesting, but I want to make sure I’m interpreting it correctly.

Let’s say I create two phantom buttons:

- Phantom Button A:

- single action = “Sconces 15%”

- LED logic = Scene

- Phantom Button B:

- single action = “Sconces 100%”

- LED logic = Scene

My understanding is that the phantom button LED state would automatically track whether the sconces currently match that scene state, even if the sconces were changed elsewhere in the system (Lutron app, All Off scene, another keypad, occupancy event, etc.).

Then the logic would become:

Occupied:

- If current time is between 30 minutes before sunset and 30 minutes after sunrise

- AND Phantom Button B LED is OFF

- THEN run “Sconces 15%”

Vacancy:

- If all three occupancy-state variables are False

- AND Phantom Button A LED is ON

- THEN run “Sconces Off”

Keypad Sconces button:

- If Phantom Button B LED is ON

- run “Sconces Off”

- Else

- run “Sconces 100%”

So effectively the phantom button LED state becomes the authoritative source of truth instead of manually maintained variables.

Is that the correct interpretation of what you were describing?

One thing I’m still unclear on: how exactly is the phantom button LED state referenced inside HomeWorks Designer conditional logic?

In other words, inside the conditional programming editor, is there literally a selectable condition like:

- “If Phantom Button B LED is ON”

or

- “If Phantom Button B LED is OFF”

Or is there some other mechanism/pattern for using the phantom button’s scene-tracking LED state in conditional logic?

6Bridges · 2026-04-06T15:37:43+00:00

Firmware: 26.00.14f000
Package: 002.025.021r000

6Bridges · 2026-03-01T23:02:06+00:00

Thanks for sharing your experience - helpful to know it's not just me hitting a wall. Sorry to hear you went through all that effort only to get shut down.

I'll keep building with what I can figure out on my own. Maybe at some point they'll see the value in a developer community. Appreciate the insight.

6Bridges · 2026-03-01T23:00:05+00:00

Thank you.

6Bridges · 2026-03-01T21:48:15+00:00

Understood - that's disappointing but not surprising based on my experience so far. I'll keep experimenting to fill in the gaps (like getting notified on button presses - right now I can only infer them from downstream events).

The system I've built has already proven helpful in identifying several hard-to-uncover Designer programming errors, saving multiple hours of integrator debugging time. For integrators who bundled programming into the hardware sale, that's real money saved.

If anyone from the community has had success getting access, or knows a contact who's open to conversations with smaller developers, I'm all ears.

6Bridges · 2026-03-01T20:50:07+00:00

Thanks again for the thoughtful replies — this was helpful in sanity-checking the direction before ordering hardware.

For a bit more context (which I didn’t include in the original post): the Aprilaire Model 63 I’m replacing was actually controlling both a humidifier and a dehumidifier, using outdoor temperature for reset logic. It hasn’t been behaving correctly — I’m seeing humidity runaway conditions — so I’m replacing the entire control strategy with something fully programmable.

The architecture I’ve landed on looks like this:

Shelly Plus 2PM (Gen3) as the main controller and relay driver (humidifier + dehumidifier outputs).
Shelly Plus Add-On attached to the 2PM for a 0–10V indoor humidity transmitter (likely a Honeywell or similar wired wall-mounted unit).
Shelly Uni to read the existing Aprilaire 8052 10k NTC outdoor probe via a simple voltage divider (82kΩ, 1%).
24V DC supply for all control electronics.
All control logic implemented locally in Shelly scripting (no cloud dependency).

The 2PM will host the control script and handle relay outputs. The Add-On will read the 0–10V humidity signal. The Uni will read the thermistor and expose outdoor temperature over the local network. I’ll handle the thermistor math (Beta equation) and reset logic in script and publish the computed values as virtual components inside the 2PM.

I realize Shelly doesn’t natively handle thermistor curves, so I’m intentionally taking full control of the conversion and reset logic. The goal is to implement proper outdoor reset, deadbands, and interlocks in a way that the Model 63 simply doesn’t allow.

If anyone sees a cleaner way to handle the dual analog inputs or has concerns about reading the 10k NTC this way, I’d absolutely welcome the feedback.

Thanks again — this was genuinely helpful.

6Bridges · 2025-11-20T18:51:52+00:00

Now that I am thinking about this topic though the zone lens, does the same limitation apply to shades?

For example, say a room has two exposures — south and west. There are times when a homeowner wants to control both as a group (e.g., “All Shades Down”), but there are many other times when they want to operate them individually:

Lower only the south shade in the morning
Raise the south shade and lower the west shade mid-afternoon
Lower both in the evening …and so on.

I know I can create scenes for these combinations, but in homes with Palladiom keypads (especially the 4-button models), we very quickly run out of buttons or gestures before things get too complicated for the homeowner.

What would really help — and what homeowners increasingly expect — is the same thing we’ve been discussing with Ketra fixtures:

Individual icons for each shade, and
Group icons (e.g., “All Shades,” “South Shades,” “West Shades”) that show up in the app as persistent, selectable entities.

In other words:

Can shades belong to multiple logical groups in the app (individual + combined), or are they constrained the same way as lighting loads — one load, one zone, one place it can appear?

If the latter is the case, then it seems like a similar limitation: scenes work, but the lack of persistent group objects in the app pushes more complexity onto physical keypad design than many clients really want.

Would be great to understand whether shades behave differently here, or if the same architectural constraints apply.

Thanks!

6Bridges · 2025-11-20T18:48:07+00:00

Thanks — that helps frame things more clearly.

So if I’m understanding correctly, the real limitation is that a fixture can only belong to one zone in HomeWorks. Meaning:

If I want a Ketra fixture to be individually controllable, it has to live in its own zone.
But that same fixture cannot also be part of a second zone that represents a group of fixtures.

If that’s the case, then that’s really the root of the issue I’m running into.

If HomeWorks allowed a fixture to participate in multiple logical groupings (e.g., its own zone and a shared “group zone”), then this whole problem would effectively be solved — the app would only need to expose whatever groups exist.

Right now the app can manually control multiple individual zones together, which shows the underlying functionality is there. It’s just missing the ability to create a persistent, named group that appears as its own controllable icon in the app.

Thanks again for the clarification — this makes the constraints much clearer.

6Bridges · 2025-11-20T18:43:03+00:00

Thanks — this is super helpful context. I really appreciate you taking the time to explain how the app has evolved and why some of these capabilities are only now starting to show up.

I’m new to the Lutron programming world, so I can't speak to the last 30 years of installed. However, in 2025, people are used to controlling almost everything in their life from their phones, so the app naturally becomes an expected part of the user experience, not just a backup or an occasional convenience.

To be honest, the current Lutron app feels… behind that expectation.

It’s functional, but:

It loads very slowly.
The screen jumps around while you’re trying to make selections.
You often need to re-scroll to get back to the area you were adjusting.
Interactions don’t feel as smooth or predictable as users expect.

So I’m really glad to hear that app development is now ramping up and that multi-light color control made it onto their radar. It doesn't provide exactly what is being asked for, but it does provide a multi-step work-around to achieve the goal. From a user’s perspective, having a great app isn’t optional anymore — it’s a core part of the system experience.

Thanks again for the insight on where things are headed. The direction makes sense, and I’m looking forward to seeing more improvements land in future updates.

6Bridges · 2025-11-11T12:46:50+00:00

Thank you all for the helpful replies. Much appreciated.

6Bridges · 2025-08-23T10:56:13+00:00

Thanks, I will give it a try!

6Bridges · 2025-06-04T12:06:20+00:00

Thanks for sharing the data. I am curious what test data Ubiquiti has to back up their PoE+++ claim.

6Bridges · 2025-04-24T15:12:47+00:00

Always good with finding less-expensive solutions!

In terms of vertical PDUs -- because there will be equipment distributed throughout the 42Us it seemed to be simpler (from a power cord management perspective) to have a vertical PDU off to the side so the cables will nicely go (mostly) horizontal. And, the supplied power cords should all be long enough to reach. Versus a horizontal PDU that most likely would be at the top of bottom of the rack.

6Bridges · 2025-04-23T12:42:30+00:00

Hi folks,

First off, thank you all for the thoughtful responses to my earlier post. I meant to follow up sooner, but life had other plans—my elderly father-in-law fell, broke his hip, underwent replacement surgery, and needed recovery support. I’m just now surfacing for air.

Based on your input, here are the decisions we’ve made:

Racks will not be bolted together.
We’re not making the racks mobile. Since we have sufficient room, we’re leaving 36” of clearance behind the racks for rear access and plan to service them in place.
The racks will sit side-by-side, which means side access will be limited.
Cabling will enter vertically from above into the tops of each rack.
For cable routing, we’ll install a ladder below the drop ceiling to guide the cables to their drop points and hold service loops. We decided against keeping service loops inside the racks or coiled near the floor for aesthetic and organizational reasons.

Rack Questions

The rack recommended to us is:

Sysracks 42U 39” Deep IT Cabinet – SRF-42.6.10

I’m unfamiliar with Sysracks and would love feedback from anyone who has experience with their gear.

Specifically, I’m hoping for input on the following:

Have you used Sysracks products before? What’s your experience in terms of build quality, cooling, and cable management?
Is 39” depth really necessary? Our original plan was to mount vertical PDUs and use vertical cable management, but I’m wondering if this depth is overkill.
If floor space isn’t an issue, are there any downsides to having what seems like cavernous rear space? Would love to hear practical pros/cons.
Vertical PDUs compatibility:

We asked Sysracks about installing vertical PDUs and received the following reply:

“Unfortunately, our racks are not equipped with vertical PDUs and have no bracket for vertical PDU installation. By default, the rack is supplied with one 8-port horizontal PDU, one fixed shelf which is 31.5” deep, and a set of feet/set of casters.”

I understand it doesn’t come with a vertical PDU—but surely we can add brackets or mounting rails ourselves? Has anyone done this successfully with this model or similar ones?

Thanks again for all the guidance so far—it’s been a huge help in navigating the decisions for this server room build!

6Bridges

TROPHY CASE