Solution Dashboard Template

Frozen pattern for Autoconnecto fleet / solution dashboards (EnergyFleet is the reference implementation). Use this for every future domain fleet (temp, machine, HVAC, etc.).

Related:

• Dashboards Overview
• Dashboard Page
• Device Count Widget
• Device Table Widget
• Alarm Summary Widget
• Navigation Button Widget
• Solution Entity Header Widget

---

Spine (one dashboard, five states)

State ID	Purpose	Typical widgets
default	Fleet home — situation awareness	Device counts, alarm severity summary, alarm table
list_active	Find active devices	Back nav + filtered device table
list_inactive	Find inactive devices	Back nav + filtered device table
list_all	Browse all devices in scope	Back nav + filtered device table
detail	Operate one selected device	Back nav + entity header + telemetry / alarms

Rule: one domain per dashboard (e.g. energy_meter only). Do not mix unrelated device types on the same home.

Navigation:

• Counts → corresponding list_* state
• Table row / alarm click → detail + selected entityId
• Breadcrumb / “← Fleet home” → default

Do not put ACL / authorized-user lists on the live home. Access control stays in platform sharing / tenant settings.

---

Standard checklist (8 items)

1. Breadcrumb / back

• Use DashboardPage chrome (not canvas widgets): Fleet home link + breadcrumb when currentState !== default.
• On detail, breadcrumb includes the selected device name.
• Do not add redundant navigationButton / entity-header widgets for this — they look like placeholders next to the real header.

2. Selected device context (detail)

• Selected entity name is shown in the page breadcrumb when drilling down.
• Detail telemetry widgets bind a dashboard-state alias so they follow list/alarm selection.
• Optional: link to device settings from the entity selector / device pages — keep ops canvas free of duplicate header cards.

3. Alarm severity chips (default)

• Use widget type alarmSummary above the alarm table.
• Scope with deviceFilterMode: DEVICE_TYPE + the solution’s device type.
• Keep Critical / Major / Minor / Warning breakdown visible.

4. Empty / waiting states

• Detail telemetry widgets: Select a device when no entity is selected (waiting_for_entity).
• Device tables: filter-aware empty copy (e.g. “No inactive energy_meter devices”).

5. Time window convention

• Dashboard time_window: realtime, 1 hour window (windowSizeMs: 3600000), refresh ~10s.
• Widgets use timeSource: "dashboard" so home and detail share the same clock.
• Per-widget historical overrides are allowed on detail only when needed.

6. Standard state IDs

Always reuse these IDs across solutions:

default | list_active | list_inactive | list_all | detail

Display names may differ (“Fleet home”, “Meter”, …); IDs must stay stable for nav targets and device retargeting.

7. Device retarget rule

For every device of the solution type:

• target_dashboard_id = this solution dashboard
• target_state_id = detail

Row click / device open then lands on the detail state with entity context.

8. Mobile order

Set config.mobile.order so phone layout reads:

1. Home tiles (counts)
2. Alarm severity
3. Alarm table
4. List back + table
5. Detail: back → header → KPIs → charts → alarms

---

Widget map (reference)

Layer	Widget types
Home counts	deviceCount → list_*
Home severity	alarmSummary (device type filtered)
Home alarms	alarm → detail + entity
Lists	deviceTable → detail (back via page chrome)
Detail chrome	DashboardPage breadcrumb + selected entity name
Detail data	KPI / value / analog / multitimeseries / deviceAlarm via dashboard-state alias

Detail widgets must use the dashboard-state alias (__dashboardState__ / selected entity). Do not hardcode a single device ID on detail widgets.

---

Explicitly avoid

• ACL / user lists on Home
• Mixing monitor + control (relays) on Home — put control on detail or a separate Control state
• Every device’s charts on Home (does not scale)
• Multiple dashboards for the same drill-down path (prefer one dashboard, many states)

---

Reference implementations

Solution / dashboard	Device type	Detail focus
EnergyFleet	energy_meter	3-phase power / voltage / current — reference stack
ClimateFleet	ht_sensor	Temperature + humidity — reference stack

Device profiles + alarm packs

Fleet alarms belong on device profiles (not on the dashboard):

Profile	Devices	Seed
Multispan Modbus Energy Meters	energy_meter (e.g. avh1)	_seed-fleet-alarm-profiles.js
HT Climate Sensors	ht_sensor (e.g. ht1, ht2)	same script

Energy pack includes no-data, per-phase L–N / L–L voltage, current, power, PF, frequency, MD, phase-loss, plus [Control] attribute stubs for future relays/breakers. HT pack includes no-data, high/low temp & humidity, comfort band, plus HVAC/door control stubs.

Seed / reset (local):

node backend/scripts/_seed-energyfleet-dashboard.js
node backend/scripts/_seed-climatefleet-dashboard.js
node backend/scripts/_seed-fleet-alarm-profiles.js

ClimateFleet seed also upserts both fleets into the Solutions catalog so tenants can Use solution → copy into their dashboards. On Use (POST /api/solutions/:id/use), widget targetDashboardId / fallbackTargetDashboardId self-references are rewritten to the new dashboard id, and seed/foreign device IDs are cleared from aliases so the copy waits for the tenant's own devices. Solution preview remaps aliases to that tenant's lazy demo devices.

---

Cloning for a new domain

1. Copy the five state IDs and nav rules above.
2. Change device type filter everywhere (deviceCount, deviceTable, alarm, alarmSummary).
3. Replace detail telemetry keys / units for that domain.
4. Retarget devices of that type to the new dashboard + detail.
5. Keep home free of admin/ACL widgets.
6. Publish to Solutions (title, description, icon, dashboard_config_json) so users can copy from the catalog.