This page is not going to tell you that building it yourself is a bad idea. It is a great project: a live data feed, a real-time state machine and a physical output you can see from the sofa. If you enjoy that, stop reading and go build it.
It is going to tell you what the project actually is, because the gap between "my lights go yellow" and "my lights are correct for two hours every Sunday from March to December" is much wider than it looks from the outside. Everything below is the work that lives in that gap.
What you're actually signing up for
Roughly in the order you will hit them.
A live flag source, with auth
Historical F1 data is easy to find. A live feed during a session is not. OpenF1 is the usual answer and it is a genuinely good project, but live access needs an account and an OAuth token you have to refresh, and the broker caps concurrent connections. Budget time for token handling before you write a single line of light code.
A flag is not one field
There is no single "current flag" value you can read. You reconstruct it from race control messages plus track status, and the two disagree. Race control is prose, so you end up pattern-matching text, and the text is full of traps: "GREEN LIGHT - PIT EXIT OPEN" appears while the track is still red, and a message announcing a safety car ending is not the same as the track going green.
Yellow is at least three different things
Single yellow, double yellow, and sector-scoped yellows all mean different things, and a virtual safety car is not a safety car. If you collapse them into one "caution" colour you lose most of the value, and if you do not, you now own a state machine.
Broadcast delay, per viewer
The live feed is ahead of every stream, by a different amount for every viewer and every provider. Without an offset your lights spoil the crash before you see it. With a fixed offset you are wrong for half your audience. It needs to be calibrated and it needs to apply to every reaction, not just flags.
Fastest lap is scoped, and laps get deleted
A purple flash is easy until qualifying, where the broadcast resets the benchmark for Q1, Q2 and Q3 separately, so "fastest of the session" is the wrong comparison. Then track-limit deletions retroactively invalidate times you have already flashed for.
Every light vendor is its own project
Philips Hue needs a bridge and its v2 API behaves differently from v1. Govee's cloud API has no flash effect at all and rate-limits aggressively, so a crisp flash means driving it over your LAN instead. LIFX has its own cloud limits. LAN discovery is lossy UDP multicast, so a single scan legitimately returns nothing and you need to merge results across scans.
It has to survive two hours unattended
This is the part that catches everyone. A script that works when you run it in a terminal is not the same as something that reconnects after a dropped socket, notices the feed went stale, and is still driving lights in lap 50 while you are watching the race rather than a log.
The maintenance is the project
A DIY build is not finished when it works. It is finished when you stop watching F1. Two real examples from the 2026 season, both from the feed most DIY builds depend on:
29 August 2026
The MQTT username rule changed
OpenF1 announced that the username field on the MQTT and WebSocket broker must now match your account email. Any string used to be accepted. Mismatched connections are now rejected with 0x87. If you had put a placeholder in there, as the docs previously allowed, your feed stopped. There was no error in your code to find.
23 June 2026
The broker went down during a race
The MQTT and WebSocket broker failed during a race weekend and stayed unavailable for several days. When it returned, concurrent connections were capped at ten per user. If that feed is wired straight into your lights, that weekend is simply gone, and you find out about it at lights out.
OpenF1 discussion #436None of this is a criticism of OpenF1. It is a free community project doing something genuinely hard, and we depend on it too. That is the honest version of the pitch: we are not selling you access to secret data, we are selling you the part where somebody else notices the announcement, ships the fix, and tests it before Sunday.
The two paths
Building it
- Free, plus your evenings
- A weekend to first yellow flag
- A season to get the edge cases right
- You own every upstream change
- Exactly the behaviour you want
- You learn a lot
Race RGB
- $10 once, for the season
- Minutes to first flag
- Every flag, plus fastest lap and team colours
- Upstream changes are our problem
- Per-flag colour, effect and hold time
- Free race weekend to try it first
When you should build it
The build is the hobby
If you want the project more than the outcome, nothing here should talk you out of it. This is a genuinely fun thing to build.
You want something we do not do
Driving a bespoke LED matrix, an e-ink timing tower, a physical semaphore, anything that is not a Hue, LIFX or Govee light. We only do bulbs and strips.
You need it inside Home Assistant proper
If everything must be a Home Assistant entity with its own automations and history, a native integration you control is the right answer. We drive the lights directly instead.
You only care about one flag
If all you want is red means red and nothing else, that genuinely is a short script. The complexity lives in the other flags, the timing and the season.
Common questions
Can I build F1 flag lights myself?
Yes, and plenty of people have. The usual build is a Python script against OpenF1 pushing colours to Philips Hue, LIFX or Govee, often wired into Home Assistant via MQTT. A basic version that turns your lights yellow under a caution is a weekend project. A version that survives a whole season, handles every flag correctly and matches your broadcast delay is a much bigger commitment.
What is the hardest part of a DIY build?
Not the lights. It is reconstructing the flag state, because there is no single field to read: you infer it from race control messages and track status, both of which have edge cases that only show up during a live session. The second hardest is broadcast delay, because it is different for every viewer and has to be calibrated rather than hardcoded.
Does Race RGB use OpenF1 too?
Yes, we read the same public feed a DIY build would. That is the point of this page: the data is not the moat, the maintenance is. When the upstream feed changes its auth or goes down mid-weekend, it is our problem to absorb rather than yours to debug on a Sunday.
Do I need Home Assistant?
No. Race RGB talks to Philips Hue, LIFX and Govee directly, with no automations, templates or YAML. If you already run Home Assistant it works alongside it on the same lights, and there is more detail on the Home Assistant page.
Should I still build it myself?
If the build is the point, absolutely, and we would rather say so. If you want your room to react this weekend and stay working for the rest of the season, buying it back costs less than one evening of your time.
Keep reading
Or just skip to the part that works
Every flag, fastest lap and the leader's team colours on your Hue, LIFX or Govee lights, matched to your broadcast delay. Free race weekend, no card required.