Even though the wording might be slightly suboptimal here, it's better
to be consistent across the codebase than to finetune on this level.
This also switches the default the other way around: verification is
now disabled by default. This is not a good general default, but for
this particular case setups where the verification would succeed would
be so rare and require considerable local setup that it's very
unlikely to happen in practice.
Not all devices support HTTPS, so we default to plain HTTP still.
Ones that do are very likely to have certificates that do not pass
hostname verification, and are either self signed or issued by an
untrusted CA. Add option to use unverified HTTPS to make it possible to
connect to these, and when in effect, filter urllib3's related warnings
about insecure connections to the hostname in question.
* Disconnect rather than just logout at end of config flow
Neither the connection or the requests session will be reused, so
there's no reason just to logout. Do all of the connection closure
so we get all of huawei-lte-api's cleanups explicitly done.
* Name connect functions consistently, analoguous to disconnect
* Use `None` for unknown states consistently
* Use huawei_lte_api NetworkModeEnum instead of magic strings
* Recognize some new sensor items
* Exclude current day duration sensor
* Fix current month upload/download types
* Add current day transfer
* Extract lambdas used in multiple spots to named functions
* Formatter naming consistency improvements
Key routers in hass.data by config entry rather than unique id
There's no particular reason to key them by the unique id; the config
entry id is a stronger, always available guarantee, and a much more
common convention across the HA codebase.
At some point, we might conceivably support devices we can't find a
proper unique id for; this would work for that purpose as well.
* Probe Huawei LTE API for device support on SSDP match
More or less as expected, the loosening of SSDP/UPnP data matches done
in #81643 started to yield false positives, as in #85402.
Coming up with robust matches solely based on the SSDP/UPnP data still
does not seem possible, so keep the matches as loose as they were made,
but additionally invoke a probe request on the API to determine if the
device looks like a supported one.
* Probe only after unique id checks
Prevents throwaway probes for discoveries already in progress.
* Fix SSDP result URL test, add missing assert on it
* Recognize more SSDP friendly names as "ours"
* Trigger on SoyeaLink devices
* Pass discovered URL through context, it does not persist via user_input
* Use manufacturer from SSDP
* Actually use serial number if available, update URL for configured
* Remove heuristic friendly name filtering against non-LTE devices
* Refactor Huawei LTE to use Entity Description
* Apply suggestions from code review
Co-authored-by: Ville Skyttä <ville.skytta@iki.fi>
Co-authored-by: Ville Skyttä <ville.skytta@iki.fi>
Ville Skyttä