When testing #52 I ran in to a scenario that I think should be fixed:
If you specify https://my.isy.address:80 (which is likely user error, as it's the non secure port but specified as https. I made this error when switching to https for testing), PyISY will attempt the connection, fail, and then attempt the connection with HTTP and continue onward for the rest of its session in HTTP.
I see this as a security concern: If the user specifies https, they need to be confident that the communication is encrypted. It would be better for PyISY to error out than try to help by falling back to HTTP.
(A middle-ground, if there is objection to this, is to at least throw an exception that could be caught by the application. With the current implementation, Home Assistant (for example) doesn't get to know that the connection ended up being non-encrypted and therefore can't warn the user. But I would rather go with my primary suggestion above.)
When testing #52 I ran in to a scenario that I think should be fixed:
If you specify
https://my.isy.address:80(which is likely user error, as it's the non secure port but specified as https. I made this error when switching to https for testing), PyISY will attempt the connection, fail, and then attempt the connection with HTTP and continue onward for the rest of its session in HTTP.I see this as a security concern: If the user specifies https, they need to be confident that the communication is encrypted. It would be better for PyISY to error out than try to help by falling back to HTTP.
(A middle-ground, if there is objection to this, is to at least throw an exception that could be caught by the application. With the current implementation, Home Assistant (for example) doesn't get to know that the connection ended up being non-encrypted and therefore can't warn the user. But I would rather go with my primary suggestion above.)