Add feature types for vacuum cleaner maintenance

Delivered features
1

As part of an external Roborock integration, several maintenance information items are available but currently do not have a dedicated Gladys type.

Examples:

  • Remaining life of the main brush
  • Remaining life of the side brush
  • Sensor cleaning
  • Life of the dock strainer
  • Life of the dock cleaning brush
  • Life of the dust collection system

Today, these features must be declared as unknown, which simply displays « Unknown » in Gladys.

Would it be possible to add dedicated types in the vacuum-cleaner category, for example:

MAIN_BRUSH_LIFE_REMAINING
SIDE_BRUSH_LIFE_REMAINING
SENSOR_CLEANING_LIFE_REMAINING
DOCK_STRAINER_LIFE_REMAINING
DOCK_CLEANING_BRUSH_LIFE_REMAINING
DUST_COLLECTION_LIFE_REMAINING

These values would be expressed as a percentage.

This could be useful for Roborock as well as other robot vacuum integrations.

2

Hi @spenceur,

Thanks for your request, the need is quite legitimate: these maintenance data should not end up as « Unknown » in the interface!

Looking at the 6 proposed types, we made an observation: they are all exactly the same semantically: « remaining life of a component, in % ». Only the name of the part changes (main brush, side brush, dust bag…). In Gladys, the name is already carried by the name field of the feature, and a device can have several features of the same category/type (like a power strip with several switch/binary).

Instead of adding 6 specific vacuum types, we preferred a generic approach in this PR: feat(device): add generic maintenance feature category

Concretely, this adds a cross-category maintenance with a single type life-remaining (0-100% sensor, read-only). Your Roborock integration then creates a feature per component:

  • category maintenance, type life-remaining, name « Main Brush »
  • category maintenance, type life-remaining, name « Side Brush »
  • etc.

What this brings compared to specific types:

  • It covers your 6 cases, but also all those we haven’t listed (washing pads, detergent…) and other consumable devices (air purifiers, water softeners…), without having to make a PR in Gladys for each new component or new brand.
  • Nothing is lost on the usage side: display in %, graphs, and scenes (« alert me when the brush goes below 10 % ») work the same way, as scenes target a specific feature, not a type.
  • We avoid making the catalog of types grow indefinitely (and the MQTT dropdown list :sweat_smile:), each entry being a public contract that we can’t remove afterwards.

The only difference is that the component label comes from your feature rather than a translation built into Gladys — but that’s exactly what makes the system flexible.

It will be available in the next release. Don’t hesitate if you see a case that this generic type would not cover!

3

I’m closing this post as the feature is available in Gladys Assistant 4.86: