Summary Tiles (updated April and June 2024)

I have added updates to this first post as it has become increasingly out of date as of late April 2024. Further changes were made in June 2024.

I’ve been looking at summary tiles more, meaning the little status tiles on the Favourites and Room pages of the mobile apps. My conclusion is that they are configured in a way that would be recognisable from device configs and capability presentations. They focus on particular observable events using the device ‘type’ as the filter.

Update: The observable events now filter on the category rather than the device type.


The configuration data is divided into two top level groupings - ‘static’ and ‘dynamic’. The static tiles appear to be those that are always displayed (if enabled). The tiles may be updated ‘immediately’ or they may be ‘periodic’.


This monitors the windowShade>windowShade attribute in the main component of devices of type oic.d.blind and updates immediately.

Update: This now uses the category blind instead of the type.


This monitors the relativeHumidityMeasurement>humidity attribute in any component of any type of device and updates every ten minutes. The tile displays the average value.

Update: If there are more than 5 values and the standard deviation is more than 5, a humidity range is displayed instead of the average value. A tilde (~) is being used in the range, which looks a little odd. The humidity values from devices of type AirConditioner are only included if their switch is on.


This works with switch>switch and switchLevel>Level in the main component of devices of type oic.d.light, or with switch>switch in the main component of oic.d.smartplug. It updates immediately.

Update: This now works with the Light and SmartPlug categories instead of the types and as of late April 2024 has added Switch. It also works with the colorControl and colorTemperature capabilities on the display side.


This uses temperatureMeasurement>temperature in any component of oic.d.airconditioner, oic.d.airpurifier, oic.d.thermostat,,, or and updates every ten minutes.

Update: The categories AirConditioner, AirPurifier, Thermostat, AirQualityDetector, MultiFunctionalSensor, MotionSensor and Button are now used instead of types. A temperature range is used instead of an average if there are more than 5 values with a standard deviation of more than 3, and there is a filter for the switch being on for the AirConditioner and AirPurifier. A further update in June 2024 added TempHumiditySensor which by then had already been use in production drivers for some time.

weather and outdoorAirQuality

These are special cases that update every twenty minutes. The weather tile just displays temperature and the air quality is described as ‘ultra fine dust’ but actually seems to be PM2.5 which I believe is normally called ‘fine dust’.


Update: A hub tile seems to have been added in June 2024. It seems to monitor all the attributes of the bridge capability on devices with the Hub category but for display purposes it is the health status that matters.


The ‘dynamic’ grouping appears to be tiles that are only displayed when there is something to report.


The ‘running’ tiles display various states for devices of type oic.d.dishwasher, oic.d.dryer, oic.d.washer, and (AirDresser). There are lots of different attributes involved.

Update: These now work with the categories DishWasher, Dryer, Washer and ClothingCareMachine, with ShoesCareMachine being a new addition.


This monitors the contactSensor>contact attribute in the main component of and, the doorControl>door in the main of oic.d.garagedoor and the lock>lock in the main of oic.d.smartlock. The visible states are open for the windows and doors, and unlocked and unlocked with timeout for locks, although the configuration does look a bit garbled for the latter with the active states also being listed as the inactive ones.

Update: The ‘open’ tile now works with MultiFunctionalSensor and ContactSensor. A separate ‘lock’ tile has been introduced for GarageDoor and SmartLock.


This monitors the battery>battery attribute in the main component of any device and the tile is visible for values less than 15.

Update: Actually that should have said less than or equal to 15.

So it seems there is another useful tool out there that the community probably might like to get its paws on, though I still feel that certain of this functionality would be better implemented using device groups as that gives scope for using summary information in automations. Of course, I’ll happily withdraw that comment if it turns out that the status of summary tiles can indeed be used in that way rather than being just a display feature. Indeed the summary lighting group that I assumed was powering the lights tile might actually be an end product of it instead.


good info! has anyone figured out the discrepancy between devices/components used in the summary data and devices available to filtered out from them? Last I heard there were devices being used for the data, but when you try to filter them out in settings for the summary they aren’t listed there.

I have revamped my original post to better distinguish between ‘static’ and ‘dynamic’ tiles and correct some of the bits which were more obviously cobblers. I appreciate that it would probably just be easier to spew out the configuration file or at least give the URL but I like to seem at least a bit reluctant to do so when it isn’t the public API that is involved.

I haven’t worked out what is going on, but I think it is a similar mechanism to discrepancies between device presentations and what you get in the UI where the configuration is usually sound but the plugin is making a bit of a Horlicks of implementing it sometimes. Having said that …

Something I do notice is that if I create virtual devices in the categories Light or SmartPlug they do appear in the ‘Lights’ summary tile despite not actually having an ocfDeviceType defined in the device objects. They don’t appear in the settings though. So I was wondering what would happen if I explicitly created them with an ocfDeviceType. And the answer was that I got a generic icon rather than a switch one but the summary tile settings remained empty. Then I wondered what would happen if I actually used oic.d.smartplug instead of absent-mindedly PascalCasing it. That time I got the right icon and the device appeared in the settings.

So my conclusion based on a sample size of one is that the ‘Lights’ summary tile settings page follows the lead of the icons in expecting the device to have an explicit ocfDeviceType (in this case oid.d.light or oic.d.smartplug), whereas for newly created devices to be recognised it seems adequate for them to have Light or SmartPlug categories in the components. It would be interesting to know if that in any way matches what others are seeing.