How to create a cloud automation

A cloud automation is a calculation that writes back to the installation. It's built in the same node editor as a virtual sensor, but has nodes like Write setpoint and Change setpoint — and that means it actually changes operation.

That's the most important distinction to hold onto: a virtual sensor works something out, a cloud automation does something.

You need write access, and the setpoints the automation is going to write to have to exist. See How to change a setpoint.

How to create a cloud automation

• Open the building you want to work on. See How to switch building and search for a building.

• Go to Cloud automations in the sidebar.

• Click New cloud automation.

• The Cloud automation editor opens. Drag node types out of the panel.

• Build the logic from Input to Output.

• Add the output node: Write setpoint, Write to several setpoints or Change setpoint. Pick the target with Select setpoint or Select setpoints.

• Set the Priority for the write.

• Click Save.

You get the confirmation Cloud automation saved.

Priority — read this before putting it into service

The write happens at a priority level, and the levels are shown as {value} (highest priority) and {value} (lowest priority).

Note: If a manual override sits at a higher priority level than the automation writes at, the automation is overridden — it runs, but has no effect. This is the most common reason a cloud automation "doesn't work". Check the setpoint's priority levels first.

The reverse also applies: if the automation writes at a high priority level, it blocks calendar control and manual changes. Choose the level based on what should be able to override what.

Error handling isn't optional here

Under Error handling you set the Fallback, Time period without data before fallback is applied: and Time period without data before calculation stops:

For a virtual sensor, missing error handling means a calculation stops. For a cloud automation it means the installation is left with the last value that was written, with nothing updating it.

The stop period has to be longer than the fallback period — otherwise: The time period for emergency stop must be higher than that for fallback.

The nodes available to you

The same library as for virtual sensors — Mathematics, Logic, Aggregate and Advanced — plus the setpoint output nodes. See How to create a virtual sensor for the full overview.

The Schedule node is particularly useful here: it gives 1 if active, 0 if inactive, so the automation only acts within operating hours.

How to run and follow up

• Run in the actions menu runs it manually.

• Outputs shows what it calculated.

• Active shows whether it's running.

• Execution time window - past and - future control its reach.

Automations covering a system also appear in the FDV building overview as Cloud automations from technical schema — see How to read the FDV building overview.

Frequently asked questions

How do I test without changing the installation?

Build the logic and look at Outputs before connecting an output node with a setpoint. The value can be read without anything being written.

Can I understand an automation somebody else built?

Use Ask me about the logic in this automation to ask questions about it.

Can I copy an automation to another installation?

Yes, Make a copy — and Include timeseries and other settings decides whether the attachments come along. Remember to point the setpoints at the new installation.

What is a flex automation?

A variant aimed at energy flexing — see How to create a flex automation.

Tip!

Write an FDV note on the system when you put a cloud automation into service, saying what it does and which priority level it writes at. An automation controlling an installation is invisible to whoever is standing in the panel room wondering why the setpoint is changing by itself.