Summary Tiles

Apps & Clients
1

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.

static

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’.

blind

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

humidity

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.

light

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.

temperature

This uses temperatureMeasurement>temperature in any component of oic.d.airconditioner, oic.d.airpurifier, oic.d.thermostat, x.com.st.d.airqualitysensor, x.com.st.d.sensor.multifunction, x.com.st.d.sensor.motion or x.com.st.d.button and updates every ten minutes.

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’.

dynamic

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

running

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

open

This monitors the contactSensor>contact attribute in the main component of x.com.st.d.sensor.multifunction and x.com.st.d.sensor.contact, 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.

battery

This monitors the battery>battery attribute in the main component of any device and the tile is visible for values less than 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.

7 Likes
2

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.

3

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.

2 Likes