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.