Consider using UILogicId instead of Class for capability selection?

[MarkGodwin]

Looking through the existing list of classes, it seems that a lot of models with similar names but identical features exist for things like case colour or regional variants. This seems to be adding a lot of overhead that falls on the project maintainer when new models come out.

Just eyeballing the Deebot data, it seems that the UILogicId field might be a better option to key off the capabilities? From the name, I would guess that it's what the EcoVacs app might be using to control the features of the UI.

• OZMO 920 (vi829v) - DX_5G
• N8 (ty84oi) - N8_PLUS - which suggests it might use the same API as the N8 Plus range.
• N10 (m1wkuw) - t8_ww_n_nobel - Looks from this like the N10 might behave a lot like a T8?
• N20 Plus (buom7k) - y2se_ww_h_y2h5

(yes, I am addicted to these things)

In the later ones, it's possible that the string can be tokenised to determine the features? Maybe not.

But if you start requesting that people record the UILogicId, a pattern might emerge that will save a lot of issues being raised going forwards. Ideally telemetry from the HA installations could be collected, but I think that's quite a complicated ask and privacy concern.

[MarkGodwin]

Example from trawling google...

t10_ww_n_curieomni seems to be the UILogicId for both "DEEBOT X1e OMNI" (bro5wu) and "DEEBOT T10 OMNI" (lx3j7m)