• 

  Written:

  2025-08-27

• 

  Updated:

  2026-04-26

Igloo

Introduction

Automations and dashboards don’t interact with vendor-specific interfaces for every device, but instead, a model the platform provides. This model determines how they can control devices and read their current state.

I’m going to grade them on two scales:

• Cohesion:

  • Allowing two lights from different vendors to be controlled together
  • Allowing an RGBCT and normal light bulb to be turned off together

• Coverage:

  • How many device features are exposed
  • Exposing nonstandard features like reboot buttons, diagnostic sensors, light effects, etc.
  • Allowing new/unplanned devices to be modeled

Existing Solutions

Interestingly, every popular platform’s model uses composition in some regard. Devices are not simply modeled as a light or air conditioner, but composed of smaller units. How fine-grained the units are, how they are put together, and other implementation details vary drastically.

Home Assistant, Amazon Alexa, Google Home

Home Assistant, Amazon Alexa, and Google Home have surprisingly similar models, composing devices in a flat structure of strictly defined units. This approach is relatively simple and provides strong cohesion for devices which fit into the definitions.

These definitions vary between platforms, but all hold a lot of information, and must balance coverage and bloat. With too much coverage, definitions become massive, and hold features which many devices don’t have.

When a device’s feature cannot fit into an existing definitions, all provide three generic units: mode, number, and toggle. The mode unit contains all potential modes (a list of strings) and the current mode. Two vendors might represent the same functionality, with slightly different names, breaking cohesion.

Apple HomeKit

HomeKit introduces a hierarchy, where devices are composed services, which are further composed of fine-grained characteristics (Brightness, Volume, TargetTemperature). With the plethora of characteristics they define, many devices can be represented. This model achieves strong cohesion between all devices, regardless of if the model was explicitly designed for them.

Samsung SmartThings & Matter

Similarly, SmartThings and Matter have a hierarchical model, but with significantly more flexible structures. This allows for nearly any device to be represented, but have zero cohesion in of themselves. Instead, they define standards for vendors to follow when implementing their devices (1 2).

Comparison Table

Conclusion

Typing styles:

1. Untyped / Flexible

   • Suffers from cohesion → requires standards

2. Typed with large units (ex. Home Assistant’s Light)

   • Opinionated definition must balance coverage & bloat
   • Struggle with coverage → generic units (reduce cohesion)

3. Typed with small units (ex. Dimmable)

   • Cannot represent an N-channel relay without additional features
   • Allowing duplicate Switch units → can’t distinguish/identify them
   • Hierarchy has each channel as unit composed of Switch and Channel → works well
   • Additional hierarchy → too flexible → requires standards

A strictly typed model with small units & one layer of hierarchy seems to be the best balance of cohesion and coverage.

Igloo’s Solution

The model we concluded with is freakishly similar to the ECS (Entity-Component-System) model! While it’s really only used for games, it’s a great reference to have, and we’ll at least be using their naming scheme:

1. Entity: a set of components (no duplicates) only

2. Component: a primitive, strictly-typed data property

   • Contains a name like Dimmer
   • Optionally contains a value Dimmer(f64)
   • Otherwise, acts as a tag

An RGBCT light bulb becomes:

(Switch(true), Dimmer(1.0), Color(255, 0, 0),
  ColorTemperature(2000), ColorMode(Temperature), Light),
(Seconds(54), Uptime, Sensor),
(Decibels(−57), WiFiSignal, Sensor),
(Reset, Trigger),
...

Never Bloated, Backward-Compatible

If no existing components can model a feature, a new component is added, instead of modifying old ones. Bloating the model is never a concern, as adding a new FancyLightComponent never affects existing lights, and is only attached to entities which have that behavior. This append-only practice can easily be made backwards-compatible with automations or other code.

Device-Entity Relation

We have two primary options:

1. Actual Hierarchy:

   • Device entity exits, which relates to each entity which represents it
   • This does exist in other ECS implementations, like Bevy

2. Flat Tagging:

   • Give each entity something like a Device(id) component

Systems

*I don’t want to force Igloo into a corner here – it may choose to have systems like ECS, or it may only have the EC part.

ECS separates data (entities and components) from logic (systems). These systems are composed together and non-hierarchical. They operate entirely independently, except for their interaction with entities and components.

Queries are the method in which systems specify what entities/components they want to read, and what they want to change. They define the shape of entity they are looking for, like ones with a Dimmer and Switch. Queries are intentionally broad, and may find multiple matching entities.

When specificity is needed, tags (components with no values) can be used. Tags can mark an entity as a Light, it’s physical location like Kitchen, or anything else. Notably, these tags give the user the option to use them, but doesn’t require them to.

Conclusion

I landed on the ECS-like device model before fully exploring what was out there. I’ve questioned if this choice was right for a long time, and struggled to find anything else better. But, going through and really understanding what makes a model good (or bad) was worthwhile. Now, I can confidently say this is the right model.