Hi everyone, hi @pierre-gilles,
Here’s an idea I’d like your opinion on before going any further: the ability to compose a dashboard card from several elements (values, gauges, charts) chosen from any Gladys devices.
The Observation
Today, one widget = one function. To monitor a room, for example, I stack:
- a « Room Temperature » widget for the current value,
- a « Chart » widget for the history,
- a « Gauge » widget for humidity.
That’s three cards, each with its own title, margins, and empty space, for information that goes together. On mobile especially, you quickly scroll through a lot of screen for little information.
(I know the Chart widget already displays the last value and the variation above the curve: it covers the simplest case, but not the mixing of several devices or several types of display.)
What This Would Allow
Some concrete examples:
- One Room, One Card: temperature and humidity in tiles, 24-hour temperature curve below.
- Energy: instant power gauge + weekly consumption chart.
- Comparison: two side-by-side charts (indoor/outdoor temperature, solar production/consumption).
- Heating: setpoint, measured temperature, and valve state in tiles, with the history of the measured temperature.
- Outdoor: a few values from the weather station + the rain curve.
Why I Didn’t Do It with an External Integration
I looked to see if the widgets from external integrations (Gladys 5.1) could serve this purpose, since their format already has almost everything: a row of tiles (value, gauge), a chart linked to the history of devices, text…
But two things prevent it, and it’s normal:
- An integration widget can only reference its own devices. The core ignores any device from another integration (a chart that references one is removed entirely). This is a deliberate isolation, and I find it healthy.
- Only one main element per card (chart, list, or image), in an order fixed by the core: no side-by-side charts.
The only possible workaround would be an integration that reads Gladys’s API with an API key to return « flat » data. It would work, but without real-time updates, with a full-access key in a third-party container and against the spirit of isolation. I don’t want to go down that path without your opinion.
Two Possible Approaches
Approach A — a Native « Composite » Widget (my preference)
A new type of widget in the core, whose editing consists of adding blocks:
- possible blocks: value, gauge, chart (reusing existing widgets);
- simple layout: one or two columns, blocks stack in the chosen order;
- each block points to any device functionality, via the same selector as current widgets.
Advantages: nothing leaves the core, no new security questions, real-time via websocket like other widgets, and the code of existing widgets can probably be largely reused.
Approach B — Allow Integration Widgets to Reference User-Selected Devices
A widget setting of type « device » that would offer all devices (and not just those from the integration). The user would explicitly agree, device by device, when configuring the widget.
Advantage: the community could publish all kinds of layouts without touching the core. Disadvantage: it opens a breach in isolation, since an integration could read data that isn’t its own. And it doesn’t solve the limit of one chart per card.
The Implications I See
- Performance: a card with multiple charts makes as many history requests. A limit (for example 4 blocks, 2 charts) would keep things reasonable, especially on Raspberry Pi.
- Mobile: two side-by-side columns should probably switch to a single column on small screens.
- Editing: the form of a composite widget is more complex than that of other widgets. It must remain easy to use.
- Maintenance: Approach A adds a widget type to maintain. Approach B shifts this work to integrations but touches the security model.
- Compatibility: both approaches are additive. No existing widget changes.
My Questions
- Does the need resonate with you, and would you see this in the core?
- Approach A, Approach B, or something else (for example, simply allowing the Chart and Gauge widgets to display multiple values)?
- Is the isolation of integration widgets a principle not to be touched?
If Approach A suits you, I’d be happy to take care of the PR, following your guidelines on the scope.
Thanks!