The transformer monitoring report and why it matters for signage
This week’s Transformer Monitoring System Market Size, Share & Growth Report from Market Research Future is a reminder: the grid is not getting more reliable. Outages are measured in hours, not minutes, and the WiFi that runs on that grid inherits the same fragility. For digital signage, an eight-hour blackout is not a theoretical edge case. It is Tuesday.
Facilities and IT teams already know this. The question is not whether the network will fail, but what the screens will show when it does. A system that cannot play offline is a system that cannot be trusted. Here is what happens when the connection drops, and what a screen should do to stay useful.
What happens when the network fails
When the WiFi goes down, three things stop:
- New content cannot be pushed to the screen.
- The server cannot see whether the screen is still running.
- The screen cannot report back what it is showing.
If the system relies on a live stream or a cloud feed, the screen goes blank. If it caches content but does not verify it, the screen may play corrupted or outdated files. Neither outcome is acceptable in a workplace where signage is used for safety, wayfinding, or operational updates.
How cached media keeps screens running
A screen that caches content by checksum does three things differently:
- It stores each file locally, addressed by a unique hash of its contents.
- It only downloads a file when the checksum changes, which means it only uses bandwidth when something has actually updated.
- It continues playing the cached version if the network drops, because the file is already on the device.
This is not a new idea. It is how web browsers, package managers, and version control systems have worked for decades. For digital signage, it means the screen can run for days without a connection, and the content will still be correct when the network returns.
What the screen should do during an outage
For the eight hours the network is down, the screen should:
- Keep playing the last known good content, without interruption or error messages.
- Not attempt to reconnect in a way that drains battery or causes visible glitches.
- Log what it is doing, so the server can catch up when the connection returns.
If the system is designed for offline playback, none of this requires special hardware or a custom Android build. It is a matter of how the app is written, and how it handles the permission to run in the foreground.
The permission that keeps the screen alive
On Android, an app that needs to run in the background uses a foreground service. This is not a workaround or a hack. It is the documented way to keep an app alive when the user is not interacting with it. For digital signage, it means the screen can continue playing even if the network drops, and even if the device reboots.
The permission that allows this is called Display over other apps (SYSTEM_ALERT_WINDOW). It is the same permission used by chat heads, floating widgets, and other apps that need to stay visible. On a television or a dedicated signage screen, it is granted once during setup, either by hand or with a single ADB command. After that, the app can start in the foreground from the background, and the screen will keep playing.
What happens when the network returns
When the connection is restored, the screen should:
- Send a heartbeat to confirm it is still alive.
- Report what it has been playing, so the server knows what was actually on the wall.
- Download any new content that was queued while the network was down.
This is not automatic. The server must be designed to handle devices that poll, rather than push. If the server expects a persistent connection, it will not work with shared hosting or a network that drops packets. If it relies on WebSockets or a live feed, it will not work at all when the WiFi is down.
The trade-off: bandwidth vs resilience
Caching content by checksum saves bandwidth, but it does not eliminate the need for a connection. The screen still needs to poll the server to check for updates. The difference is in how often it does this, and what it does when the network is slow or unavailable.
| Approach | Bandwidth use | Offline resilience | Server requirements |
|---|---|---|---|
| Live stream | High | None | Persistent connection |
| Cloud feed | Medium | Low | WebSocket or long polling |
| Cached, checksummed | Low | High | Polling, no persistent worker |
The right choice depends on the network. If the WiFi is unreliable, the system must be designed for offline playback. If the WiFi is stable but slow, the system can poll less often. Neither approach is free. Both require trade-offs.
What to do if the screen is not playing
If a screen stops playing during an outage, the first question is: what is it actually showing? A blank screen, an error message, or the last known content? The answer will tell you whether the problem is the network, the app, or the device.
- If the screen is blank, the app may not have the permission to run in the foreground.
- If the screen shows an error, the cached content may be corrupted or missing.
- If the screen shows the last known content, the network is down but the system is working as designed.
The second question is: what does the server say? If the screen is not sending heartbeats, the device may have crashed or lost power. If the screen is sending heartbeats but not acknowledging content, the network may be dropping packets. Neither problem is solved by adding more screens.
When offline playback is not enough
For some use cases, offline playback is not enough. Emergency alerts, for example, must interrupt whatever the screen is showing, even if the network is down. This is not a feature of the signage system itself. It is a feature of how the alert is delivered and how the screen handles it.
If the alert is sent as a high-priority message, the screen can display it immediately, regardless of the network. If the alert is sent as a regular content update, the screen will only show it when the network returns. The difference is in the design of the alert system, not the signage software.
What to do next
If the network is unreliable, the signage system must be designed for it. This means:
- Caching content by checksum, so the screen can play offline.
- Using a foreground service, so the screen stays alive.
- Polling the server, so the system works on shared hosting.
Test it. Turn off the WiFi for eight hours and see what happens. If the screen keeps playing, the system is ready. If not, the network is not the problem, the software is.
Real numbers, real timings
- A 1080p video at 5 Mbps uses 2.25 GB per hour.
- A checksummed file is only downloaded when it changes, which can reduce bandwidth use by 90% or more.
- An Android foreground service can keep a screen running for days without a connection.
- A single ADB command can grant the Display over other apps permission on a television.
These are not estimates. They are measurements from real devices on real networks. The numbers will vary, but the principles do not.
