Virtual sensors and cloud automations
Virtual sensors, cloud automations and flex automations are the same underlying thing: a calculation flow. You build each one in a visual editor as a graph of connected nodes, and Properate runs it in the cloud on a schedule. What differs is the purpose.
Virtual sensors
A virtual sensor computes a new timeseries from existing ones. Once it exists, it behaves like any other sensor — you can graph it, alarm on it, put it on a technical schema or a dashboard.
This is how you get a value nobody installed a meter for: efficiency derived from two temperatures and a flow, total consumption summed across meters that are billed separately, or a normalised figure you want to compare between buildings.
A virtual sensor: read timeseries, transform the values, write the result back as a new timeseries.
Cloud automations
A cloud automation acts on the building rather than just describing it, driving setpoints according to logic you define instead of a fixed schedule in the control system. Cloud automations attached to a technical schema also surface in the FDV overview under the relevant system, so whoever opens that system can see it is being automated.
A cloud automation. The same editor as virtual sensors, but the result is written back as a setpoint.
Flex automations
Flex automations are the energy-flexing variant. In addition to the flow itself they carry the flexibility potential and activation settings — see the Energy article for how activation, ramp-up, buffer and ramp-down work.
What every calculation flow has
- Frequency — how often it runs.
- Execution time window — how far into the past and the future each run considers. Worth understanding: a flow that needs to react to a forecast needs a future window.
- Plan and exceptions — the normal schedule, plus the deviations from it (holidays, shutdowns).
- Notifications — info, warning and error messages raised by the flow itself.
- Last run and health — the first things to check when output looks stale.
- Labels, sub-building and system — so flows stay findable, and so they attach to the right part of the building.
Good to know
- A flow that shows no setpoints usually means the target timeseries are not writable — setpoint timeseries have to be marked as writable to be driven.
- Because virtual sensors are used elsewhere, deleting one affects everything downstream. Check what depends on it first.
- Errors in a calculation flow appear as notifications on the flow, not as building alarms — so a broken flow can go quiet rather than loud. The last-run timestamp is the reliable tell.