Repository navigation
Operating the System
After connecting, the dashboard opens the first saved location when locations exist. All shows compact read-only sensor tiles. Location tabs show readings and charts for assigned devices. Configuration & Setup is used for pairing, inventory, locations, device setup and supported controls. The System tab presents host/database health and the history retention controls.
Presentation profiles are selected at the top right and can keep separate layouts and display preferences. They are session-style convenience profiles, not accounts: there is no per-user login or authorization boundary, and all profiles share devices, locations and data.
The Starlink tab shows read-only data from the local router and dish APIs.
Configure each target independently under Configuration & Setup → Starlink;
the usual defaults are router 192.168.1.1:9000 and dish
192.168.100.1:9200. Install the optional gRPC/protobuf runtime in the
dashboard service's Python environment and restart that service if it was not
already installed. Enable only the endpoint you want to monitor.
Dish readings are supplied by terminal firmware and may be partial. A missing field is shown as unavailable; it does not mean zero, and it does not by itself mean the connection failed. Throughput is actual traffic at the sample time, not a speed test or maximum capacity. The dashboard stores samples locally for trend charts. Use the Starlink monitoring guide for troubleshooting and exact collection limits.
Open the time-limited pairing window from Configuration & Setup, then put one device into pairing mode according to that product's instructions. Confirm that the gateway has registered it and discovered the expected endpoint and clusters. Avoid resetting already paired devices as a routine troubleshooting step.
Battery sensors may sleep. Keep them near the gateway during setup and wake them only as directed when a configuration operation is pending. The sensor reporting workflow shows acknowledgements/readback where supported. A successful manual read proves a value can be read at that moment; it does not prove automatic reports are arriving. Confirm unsolicited reports over time.
The dashboard records reports and deliberate reads with their source and receipt time where known. A chart can contain gaps when the device does not report, the gateway is offline, or ingestion is interrupted. The stale indicator reflects age against the device freshness setting; it does not itself diagnose a failed sensor. Signal strength is passively recorded when available and is not a complete mesh-route map.
For diagnostics, compare gateway readiness, device last contact, latest measurement age, report origin and the dated hardware-validation record. Do not repeatedly wake a sensor and treat those manual reads as proof of recurring reports.
The supported S60ZBTPG profile exposes the documented relay, electrical readings and selected settings. Read current state/settings before changing them. Remote switching changes the physical load, so verify what is connected before sending On or Off. Overload settings and other vendor-specific controls apply only where the UI identifies the exact supported plug.
If the dashboard is stale, check the Pi service and database first, then gateway Wi-Fi/API health, then Zigbee device reporting. Use the operations guide for logs and recovery procedures. Avoid simultaneous router, gateway and device resets: staged checks help identify which link failed. A mains-powered Zigbee plug can act as a router, but verify device behavior rather than assuming a sensor has selected it.