One team, several panels: three perspectives on the same operation

A panel is a view built from widgets that read data from the variables. None is mandatory: you can have several panels at once, each with a different perspective on the same operation. That sentence opens the manual’s panels page, and it sums up a design decision.

The most common way to build a panel is by variable type: temperatures here, humidities here, outputs here. The useful way is by question. If the question is “now”, a gauge; if it is “what happened”, a dynamics chart; if it is “how much”, an accumulator; if it is “what to attend to”, alarms or tasks. A team does not have one question: whoever is on the floor, whoever pays the bills and whoever answers for each lot ask different things, at different moments, from different screens.

Panels belong to the organisation. What one member creates is available to everyone else. So the right question is not “which is the panel”, but “which are the three or four panels this team needs”.

The pieces

Growcast ships fifteen widget types. The manual groups them by the question they answer.

• Current state: analogue gauge (current value with range and colour zones, with optional alarm lines), live output (whether an output is active now, how long it has been on, its percentage of time on and its consumption in the period) and hardware status (the tree of devices and modules with their connection and alarms, as an illustration or as a list).
• Temporal: dynamics (one or several variables charted over time) and last activations (a chronological list of an output’s state changes).
• Consumption: accumulator (the accumulated total of a variable in the period; for outputs with an operating characteristic, kWh, litres or doses) and supply consumption (bars or a table per supply according to the tasks carried out).
• Traceability: cycle Gantt, cycle comparison (cards or radar, aligned by production day) and cycle monitor (the card of an environment’s active cycle).
• Operation: active alarms with an acknowledge button, tasks in a kanban and a mini calendar.
• Forecast: a one-hour forecast of a variable, in demo mode today.

The widgets that look back have their own period: 1, 12 or 24 hours. The traceability and supply consumption widgets do not look at a period but at a cycle: they aggregate what happened since the lot entered the environment. The grid has twelve columns on desktop, eight on tablet and two on phone, and each widget’s size is saved separately for the three, so it pays to review the panel at the width it will be looked at.

With that, three panels.

Panel 1: “Now”, for whoever is on the floor

Whoever uses it is standing, phone in hand. They open it twenty times a day and each time have a single question: is anything wrong? They have to read the answer in two seconds and get back to what they were doing.

The widgets, in reading order:

• Hardware status, at the very top. One glance says whether the device and each module are online. If a module is down, none of the numbers beside it is valid, so this is the first reading.
• Two or three analog gauges: temperature, humidity, CO₂ or substrate moisture. Each shows the current value, the period’s minimum, average and maximum, and its curve with the alarm line drawn where it fires.
• A dynamics chart with analog and digital variables: temperature, humidity, CO₂ and an output’s state on the same axis. It is where the activations are seen in context: when the equipment acted and what the variable did next.
• Active alarms, filtered to this environment, with the acknowledge button. It sounds once, clearly, and stays pending until someone acknowledges it. The normal state is an empty card.
• Digital gauges for the ventilation and the pump. On or off now, since when, and how long they were on today. It is the widget that confirms the automation did what it had to do.

What this panel does not have is as important as what it has. No 24-hour dynamics, no consumption, no cycle comparison. All of that answers “what happened”, and on the floor the question is “what is happening”. The manual says it in one line: aim for 6 to 8 widgets per panel and create several panels rather than a giant one.

On the phone the grid has two columns: hardware status and outputs take the full width and gauges go two by two. It pays to arrange that order from the phone itself, because the small-screen size is saved separately.

Panel 2: “How much”, for whoever pays the bills

This one is looked at by the owner, or whoever keeps the costs, from a desk, once a day or when a cycle closes. They do not care whether the extractor is on now. They care how many hours it was on, how much water went through the pump and how much supply was applied, and whether that matches what was bought.

The widgets:

• 24-hour digital gauges on climate control, ventilation, the pump and the dehumidifier, with the operating characteristic set on each output. Each shows how long it was on in the day and the consumption that implies: time on multiplied by nominal power gives kWh; by flow rate, litres. Without a meter in the board.
• Read by the percentage of time on and not by the current state. A dehumidifier on 80 % of the day is a question about the environment’s envelope, not about the dehumidifier.
• Supply consumption in table view, product and amount, filtered by task type and by environment. It aggregates the completed tasks of the active cycle: the water recorded in each wash or irrigation, and the supplies applied in treatments, disinfection and cleaning, computed from each task’s dose and volume.
• A 24-hour dynamics chart of the variable that costs most to hold, for instance humidity. Seeing the daily profile next to the dehumidifier’s hours shows whether the problem is the unit or a door left open.

There are two sources of consumption on this panel, and it is worth having them together on purpose. The digital gauge derives consumption from the hardware: time on multiplied by the characteristic. Supply consumption takes it from what the team recorded in tasks. When the litres the pump delivered according to the gauge do not match the litres recorded in the tasks, it is one of two things: a task that was not recorded, or a flow rate on file that is no longer the real one. Both are worth discovering, and this panel discovers them on its own.

For the week’s or the month’s total, the place is not the panel but the lot and cycle reports, which condense the same sensor, task and consumption statistics over a closed period. The panel answers “how much today”; the report answers “how much in total”.

Panel 3: “How is each cycle going”, for the head of production

Whoever uses it answers for lots, not for environments. They look at it every day, but not on the floor: in the office, with time to compare. Their question is whether this cycle is going like the best one they had, and whether the planned work is getting done.

The widgets:

• Cycle Gantt by environment, at the top. Each bar is a lot in an environment, with its stage, its production day and its estimated duration. It is the season’s map in one row.
• Cycle comparison in radar view. The active cycle against a reference cycle, aligned by production day and not by calendar date. The radar shows in which variables the shape departs, and the similarity score sums it up in a number from 0 to 100. After a bad result, “where did we drift from the good cycle?” is answered by looking at the figure.
• Cycle monitor per environment, one for each active one. The active cycle’s card with its lot, its production day, its tasks and its recent alerts.
• Tasks in a kanban, filtered to the environment. Pending, in progress, completed, draggable. Here you see whether the plan of applications and checks is being followed and what was left undone.
• The week’s calendar, for the environment’s daily rhythm.

None of these widgets would make sense on panel 1, and none of panel 1’s adds anything here. They are the same sensors, the same outputs and the same tasks, read from another place.

Shared mechanics

The three panels rest on the same infrastructure.

• Live values reach the browser over MQTT, without polling: a gauge changes when the variable changes, and when the device disconnects the hardware status shows it on its own.
• History has two levels. The last 24 hours are kept at one record per minute; earlier data as 15-minute averages in historical storage. A one-hour dynamics chart and a sixty-day cycle comparison query different layers, and long queries align their windows by day to reuse results.
• Permissions are by role. Any member of the organisation sees the panels; the operating role edits widgets; the administrator creates panels, chooses which opens by default and deletes them. The current-state, temporal and hardware-consumption widgets are in every plan; cycle, task, supply and forecast widgets require the PRO plan.
• Panels can also be created from outside. Growcast’s MCP server exposes the same operation: a connected assistant can create an environment’s standard panel (cycle monitor, its alarms, one gauge per sensor and one live output per actuator) in a single call, or receive an explicit list of widgets and arrange them on the grid. Asking for “a consumption panel for environment 2 with climate-control and pump accumulators” is a valid way to build panel 2.

Closing

A panel with twenty widgets answers no question quickly. Three panels with six or seven each answer three. Whoever is on the floor opens theirs and knows whether anything is wrong. The owner opens theirs in the morning and knows what the day cost. The head of production opens theirs and knows whether this cycle looks like the good one.

The data is the same. What changes is the question, and the panel is the shape of the question.

See the platform→