A new setting or image is queued as a job and the screen takes it at its next check-in. A screen asleep in Sleep mode is woken for it; in Deep Sleep both radios are off, so nothing can reach it until its timer fires. Each screen's page shows its queue.
Details
Radios
Settings
Quick control
Read by the screen's app with plain getter calls — no panel change, so it costs no battery waveform. It runs by itself every 6 hours; Read now queues one for the next check-in. n/a = this firmware does not have that call; a refusal is shown with the firmware's own error.
| # | Job | What changes | Status | Saved |
|---|
Recently applied and cancelled
| # | Job | What changed | Status | When |
|---|
A change is a job: it waits here until the screen checks in and takes it. Saving again before then updates the same job; Cancel takes it out of the queue and the screen keeps what it has. Pending = it goes as soon as possible (the screen is awake, or asleep and listening so it is woken for it). Waiting = nothing can reach the screen until its own timer fires. Sent = the screen has taken it and is running it; Applied = the screen reported back from that wake.
| What | Screen says (MDC) | Agent last said | Bytes |
|---|
Control (admin)
Sleep mode and auto-sleep are not here on purpose: they belong to Settings, which sends them through the screen's app so the console always knows what the screen is running. Factory reset, network and secure-mode changes are blocked even in raw mode.
Recent MDC requests
| # | What | Status | By | When | Reply |
|---|
MDC is the display's own control protocol. It only works from the screen's local network, so a small bridge program on a PC there carries each request and brings the raw reply back. It only answers while the screen is awake. Reading is on demand only: every MDC message restarts the screen's idle countdown, so polling it would keep a sleeping screen awake and distort the battery figures. spec = meaning from the firmware or the official app; bench = matched on a test screen; values without either are shown as bytes.
On the screen
The image above is the one this screen was sent, with what the screen reported back about drawing it. The screen also takes its own capture at the end of every content change — it is folded into the wait the panel already needs, so it costs about a second — but on an ePaper that capture is 640×360 from a 4:3 panel, heavily aliased and black over its lower half, so it proves the app drew something and nothing more. This button forces one on a wake that changed nothing, which costs about 35 seconds. For a real picture of the panel, use a camera.
Assign content
Delivery log
- assign an image to watch it arrive
| Wake | Started | Awake for | Records |
|---|
| Server time | Device clock | Wake | What | Detail |
|---|
The server time and the device clock will not match. The device clock runs fast while the screen sleeps, which is why both are recorded.
Images are resized for each screen size automatically. Assign one to a screen from that screen's page.
| Device | Arm | Wakes | Awake (median) | Awake (max) | Battery | Per day | Days left | Signal | Offline records | Screen updates |
|---|
Awake time is measured by the server from the first to the last message of each wake. It is the number that decides this test: time awake costs far more battery than updating the picture.
| Role | Company | Added |
|---|