Troubleshooting
Device Reset Guide
A reset cuts power to one part of a Kuori unit and lets it start again. It is the remote equivalent of pulling a plug, and it fixes the class of fault where a component has stopped responding but the hardware is fine.
Resets act on real equipment at a real site. A reset during opening hours puts a screen out for the time it takes to boot. Read the rest of this page before you send one.
Where to find them
Two places, doing the same thing.
The Management tab on a device's own page has the same five as buttons, plus scheduling.
The rules
Three of them, and they matter more than knowing which button is which.
Send one reset at a time. After each one, wait five minutes for the component to restart before you decide whether it worked. Resets are only possible while the device is online.
When you do not know which one you need, work through them in this order and stop as soon as the symptom clears:
Mediaplayer → LCD Driver → Modem (if reachable) → Host → SMB
That order runs from the least disruptive to the most. The last two take the whole unit down for a boot cycle.
The five targets
Reset Mediaplayer restarts the separate media player computer that handles signage playback. Use it when content is stuck, playback has frozen, scheduled media does not start, or the signage software is not responding. Give the player time to boot and reconnect before you judge the result. This is the most common reset and the least disruptive.
Reset LCD Driver restarts the display driver interface between the media player and the screen. Use it when the display is black, flickering, frozen, showing artifacts, or otherwise visually corrupted while the device itself still looks like it is running. It targets the display path without rebooting the whole system.
Reset Modem restarts modem and router control to recover unstable connectivity. Use it only when the device is still reachable but the connection is poor, meaning high latency, intermittent drops, or unstable remote access. A device that is fully offline cannot be helped this way, because the command travels over the very connection that is down.
Reset Host restarts the SMB host, normally the Android board, and the DSM client running on it. Use it when the host side is unstable, the client is unresponsive, or the targeted resets above did not fix it. This takes the device offline for a while.
Reset SMB restarts the System Management Board, which controls core hardware functions such as the fans, the heater, reboot control, and temperature supervision. Use it when hardware control is not reacting normally, or the device seems electrically or thermally unstable. The SMB is also what performs the other four resets, which is why it comes last. It is the right move when the client reports SMB disconnected while the device is otherwise online, meaning the client is running but cannot reach the board.
Sending one
- Check the device is online. The status badges on the device page, or the Online dot in the list, tell you.
- Pick the target.
- Confirm.
DSM confirms that the command was sent. That means DSM handed it to the device, not that the reset worked. Wait five minutes, then check the device's Events tab and its status badges. An SMB reset shows up as an event naming the reason the board restarted.
Offline devices
Every reset is disabled for an offline device, and DSM says so rather than letting you click a button that would do nothing.
There is no way around this, and it is the right behaviour. A reset is a message to a device, and an offline device is not listening. If a device is offline and stays offline, DSM has done what it can and the site needs a visit.
Scheduling a reset
Under Scheduled commands on the Management tab, New schedule sets a reset to run at the same time every day.
Pick a time and a reset command type, then save. A nightly media player reset is a reasonable way to live with a player that drifts over a few days.
The schedule runs on the device's own timezone, which the tab shows above the button. If that timezone is wrong or unset, fix it on the Settings tab first. A schedule set to 03:00 against the wrong timezone will reset a screen in the middle of the trading day.
Schedules can be saved for an offline device. They start once it reconnects.
Scheduled commands need client version 0.4.20 or newer, and they are not available on Windows devices. DSM tells you when the client is too old.
Which reset to try
When the symptom points somewhere specific, start there rather than at the top of the order. Wait five minutes after each attempt before moving to the next column.
| Symptom | Try first | Then |
|---|---|---|
| Content stuck or frozen, playback not starting | Reset Mediaplayer | Reset Host |
| Display black, flickering, or showing artifacts | Reset LCD Driver | Reset Host |
| Connection poor, latency high, dropping in and out | Reset Modem | Reset Host |
| DSM client unresponsive, host unstable | Reset Host | Reset SMB |
| Device online but SMB disconnected | Reset SMB | Site visit |
| Fans, heater, or temperatures behaving oddly | Reset SMB | Site visit |
| Device fully offline | Nothing. Resets need the connection | Site visit |
When a reset is not the answer
Repeat resets on the same device are a symptom, not a fix. If a unit needs a daily reset to stay usable, log it in the device's Notes and raise it with Kuori. The Display health tab and a per-day Offline report will show you the pattern, and that pattern is what makes the case for a hardware swap.
A reset also cannot help with content. If the playlist is wrong, resetting the media player reloads the same wrong playlist.
Firewall rules and encryption (DSM)
Use this guide to diagnose connectivity problems between a device and DSM. Most connection failures trace back to blocked outbound traffic, DNS/NTP issues, or overly restrictive network filtering.
Quick Checklist
Before digging deeper, confirm the basics:
- Device has general outbound internet access
- Required ports below are open outbound
- DNS resolution is working
- Device clock is in sync (NTP)
- No IP/domain whitelisting is restricting traffic
- MDM-specific firewall rules are in place
- Any third-party apps on the device have their own required ports open
1. Check Core DSM Firewall Rules
DSM requires the following outbound rules. If any of these are blocked, the client will fail to connect.
| Address | Protocol | Port | Purpose | Symptom if blocked |
|---|---|---|---|---|
api2.kuori.com |
TCP | 443 | HTTPS REST calls | Client can't reach API, requests time out or fail |
api.kuori.com |
TCP | 443 | WebSocket (WSS) | Client connects briefly but loses real-time/live connection |
| DNS servers | UDP/TCP | 53 | Name resolution | Client can't resolve kuori.com hostnames at all |
| NTP servers | UDP | 123 | Time synchronization | TLS handshake fails or auth errors due to clock drift |
How to check: Test outbound connectivity from the device/network to each address and port (e.g. curl, telnet, or a port-check tool). If DNS resolution fails, verify port 53 is open and a working DNS server is reachable. If TLS handshakes fail intermittently, check the device clock against NTP.
2. Check MDM-Specific and android rules
The MDM solution in use has its own required firewall openings, separate from the DSM rules above. If the MDM agent itself can't connect, DSM enrollment/management may also fail.
- MDM firewall rules: If you are using some other MDM than Kuori Mobile Management(KMM) you need to check their firewall rules, but for KMM they can be found from here: KMM Firewal rules
Also confirm outbound access is allowed per Android Enterprise requirements, since MDM device management relies on Google-managed services:
3. Rule Out Overly Restrictive Network Filtering
A common root cause of intermittent or unexplained connection failures is IP-based whitelisting.
IP address–based whitelisting is not a viable approach for Android-based devices, and is a frequent cause of connectivity problems that "used to work" and then broke.
Why this happens:
- Devices depend on Google Play and other Google-managed infrastructure, which runs on large, dynamic, globally distributed cloud networks.
- These services' IP addresses change frequently and cannot be reliably predicted or restricted to a fixed range.
- If an allowlist of IPs was configured, it will inevitably go stale as addresses rotate — causing app updates, authentication, or background services to silently fail.
If you suspect this: Check whether any firewall/proxy rule is restricting outbound traffic to a specific IP range rather than by port/protocol. If so, replace it with rules based on the ports and domains above, and allow general outbound internet access rather than an IP allowlist.
4. Check General Network Configuration
- Outbound traffic should be allowed as per the DSM, MDM, and Android Enterprise requirements above.
- Outbound NTP requests must be allowed.
- Inbound traffic should be blocked except where explicitly required (DSM does not need inbound access).
- Devices should sit within a dedicated IoT VLAN or physically isolated network — confirm the device hasn't been placed on a segment with different (more restrictive) rules.
- If egress filtering is in place, check its logs for blocked outbound attempts from the device — this is often the fastest way to spot the exact rule causing the failure.
5. Check Encryption / TLS Requirements
- TLS 1.3 is required for all WSS and HTTPS connections. Older TLS versions or a network appliance forcing a TLS downgrade/inspection can break the handshake.
- DSM uses API key and device ID pairing for authentication — confirm both are correctly provisioned on the device; an invalid pairing can look like a "connection" failure even when the network is fine.
6. Check Third-Party Applications on the Device
If other applications on the device also seem to have network issues, they may have their own port/endpoint requirements that are separate from DSM's.
Example — TeamViewer:
| Type | Port(s) |
|---|---|
| Outbound TCP | 5938 (primary), 443, 80 |
| Optional UDP | 5938 |
TeamViewer (and similar apps) use dynamic cloud servers, so IP whitelisting will likely break them too. Evaluate each third-party application individually and allow its required outbound ports rather than restricting by IP.
Summary: Most Likely Causes, In Order
- A required port (443, 53, or 123) is blocked outbound.
- IP-based whitelisting is in place and has gone stale or is blocking dynamic Google/cloud IPs.
- MDM-specific firewall rules haven't been applied (see internal KMM link above).
- Device clock is out of sync (NTP blocked), breaking TLS handshakes.
- Device is on the wrong network segment/VLAN with different rules applied.
Display Status
Overview
This document describes the inputs used to monitor display backlight status, how they relate to each other, and how DSM (Display Status Monitor) generates alerts from them.
Inputs
| Input | Source | Single display | Dual display |
|---|---|---|---|
| bl1_enable | Controllers page | Used | Used |
| bl2_enable | Controllers page | Not applicable | Used |
| bl1 (backlight brightness) | Controllers page | Used | Used |
| bl2 (backlight brightness) | Controllers page | Not applicable | Used |
| LCD1Status | Sensors page | Used | Used |
| LCD2Status | Sensors page | Not applicable | Used |
- bl1_enable / bl2_enable — on/off flags for each display's backlight, read from the Controllers page. A single-display unit only has bl1_enable; a dual-display unit has both bl1_enable and bl2_enable.
- bl1 / bl2 — backlight brightness values for each display, also read from the Controllers page.
- LCD1Status / LCD2Status — Sensors page values indicating whether each display's LCD controller is enabled. A single-display unit only has LCD1Status; a dual-display unit has both LCD1Status and LCD2Status.
Alert generation
DSM generates alerts based only on the backlight brightness values, bl1 and bl2. If either bl1 or bl2 drops to 0, DSM generates an alert for that display.
The alert text names the affected screen: bl1 = 0 shows "Screen 1 is off", and bl2 = 0 shows "Screen 2 is off".
DSM does not evaluate bl1_enable, bl2_enable, or LCD1Status/LCD2Status directly when deciding whether to raise an alert — but as described below, bl1_enable and bl2_enable can force bl1/bl2 to 0, which then triggers the alert indirectly.
Backlight enable behavior
bl1_enable and bl2_enable also control the physical backlight, separately from what DSM watches for alerts:
- bl1_enable (or bl2_enable) goes from 1 to 0.
- The backlight for that display is turned off.
- The corresponding brightness value, bl1 (or bl2), is also set to 0.
- Because bl1/bl2 is now 0, DSM generates an alert for that display.
So a bl1_enable/bl2_enable transition to 0 always produces an alert, but by way of forcing bl1/bl2 to 0 — the alert itself is still keyed off bl1/bl2, not off the enable flag.
Typical causes for bl1_enable/bl2_enable going to 0: the upstream picture source (e.g. a media player) crashes, goes to sleep, or intentionally turns the display off.