Skip to content
HVACloud

Appearance

Language

Three ways into the same interface

Plants already running in a controller vendor cloud stay there and still appear in HVACloud, in the same tenant as native plants.

  • Decided per plant not one decision for the whole fleet
  • Mixed fleets under a single interface
  • No double ingest the data stays where it already is

Openness instead of coercion

A manufacturer who has worked with one controller family for years has a fleet in that vendor cloud. Moving to a new platform must not mean that fleet is either rebuilt or written off.

HVACloud therefore knows three ways to connect, and you decide per plant:

  1. Natively through a panel or gateway. The full feature set.
  2. Cloud-to-cloud from an existing vendor cloud. The plant stays there but appears in your tenant.
  3. Further third party clouds, where their vendor agrees.

What is the same either way

A plant connected cloud-to-cloud sits in the same tenant as a native one. Same dashboards, same alarm management, same operator portal, same grid services. For your service staff it is one interface, not two.

Existing contracts with the controller vendor are untouched. There is no break that would have to be negotiated first.

What honestly only works natively

A third party cloud API delivers aggregated data with latency. Anything that needs high resolution raw data or the device itself is therefore only fully available over the native path:

  • Live operation
  • Local HMI and local logic
  • Cloudia Edge
  • Factory commissioning

That is not an argument against cloud-to-cloud. It is the reason it is an option beside the native path rather than the default.

Better shown than read

We will show you this area on a real plant, set up around the equipment you build.

Request a demo