Philips Hue bez Bridge: Claude mi propojil světla s Macem a obrazovkou
Claude Opus 5.5 mi za jedno odpoledne a večer napsal aplikaci, která ovládá světla Hue z Macu přes Bluetooth, bez Bridge a bez kamery. Svítí podle obrazovky i podle stavu agentů. Na podstatné věci přišel sám.
Světla Philips Hue u mě teď ovládá Mac přímo přes Bluetooth. Bez Hue Bridge, bez cloudu a bez kamery namířené na monitor. Lampa na stole ukazuje, co dělají moji AI agenti, a celý pokoj umí svítit podle toho, co běží na obrazovce. Od střihu na obrazovce ke zhasnutí lampy uplyne 19 ms.
Takhle to vypadá naživo. Na monitoru hraje hudební video a celý pokoj se barví podle obrazu. Natočil jsem to telefonem 14. října kolem půlnoci, video je bez zvuku.
Napsal to Claude Opus 5.5 v T3 Code za jedno odpoledne a večer. Přijde mi to brutálně husté. Na podstatné věci přišel sám a já jsem nemusel rozumět Bluetooth ani tomu, jak spolu světla Hue komunikují. Hlavně to ale reálně funguje a dělá přesně to, co jsem chtěl.
Oficiální cesta by stála peníze. Synchronizaci s obrazovkou Philips staví na bráně Hue Bridge. Potřebuje ji aplikace Hue Sync pro počítač a bez ní zvládne nová kamera Play Screen Sync, která snímá obraz, jen jeden světelný pásek. Podle přehledu na GeekLife stojí Bridge Pro na Alze 2 499 Kč a kamera 119,99 €. Dohromady přes pět tisíc korun. Já jsem nekoupil nic, světla i Mac už jsem měl.
Co to u mě doma dělá
V pokoji mám pět světel ve třech zónách: lampu na stole, dva pásky v regálu a dvě lampy u postele. Aplikace běží na pozadí, sama se spustí po přihlášení do Macu a ovládá se v prohlížeči. Mobilní aplikace Hue funguje dál vedle ní.
Místnost a scény. Plán pokoje, zóny, jas, bílá a barvy. Scény Práce, Večer, Film a Noc, další si uložím z aktuálního stavu.
Nálady. Šest palet: Západ slunce, Oceán, Les, Neon, Polární záře a Oheň. Barvy putují pokojem od stolu přes regál k posteli, sousední světla spolu ladí a každé má trochu vlastní náhody, aby to nepůsobilo strojově. Jedna cesta paletou trvá od 20 minut po minutu.
Signály agentů. Když agent v T3 Code skončí, lampa plynule přejde do zelené a vrátí se. Když čeká na moji odpověď, svítí fialově a po pěti minutách připomene. Chyba je krátké červené bliknutí. V noci platí tichý režim.
Obrazovka. Lampa stojí vlevo od monitoru, a tak bere barvu levé poloviny obrazu. Regál a postel berou pravou. Tmavá scéna světla zhasne, černé pruhy u filmu a titulky se do průměru nepočítají.
Ambient posílá každému světlu jeden příkaz na krok a přechod mezi barvami udělá světlo samo, takže se Bluetooth nezahltí. V nejrychlejším tempu běžel 31 minut bez zaseknutí.
Z T3 Code aplikace jen čte stav vláken, nic do něj neposílá. Synchronizace s obrazovkou má vlastní záložku, kde se dá přiřadit každé světlo k levé nebo pravé polovině a doladit jas, sytost a plynulost. Snímá ten displej, na kterém se zrovna něco hýbe.
Druhé video je ze stejného večera. Klip má hlavně světlé scény, takže se pokoj spíš rozjasňuje a stmívá, než aby měnil barvy. Vpravo je vidět regál, který svítí podle pravé poloviny obrazu.
Jak na to Claude přišel sám
Práce běžela ve třech vláknech. Agent pracoval zhruba pět hodin, z toho synchronizace s obrazovkou a zrychlení zabraly necelé tři. Já jsem psal zadání a potvrdil pár povolení v macOS, pro Bluetooth a nahrávání obrazovky.
První zadání popisovalo hlavně, co má aplikace umět a co nesmí rozbít: nezapisovat do firmwaru, nesahat na párování a do T3 Code nic neposílat. Claude pak porovnal sedm způsobů spojení, každý na sto příkazech. Komunitní knihovna HueBLE se na macOS bez úprav vůbec nepřipojila. Vyhrál malý nativní program ve Swiftu, který připojí všech pět světel za 3 s. Pythonová varianta přes Bleak to zvládla za 13 s.
Zrychlení jsem zadal úplně obyčejně, tak jak mluvím:
Halá, chtěl bych po tobě, ať se zaměříš ještě na lepší odezvu těch světel, vlastně na to, když se nám něco děje na obrazovce. Ještě to prosím optimalizuj.
Nevím, jestli potřebujeme úplně takové vysoké rozlišení, jaké tam aktuálně máme. Chápu, že se z něčeho musí nějak vydedukovat průměr té barvy, ale zároveň si myslím, že těch 30 milisekund, které tam aktuálně máme, je poměrně hodně a šlo by to ještě o hodně snížit.
Chci, ať zkusíš nějaké různé další netradiční způsoby, které si myslíš, že by nemusely fungovat nebo které jsou nekonvenční, případně nějaké další věci, které tě napadnou. Teoreticky to můžeš zkusit řešit nějak přímo na bitové úrovni, aby to bylo co nejrychlejší, s co nejmenším objemem dat a co nejmenšími jednotkami, ve kterých můžeme vůbec jednat, aby to prostě bylo co nejrychlejší a ta světla mohla co nejrychleji odpovídat.
Případně to řešit i tak, jak rychleji posílat data přes Bluetooth, aby je ta světla mohla rychleji zpracovat. Zkus to nějakým způsobem víc reverse-engineerovat a přijít na způsob, jak to ještě zrychlit a snížit celkovou odezvu těch světel. Budeme počítat s tím, že počítač je vždycky v podobném místě od těch světel, takže optimalizuj pro aktuální stav a pozici počítače.
Prostě různé crazy nápady a code shenanigans.Ukázal jsem jen směr. Že má číst senzor v MacBooku nebo hledat v systému skrytý režim Bluetooth, v zadání nebylo. Na obojí přišel sám.
Nejdůležitější krok byl měřák. Claude zjistil, že senzor okolního světla v MacBooku jde číst z programu, a začal jím měřit, kdy se lampa opravdu rozsvítí. Ukázalo se, že světlo reaguje zhruba 30 ms po zápisu. Dřívějších 270 ms bylo jen zpoždění, se kterým světlo hlásí svůj stav zpátky. Bez senzoru by zrychloval naslepo.
Pak se pustil do rádia. macOS se světly mluví v intervalu 30 ms, takže každý zápis čekal až 30 ms, než ho rádio odvysílá. Claude prošel systémového démona bluetoothd, našel neveřejnou metodu setDesiredConnectionLatency a k ní skryté úrovně. Úroveň „midi v2“ nastaví 7,5 ms, nejkratší interval, jaký Bluetooth LE vůbec dovoluje. Všech pět světel ho přijalo. Rychlé spojení se zapíná jen během synchronizace s obrazovkou.
Od první zmínky o bluetoothd po změřený výsledek na všech světlech uběhla zhruba čtvrthodina. Měření si ukládal do souboru, takže se dá všechno zpětně dohledat. Tohle je dotaz na surová data ze stejného večera:
O kolik je to rychlejší
První verze synchronizace zhasínala lampu při střihu za 28 až 34 ms. Mně to pořád přišlo hodně, tak jsem chtěl víc. Tady je, kam se Claude dostal:
| Střih na obrazovce → zhasnutí lampy | 19 ms |
|---|---|
| Rychlejší zřetelná změna obrazu, 367 → 33 ms | 11× |
| Rychlejší cesta od zápisu ke světlu, 52 → 17 ms | 3× |
| Víc změn za sekundu na jedno světlo, 25 → 66 | 2,6× |
Zdroj: vlastní měření, senzor okolního světla v MacBooku, stolní lampa Hue, mediány, 14. 10. 2026
| Bez zkratky při střihu | 53 | střih čeká ve frontě zápisů |
|---|---|---|
| Se zkratkou, první verze | 34 | interval spojení 30 ms |
| Interval spojení 7,5 ms, dnes | 19 | syntetické snímky, 14 střihů |
Zdroj: vlastní měření, senzor okolního světla v MacBooku, stolní lampa Hue, mediány, 14. 10. 2026
Zkratka, díky které střih nečeká ve frontě zápisů, srazila 53 ms na 34. Zbytek přineslo rychlejší rádio.
| Interval 30 ms | 51,9 | výchozí v macOS |
|---|---|---|
| Interval 15 ms | 35,8 | skrytá úroveň „midi“ |
| Interval 7,5 ms | 16,9 | skrytá úroveň „midi v2“ |
Zdroj: vlastní měření, senzor okolního světla v MacBooku, stolní lampa Hue, mediány, 14. 10. 2026
Čtvrtinový interval zkrátil cestu od zápisu ke světlu na třetinu.
Co jsme měřili | Dřív → teď |
|---|---|
Zápis → viditelná změna světla | 52 → 17 ms, 3× rychleji |
Zřetelná změna obrazu, která není střih (90 %) | 367 → 33 ms, 11× rychleji |
Střih, zhasnutí lampy | 28–34 → 19 ms, o 44 % rychleji |
Střih, rozsvícení lampy | 33–44 → 25,5 ms, o 23–42 % rychleji |
Potvrzení zápisu od světla | 72 → 19 ms, 3,8× rychleji |
Rozptyl odezvy (nejrychlejší až nejpomalejší) | 19–149 → 10–27 ms |
Změn za sekundu na jedno světlo | 25 → 66, 2,6× víc |
Snímků obrazovky za sekundu (video na 144Hz monitoru) | 60 → až 94, o 57 % víc |
Krátký záblesk ve filmu (100 ms) | ukázal se ze 48 % → celý |
Celý vzhled (zapnutí, jas, barva) jedním zápisem místo tří | potvrzení 212 → 115 ms, ze tmy o 130 ms dřív |
K tomu přibylo nové vyhlazování, které zřetelnou změnu dožene během 30 ms a tlumí jen drobné kmitání, a zápisy, které nečekají na odpověď k předchozímu snímku.
Já jsem tipoval menší rozlišení a triky na úrovni bitů. Nepomohlo ani jedno a Claude to změřil. Průměr barev stojí 0,08 ms na snímek, takže menší rozlišení nic nezmění. Zápis má 16 bajtů a na vzduchu trvá 0,3 ms, takže menší objem dat taky ne. Strop teď dělá firmware světla, který od přijetí zápisu potřebuje zhruba 12 ms. Na Macu zbývají asi 2 ms.
Za rychlost se platí výkonem: snímač, služba a agent spolu berou zhruba 20 % jednoho jádra, dřív 15 %.
Co ještě chybí
Celý řetězec od skutečného filmu po světlo senzorem změřený ještě není, řádky se střihem jsou ze syntetických snímků. Netflix a Apple TV+ v Safari macOS snímat nedovolí. S Bluetooth sluchátky se rychlé spojení zatím nezkoušelo. Kód nikde zveřejněný není, běží jen u mě.
Účel mi to ale plní už teď. Nekoupil jsem Bridge ani kameru, nemusel jsem studovat, jak funguje Bluetooth, a mám aplikaci, která dělá přesně to, co jsem chtěl. A reálně to šlo udělat takhle jednoduše: napsat, co chci, potvrdit pár povolení a nechat agenta měřit, dokud nenajde, kde čas opravdu mizí.
Zdroje a další čtení

Nové články e‑mailem
Komentáře
Načítání komentářů…