Skip to content

Building Profile

Jason Rhubottom edited this page Aug 2, 2026 · 3 revisions

Building Profile

A Building Profile is a shared, building-level set of weather and climate sensors that you configure once and link to as many covers as you like. Instead of re-entering the same weather entity, lux sensor, outside-temperature sensor, and rain/wind sensors on every cover, you point each cover at the profile and they all read from it. Change a sensor on the profile and every linked cover updates instantly.

A profile is a virtual entry β€” it controls no covers of its own and has no geometry, position, or handler settings. It exists only to hold the shared sensors.


When to use it

Reach for a Building Profile when several covers in the same building share the same environment inputs:

  • One weather entity, lux/irradiance sensor, or cloud-coverage sensor feeding every room.
  • A single outside-temperature sensor used by every cover's climate logic.
  • Shared rain/wind safety sensors.
  • A common daytime-gate or sun-tracking-gate sensor, or custom sunrise/sunset time entities.

If each cover genuinely has its own sensors, you don't need a profile.


What a profile holds

A profile carries the building-wide inputs:

  • Weather & safety β€” weather entity, rain and wind sensors, severe-weather sensors, and the is raining / is windy sensors, templates, and combine modes.
  • Light & cloud β€” lux and irradiance sensors, cloud-coverage sensor, and the is sunny sensor/template and mode.
  • Climate & timing β€” the outside-temperature sensor, the daytime-gate sensor/template and mode, and custom sunrise/sunset time entities.
  • Sun tracking β€” the sun-tracking-gate sensor/template and mode. "Is the air conditioning running?" is a building-level answer, so it belongs here rather than on each window.

It deliberately does not hold per-installation values: comfort/temperature thresholds, lux/irradiance thresholds, presence entities, and sunrise/sunset offsets stay on each cover, because those are room-specific rather than building-wide.


Creating a profile

Add a new entry and choose the Building Profile type. You give it a name and fill in the shared sensors β€” that's the entire setup; there are no geometry or movement steps. Saving creates the profile, which then appears in the cover-link dropdown.


Linking a cover

When you create or reconfigure a cover, a Building Profile step appears (it only shows when at least one profile exists). Pick a profile from the dropdown, or choose None to leave the cover unlinked. When a cover is linked, its options menu shows the profile name (🏒 Building Profile: …) so you always know where its sensors come from.

On linking, the profile's sensors are copied into the cover. From then on the cover reads those sensors as its own β€” there's no runtime dependency that breaks if the profile is later removed.


Inherit / override model

Each shared sensor on a linked cover is in one of three states:

  • Inherited β€” the profile defines it and the cover uses the profile's value. Edit it on the profile and every inheriting cover follows.
  • Overridden β€” the cover sets its own value for that sensor, diverging from the profile. The profile no longer drives that one sensor on that cover.
  • Local β€” the profile leaves it blank, so the cover's own value stands on its own.

To override an inherited sensor, just set a different value for it on the cover; the divergence is recorded automatically. To go back to inheriting, clear the override (in the profile's Local Overrides screen), which re-applies the profile's current value. An override is tracked per sensor β€” overriding one sensor doesn't detach the cover from the rest of the profile.


Overview screen

Open the profile's options and choose Overview for a read-only summary:

  • The shared sensors this profile defines.
  • The roster of covers linked to it.
  • A comparison of behavioral settings across the linked covers, showing only where they differ.
  • Any per-cover overrides, so you can see at a glance which covers have diverged from the profile and on which sensors.

Live propagation

Editing a profile's sensors propagates to every linked cover immediately β€” each cover reloads with the new values without you touching them one by one. Overridden sensors are left alone; only inherited sensors update.


Deleting a profile

Removing a profile does not break its linked covers. Each linked cover keeps the sensors it last copied from the profile and is simply unlinked, so it keeps running on those values. The profile option then disappears from the covers' menus.


Notes & limitations

  • A profile entry has a sensor-only configuration flow β€” no geometry, cover entities, or handlers. Its menu is Shared Sensors / Overview / Local Overrides.
  • Profiles are excluded from the integration's coordinator lookups, so they never masquerade as a cover.
  • Building Profiles were introduced in v2.30.0. No migration is needed for existing installs β€” a profile is a new entry you create when you want one.

Related

🏠 Home Β· ✨ Features Β· πŸ“° What's New

Buy Me A Coffee

πŸš€ Getting Started

🧠 Core Concepts

πŸ“ Cover Types

βš™οΈ Configuration

πŸ”Œ Entities & Services

πŸ› οΈ Operations

πŸ”§ Advanced Use Cases

🎨 Dashboard

πŸ§ͺ Testing & Simulation

πŸ“š Reference

πŸ‘©β€πŸ’» For Developers

Clone this wiki locally