Model equivalence testing - an easy way to crowd source API information and getting vacuums working ASAP?

[gdgib]

@edenhaus have you considered a "model equivalence testing" switch and drop down in the HA config? After checking a box (that they understand this is experimental) the user could be presented with a list of model numbers and names (e.g. "1vxt52 - X1 Omni") allowing them to select something similar with a warning that this is not guaranteed to work and they can expect ZERO support without the log messages.

If we coupled that with log messages that have copy/paste information for the issue tracker, for example: "using model ABC as XYZ, there was a failure executing 123, please copy and paste this text into [Insert link to a new issue template]". The UI during configuration could even tell them to read the logs, and that they'll need to file issues.

This would:

1. Allow users a temporary workaround that doesn't require coding.
2. The workaround requires opt-in, which should cut down your overhead in dealing with incomplete and unresolvable issues.
3. Create a LOT of issues with more specific information, which ideally could help us at least narrow down what kinds of API monitoring and reverse engineering might need to be done.
4. Bring developers who might be able to help (e.g. I have an X1 Omni, maybe you don't) together with the users who will need to know when support cna be expected.

I admit my skills aren't really up to adding that as a feature right now, mostly because I don't know the integration UI code at all.

Overall, I think the changes are:

• Add a switch & drop down to the HA configuration for the integration
• Add a list of model names to model numbers in this code base
• Add a dynamic lookup based on the configured model equivalence to the model to use

[gdgib]

In case it wasn't clear, from the user perspective, this would mean if your vacuum isn't supported you have to check a box ini the HA configuration GUI to enable equivalence testing, and the select a model you think is "close". Then if it doesn't work, the idea is you'd get some logs messages you could submit to the issue tracker on this repo which would give people like a hint as to what to fix.

By contrast today asking a dev to support a new model... well without API information it's all just a complete guess, and could be dangerously wrong.

[akuehner]

This would be a vast improvement over the current process to try and get our devices working again. It's sad to see there's been no other feedback on this proposal so far.

[edenhaus]

I don't know how to add it as HA has some guidelines and adding your proposal would not comply with them. Different models create different entities and dynamically changing/adding/removing entities is a mess for the user and also something we should avoid. Adding such a option in the config flow is not allowed for core integrations. (For sure I will not create a custom component for this feature)

Also, from a maintainer's perspective, your idea is not great as the fallback devices before removing were creating a warning log entry for more than 2 years, and only a few users gave me feedback. By eliminating the fallback, I was able to add more than 30 models in a single week. Before that only 10 models were supported properly.

Thanks for your proposal but for now I will reject it as it would make maintaining this integration harder