So looking at the docs, the websocket url is just the api url with /ws/spc how does that work?

Its the protocol that differs, the API is http(s) the websocket is ws(s).

Yes but I mean, can they be hosted at different places? Is the websocket URL always just the normal URL with a different protocol and path?

The question is boiling down to "why do we need 2 URLs?"

No idea what the original design constraint was. I do agree that we could just take "hostname" or "ip" as input and go from there, we'd have to modify the import code a little to allow for this.

Maybe best to do that as a separate change?

Can we do our due diligence to make sure there are not models or reasons why someone want to deviate? Because at this point i would also be fine with just trying to see if the URLs are different and raise a special error message for the users. (Or maybe just try using the normal URL and if that fails raise an error)

Would it make sense to make it smart? Just attempt the same credentials and if they fail ask for the correct ones?

I'm just trying to push a bit back to see if we can make this user friendly without having the need for users to dive into the manual

I don't think it makes sense as part of this change, it would turn this into a breaking change, in its current state with just configflow and the import process existing users of the interaction would just seamlessly move over.

Oh but I think that if we're going to add a config flow, that means we get an influx of new users using the integration, so ideally I use this PR to find out what the best way is for the config flow to work.

The question if the host of the websocket URL can be different is also still unanswered.

Like, fine that we don't ask that now, but we can get that info from the existing configuration and ask from now on

I'm not sure it makes for a better user experience.

We would be looking for hostname, port, optional get/put password(not supporting individual passwords for that given the pyspcwebgw project doesn't support them), and optional ws password.

We'd need to update the import code to attempt to parse the existing URLs for this information.

The paths and hostnames should always be the same as far as I can tell, unless somebody has done reverse proxy stuff in front of it for some reason, I'd imagine this is an unusual use.

We'd need to do a documentation update at https://www.home-assistant.io/integrations/spc/ as the parameters would no longer be the same.

We'd need the manufacturer to update their documentation too - they do state that authentication and encryption isn't supported but it does work 😅.

It feels like something that should be scoped to a different PR.

optional get/put password(not supporting individual passwords for that given the pyspcwebgw project doesn't support them), and optional ws password.

How do you mean this one?

I think it would make sense for our project to disallow reverse proxy stuff. We implement with the device, not with the reverse proxy. We also don't want to be responsible for the extra maintenance running it behind a reverse proxy comes, so I think the config flow addition (a moment which already is a breaking change) is a good moment to re review this instead of doing it one after the other and having multiple versions in a row.

Let me write down what I understand is the situation and then we can agree on a path forward