28 lines
3.8 KiB
Markdown
28 lines
3.8 KiB
Markdown
# Gladacres production diagnostics
|
||
|
||
Verified October 21, 2026. Site https://www.atomhmi.com/site_gladacres/; site ID gladacres. Device barn / Barn. Device Status page: /site_gladacres/page_device_status. Cross-site dashboard: /site_atom/page_devices, Gladacres / Barn (barn).
|
||
|
||
## Investigation: diagnostic readings initially blank
|
||
|
||
The user reported registers not loading. The Atom dashboard initially showed stale uptime and missing CPU/IP readings. Manage Registers initially displayed blank values for all 30 rpi_ entries despite Enabled Yes. This initial table was not reliable evidence that the device had no values: the native Device Status page subsequently populated CPU, disk, memory, IP, firmware, HMI and Node readings, and the cross-site dashboard subsequently populated too, without any saved configuration changes.
|
||
|
||
Observed Device Status readings included 1500 MHz CPU clock, 63.7 °C CPU temperature, 31% CPU usage, 7903 MB disk used / 101005 MB available / 8%, 374 MB memory used / 1492 MB available, HMI 1012 and Node 20.2. Local/tunnel IP fields also populated; addresses are omitted from this guide. Uptime was about 227 days. These are dated snapshots, not limits or guaranteed current values. The dashboard's uptime timestamp was roughly 2–5 minutes old across observations, correctly exceeding its 120-second Recent threshold. No persistent complete diagnostic outage was reproduced, but the reason for delayed uptime reporting was not established.
|
||
|
||
## Verified configuration
|
||
|
||
Barn has calculator, modbus_localhost and terminal sources. Inspected Terminal: ID terminal, type Terminal, configuration {}. Closed without saving. All 29 standard diagnostic/maintenance definitions plus rpi_upload_logs exist and are enabled. Read the full current definitions using native Advanced import validation with [] and Delete Unused OFF; insert/update/delete were all empty, and the audit dialog was closed without Submit.
|
||
|
||
- rpi_uptime: awk '{print $1}' /proc/uptime; ON_CHANGE, 10 seconds.
|
||
- rpi_service_uptime: existing systemctl/date age command; ON_CHANGE, 10 seconds.
|
||
- rpi_atom_hmi_version and rpi_model: ON_CHANGE, 60 seconds.
|
||
- CPU, disk, memory, firmware, IP and throttling/voltage readings: ON_CHANGE, 600 seconds. Node version retains its existing 3600-second interval.
|
||
- rpi_atom_hmi_update, rpi_reboot, rpi_restart_service and rpi_upload_logs: DISABLED automatic polling. None were triggered. Upload Logs sends data externally and must not be used as a casual read-only diagnostic action.
|
||
|
||
Several older definitions include address.priority:0. Existing disk commands select /dev/root, and model detection uses /proc/cpuinfo Hardware. Despite those older forms, this inspection observed working disk/model readings; they were not replaced speculatively. The dashboard backup's Gladacres expressions consistently target gladacres:barn:rpi_*; the working dashboard readback supports that mapping. No wrong-device binding was demonstrated.
|
||
|
||
## Outcome and remaining question
|
||
|
||
Read-only investigation only: no page/register/slave/recording settings saved, no update/restart/reboot, no uploaded logs and no PLC writes. Readings appeared on both native and cross-site pages during the investigation. Slow first-load population and 600-second metric polling should be distinguished from absent definitions. The 2–5 minute age seen on uptime remains unexplained despite a configured 10-second interval; do not label a connection/agent/network cause as proven. If it persists, a device-side polling/publishing/log investigation is the next step; no such logs were collected here.
|
||
|
||
Local evidence: /tmp/gladacres-register-definitions-before.json (current definition audit), /tmp/gladacres-device-status-readings.jpg, /tmp/gladacres-dashboard-loaded.jpg. These are local artifacts, not synchronized through Git. Do not commit raw network addresses, logs or credentials.
|