What Styri does with /diagnostics
- Any component at WARN or ERROR (for example
/lidar_front) shows in the robot’s status line by name, with its message - The worst level rolls up into the robot’s overall status: ERROR makes it FAULT, WARN makes it WARNING. Components at OK or STALE don’t change it
- Each component that goes to WARN or ERROR, and back to OK, is written to the activity log
- The Topics tab shows the whole latest message, every component and key
- It can read the CPU temperature from a diagnostics entry into the CPU tile
Run it
$ docker run --rm --network host ghcr.io/styri-dev/styri-core:v0.3.1Open http://<robot-ip>:8080. Diagnostics appear automatically if your robot publishes /diagnostics. If it uses another name, map it in a styri.yaml with diagnostics: {topic: /your/diagnostics}.
Read the CPU temperature from /diagnostics
cpu_temperature:
topic: /diagnostics
status_name: cpu # which diagnostics entry
key: temp # which key in that entry
warn_above: 75
fault_above: 85Both names match case-insensitively and by part of the name, so cpu finds an entry called “CPU Monitor” and temp finds “Temperature”. To check it:
$ docker run --rm --network host -v "$PWD/styri.yaml:/etc/styri/styri.yaml:ro" ghcr.io/styri-dev/styri-core:v0.3.1 styri checkstyri check shows whether the entry and key were found, with the value it read. If not, it says which is missing, and the Topics tab shows the names to use.
Styri Core is read-only: it subscribes to /diagnostics and never publishes to the robot.