Skip to content
Jan Seidl edited this page May 8, 2021 · 3 revisions

NOTE: This documentation refers to an upcoming change on 3.0.0

THIS IS A DRAFT

The design of Magic Areas is largely based on features listening to an area's state change. On versions prior to 3.0.0 we used to track entities directly from the features but we steered away from that design as it's not as efficient as using an event-based approach.

Every state change of either a primary (presence) or secondary state triggers an Magic Areas-specific event which our features listens to. This approach offloads state-tracking from the feature and allows multiple features to trap an event without having to add their trackers to entities. From a development perspective, this also simplifies the code and allows for quicker development.

As a result, you can also listen for these events on your automations if want to!

Current events fired by Magic Areas are:

  • EVENT_MAGICAREAS_STARTED: Magic Areas fully loaded
  • EVENT_MAGICAREAS_READY: All areas are ready but features are not yet loaded (used internally to know when to load features)
  • EVENT_MAGICAREAS_STATE_PRESENCE: When presence state changes
  • EVENT_MAGICAREAS_STATE_DARK: When dark state changes
  • EVENT_MAGICAREAS_STATE_DND: When do_not_disturb state changes

Magic Areas Documentation

📚 Concepts

🪄 How-To

✨ Features (view all)

📒 Cookbooks (coming soon...)

  • Controlling lights' brightness
  • Automatic Turning on Fans
  • Magic Areas and Alarmo
Clone this wiki locally