Luxafor
Utilities & PersonalConnect AI agents to Luxafor, a USB busy light controlled through a cloud webhook. Agents set colors, blink patterns, and built-in sequences so a flow can signal status on a physical desk.
What This Integration Enables
Luxafor is a USB busy light for one desk, driven through a cloud webhook keyed to a per-device Webhook User ID rather than a bearer token. The whole point of a busy light is social: it is a promise to the people around you that they can read your availability without asking, and its usefulness rests entirely on whether that promise stays true. Software is good at setting a status and terrible at retiring it. Anyone who has watched a colleague sit under a red light for two hours after a call ended knows what a stale signal costs, because the second time it happens people stop trusting the light and start knocking anyway.
Four actions, all of them writes, and this is where the connector's shape starts to matter. Set Solid Color holds a steady color from a predefined set (Red, Green, Yellow, Blue, White, Cyan, Magenta) or any 6-digit hex code through the Custom option. Blink Color does the same thing with attention attached. Set Pattern plays a built-in animation, where Police, Traffic Lights, and Random 1 through Random 5 run everywhere, while Rainbow, Sea, White Wave, and Synthetic are supported only on Windows. Turn Off clears everything by setting a solid custom color of 000000. There is no read action at all, and Luxafor's API is deliberately fire-and-forget: each call returns a JSON acknowledgement, not device state. That asymmetry defines every honest workflow built on this connector. Luxafor exposes no event subscription either, so this service ships no triggers; the light is always driven from a schedule or from something another system reported, never from the light itself. An agent can set the light a thousand times and never once ask what color it is, which means the flow, not the API, has to own the truth. This is the whole argument for human-in-the-loop orchestration on a device this simple.
Without FlowRunner
With FlowRunner
Use Case Scenarios
Availability that follows the calendar instead of the person
An agent watches Google Calendar for the start of a meeting or a focus block and calls Set Solid Color with Red. When the event ends, it calls Turn Off. The value is not the automation of two clicks, it is that the clearing step now exists at all, because a person leaving a call is the least likely moment for them to remember a light. The flow keeps its own record of when it set the color and against which calendar event, since nothing in the connector can tell it what the light is currently showing. If the calendar event was extended in place, the flow sees the new end time and holds rather than clearing on the original one.
A support queue rendered on a desk
A team lead wants the shape of the queue visible without a dashboard. On a schedule the agent reads open ticket counts from Zendesk and maps them to color: Green under the target, Yellow approaching it, Red past it. Set Solid Color carries the steady state, and Blink Color is reserved for the case that actually needs a person to look up, such as a ticket breaching its SLA. Reserving blink is a deliberate design choice, because a light that blinks for everything is a light that gets covered with tape. This is the same discipline that keeps automation exceptions meaningful in any queue.
Incident signalling that admits the platform trap
An on-call flow already pages through PagerDuty and wants a desk-level signal alongside it. Set Pattern with Police is an obvious fit and it is also the trap, because Rainbow, Sea, White Wave, and Synthetic are Windows-only and are silently ignored when the light is driven from macOS or Linux. The call returns an acknowledgement either way. An agent that signals a severity-one incident with a Windows-only pattern on a Mac desk has sent nothing at all and has been told it succeeded. The flow therefore restricts itself to the cross-platform patterns unless it knows the desk it is signalling, and it treats a successful response as evidence that the request was accepted, not that anything visible happened.
Human-in-Loop Highlight
The consequential moment on a Luxafor light is not setting it. It is clearing it, and the reason is that this connector has no read action, so nothing in the flow can ever verify what the light is showing or whether the situation that justified it still holds. Consider the ordinary failure. An agent sets the light red because an incident opened, and then the flow fails, or the incident is closed in a system this flow does not watch, or the person went home. The light stays red. Colleagues, who have been trained by the light, keep not knocking. Now consider the opposite failure, which is the one worth gating. A cleanup rule fires Turn Off after a fixed window because red for three hours "must be stale." If the person is in hour three of a genuine escalation, the light going green is a lie broadcast into a shared room, and the connector cannot detect it, cannot report it, and will confirm with a 200 that everything went fine. Turn Off is a write like any other, and the acknowledgement it returns says nothing about the world. So the agent does not schedule the clear. It escalates it. When the flow's own record shows the light has been red past the window it expected, it posts to the owner in Slack: "Your Luxafor has been red for 3 hours 40 minutes. I set it at 09:15 for INC-4471, which is still open in PagerDuty with no update since 10:02. Luxafor has no read endpoint, so I cannot see the light and I cannot tell whether you are still in this. Clear it to green, hold red, or should I switch it to Blink Color yellow so people know you are reachable but busy?" A person answers, and the agent runs the write they chose. Set Pattern sits behind the same gate for a different reason: a Windows-only pattern on a non-Windows desk is silently discarded, so an agent choosing a pattern for a severity signal is choosing whether the signal happens at all. Gating a device this small looks like overkill until you notice that every action here is a write, none of them can be verified, and the thing being written to is a colleague's belief about whether they can interrupt someone.
Agent Capabilities
4 actionsColor
2- Set Solid Color Sets the Luxafor light to a solid, steady color. Choose one of the predefined colors (Red, Green, Yellow, Blue, White, Cyan, Magenta) or select Custom and supply a 6-digit hex code in the Custom Color field. The light stays lit until something changes it, and nothing in this connector can read back what it is currently showing.
- Blink Color Makes the Luxafor light blink in a chosen color, using the same predefined set or a Custom hex code. Worth reserving for the events that genuinely need a person to look up, since a light that blinks constantly stops carrying information.
Patterns
1- Set Pattern Plays a built-in animated pattern on the light. Police, Traffic Lights, and Random 1 through Random 5 run cross-platform. Rainbow, Sea, White Wave, and Synthetic are supported only on Windows and are silently ignored on macOS and Linux, where the call still returns an acknowledgement.
Clearing
1- Turn Off Turns the Luxafor light off by setting a solid custom color of 000000 (black), stopping any active color, blink, or pattern. This is the action to put behind a person, because the connector cannot confirm whether the state it is erasing was still true.
Frequently Asked Questions
What can FlowRunner do with Luxafor?
FlowRunner agents can run Set Solid Color, Blink Color, and Set Pattern in Luxafor, plus 1 more action.
Does connecting Luxafor to FlowRunner require OAuth?
No. Luxafor connects to FlowRunner with an API key, no OAuth flow required.
Can Luxafor trigger a FlowRunner workflow automatically?
Luxafor doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.
Start building with Luxafor
$100 in credits. No card required. Connect in minutes.