C4Bridge — open-source local Control4 management for homeowners

Where this came from: this question was asked on c4forums/General Control4 — not here. We answered it there, in public, and this is that answer.

The part of this I'd push back on is "Composer would only be needed for the initial driver installation." That sentence is carrying more weight than it looks. Homeowners don't have Composer Pro, and Control4's Composer HE guide says designing the system is dealer work in Composer Pro, even though additional devices can be added and identified in HE, so whether an owner can load a third-party .c4z themselves is worth checking on a real HE install. So in practice step one of your install is "get your dealer to load it," and that's where a lot of these projects stall. Some dealers will say yes. Some will say no because they're the one who gets the call when it goes wrong. Worth designing the onboarding around that from day one rather than finding out after launch.

On the dealer objection, my honest view is that you're right on the substance. A homeowner shouldn't need a paid visit to move a shade schedule from 07:00 to 07:30, and our side of the industry has gatekept that stuff longer than it deserved. What dealers actually worry about is invisible automation. The classic bad call is "the downstairs AC shuts off at 11:30 and nobody knows why." If your schedules live only in a web UI the dealer can't see, the next person troubleshooting the system will spend an hour hunting through Composer programming that isn't there. If the driver shows its active schedules somewhere visible in Composer, say a read-only property or a status field, most of the professional resistance goes away. That one change would do more for adoption than any feature on your list.

Two technical things I'd look at before coding. First, check what owners already have: Composer HE includes the Scheduler agent with sunrise/sunset offsets and repeats, and control4.com has When >> Then. The gap is a simpler way in, not the feature, so it may be worth scoping around that. Second, the brightness abstraction is where the pain will be. Native Control4 lighting behaves consistently, but third-party lighting drivers (Lutron, Vantage bridges, Z-Wave) don't all implement the light proxy the same way. Test against a mixed system early, not a clean all-C4 bench.

Also look at the Home Assistant Control4 integration (pyControl4) before you build the control side. It already talks to Director locally (it signs in with the owner's Control4 app login) for lights, climate, covers and room media, so your .c4z might only need to handle what it genuinely can't, like schedules that live on the controller and survive a reboot. Also think about what happens to your persisted schedules when a dealer restores an older project backup. I'd want to confirm that behaviour on a live system before promising it.

If you get to a first build, I'm happy to look at it and tell you what I'd expect to break. (The repo now redirects to IsraelCIL/DirectorLink, if anyone's looking.) Disclosure: I'm a Control4 and Lutron dealer and do remote work on these systems.