Projects

2023.09.01  /  Internal build, then tailored and deployed for several client sites

MSP Service Delivery Dashboard

Scraped BrightGauge dashboards with Selenium and cast them to office TVs through Chromecasts, on a local VM at each customer site.

Problem

Putting dashboards on office screens normally means a computer behind every screen, and the commercial tools that avoid that cost more than the job was worth.

Stack

Python

Selenium

BrightGauge

Home Assistant

Chromecast

Outcome

Rotating operational metrics on every screen at a site, driven from one local VM. A Chromecast per display instead of a PC per display. Tailored and deployed for several customers; five screens at our own office.

The cost of putting a dashboard on a wall

Getting metrics onto an office TV sounds trivial until you price it. The usual answer is a computer behind every screen: something to run a browser, stay logged in, and get rebooted when it stops. Multiply that by the number of screens and it stops being a small job. The commercial products that avoid it are priced per screen, per month, indefinitely.

Neither cost matched the size of the problem, which was: show the team the numbers they already look at.

Chromecasts instead of computers

The metrics lived in BrightGauge, which renders its gauges in a browser. So each screen needed something that could display a web page and be told what to show.

A Chromecast does that for the price of a cable. A Linux VM runs Python and Selenium, loads the BrightGauge dashboards, and Home Assistant casts them out to each display, rotating through the views on a schedule.

02

How it fits together

Service delivery dashboard: source to office screens Metrics live in BrightGauge, a hosted service. Inside each customer site, a local Linux VM runs Python and Selenium to load those dashboards, and Home Assistant casts them on a schedule to a Chromecast behind each office screen. The VM has to be local because Chromecast discovery only works on the same network. Everything inside the site boundary was deployed per customer; five screens shown here. 01 BrightGauge hosted · gauges render in a browser Customer site: one deployment each 02 Local VM Python · Selenium · on the site network 03 Home Assistant casts on a schedule one VM → every screen 04 Chromecast office screen 05 Chromecast office screen 06 Chromecast office screen 07 Chromecast office screen 08 Chromecast office screen
The VM has to be on the site network: Chromecast discovery does not cross it, so nothing central could drive the screens. That constraint is also what made it cheap: one machine per site casts to every screen there, and adding a screen costs a Chromecast rather than a computer.

Why the VM has to be local

Chromecast discovery does not cross a network boundary. A device announces itself on the local network and is cast to from the same network, so the machine driving the screens has to sit beside them. There is no central server that could have done this for every site at once.

That sounds like a limitation and is mostly the opposite. Each site ends up self-contained: nothing to route between networks, no VPN in the path of a wall display, and a site whose internet drops still shows the last thing it was given. One VM per site, and that VM only ever talks to things it can see.

There was no API to integrate with

BrightGauge did not expose one at the time. The gauges existed as a web page and nothing else: no endpoint to query, no export to poll, no supported way to get the numbers out except to look at them.

That settles the design question before it gets asked. Driving the real dashboard in a real browser was not the pragmatic choice over a cleaner integration; it was the only way in.

It had a side benefit worth keeping even if an API had existed. The screens showed exactly what people saw at their desks: same gauges, same thresholds, same layout. No second version to keep in sync, and no chance of the wall display and the tool quietly disagreeing about a number.

The cost is that browser automation breaks when a page changes, where an API contract mostly does not. For a display system whose failure mode is a stale screen rather than a bad decision, that was an acceptable trade.

What I would do differently now

The cheap Chromecast this was built on has been discontinued. Its replacement costs several times as much, so the hardware argument that made the original worth doing no longer holds for the same parts.

More to the point, the Selenium layer existed because BrightGauge rendered its gauges in a browser and gave me no other way in. Most dashboard tools now publish a read-only URL or a TV mode intended for exactly this. When the dashboard can hand you a link, the scraping layer has nothing left to do.

So today I would put a Raspberry Pi Zero 2 W behind each screen, running Chromium in kiosk mode against that URL. That removes the VM, Selenium, Home Assistant, and the constraint that forced the VM to be local, because nothing needs to discover anything on the network any more. Each screen becomes self-sufficient.

Worth being clear about why that is possible: the vendors added the feature I was working around. Browser automation was not a shortcut at the time, it was the only path from a tool that rendered in a browser to a screen on a wall. It stopped being necessary because the tools changed, which is the normal way this kind of work ages.

Where it ran

I tailored and deployed it for several customers, not just internally. Each site got its own VM, its own screen count, and the dashboards that mattered to that business. The delivery mechanism was the same; the metrics were not.

Our own office ran five screens from one VM. That ratio is the argument: five displays would otherwise have meant five computers to buy, log in, patch and reboot, or a per-screen subscription to a commercial product, forever.

All projects