Screen reports on the API include hardware and software health

Screen reports on API v4.1 (GET /v4.1/screens/reports) now return much more of what a player reports about itself. From your own tools, you can watch a fleet for an SD card or a disk that’s starting to fail, keep an eye on temperatures, or check which model and software a player runs, without opening each screen in the dashboard.

Storage:

• sd_card_health: errors on a Raspberry Pi’s SD card, and whether the card has turned read-only.
• smart_disk_data: a S.M.A.R.T. summary of the SSD or NVMe drive on an x86 player, including its temperature, power-on hours, and how much of its life is used.
• storage_info: the identity of a Raspberry Pi’s SD card: name, manufacturer, and date.
• disk_usage: total, used, and free space on the player’s data storage, in bytes.
• disk_stats: read and write counters for each disk since the player started.

Hardware:

• sensors: temperature and other sensor readings, such as a Raspberry Pi’s chip temperature.
• x86_stats: hardware temperatures on Screenly Player and Screenly Player Max.
• mem_info: total, free, and available memory, in kB.
• raspi_rev and raspi_serial: a Raspberry Pi’s board revision and serial number.

Software and security:

• installed_snaps: every software package on the player, with its version.
• device_model and validation_sets: the ScreenlyOS image a player runs, and the exact package versions it’s held to.
• secure_boot, full_disk_encryption, and mtls_enabled: whether the player uses secure boot, an encrypted data partition, and a client certificate for its connection to Screenly.
• is_wayland: whether the player draws through the newer display stack.

Display, network, and running state:

• display_data: each connected display’s make, model, size, and supported resolutions.
• screen_resolution: the resolution content is shown at.
• bluetooth: on, off, or unknown. off also covers a player with no Bluetooth at all.
• probe_diagnostics: the results of the player’s own network checks, refreshed about once a day.
• player_uptime: seconds since the player’s content started, which restarts once a day.
• local_time: the player’s clock when it sent the report.

Fields fill in from each player’s next report, and some apply only to certain hardware: a field a player doesn’t report is empty. These are additions, so existing responses keep every field they had.