* 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
* Revert Axis config flow version to 1
* Set up using hass.config_entries.async_setup
* Fix review comment
* Update homeassistant/components/axis/__init__.py
Co-authored-by: Martin Hjelmare <marhje52@gmail.com>
Co-authored-by: Martin Hjelmare <marhje52@gmail.com>
* 🎨 Add missing typing for config-flow
* 🐛 Remove 'tariff' edition from options-flow
The `entry.data["tariff"]` is what makes the `entry.unique_id`,
so it's an incoherence to be able to change it in the Options flow
* 🌐 Update generated EN translation
* 🎨 Link translations of option-flow to those of config-flow
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.
* Fix IoT Class for Torque plugin
This is currently misclassified:
- There is no "Torque" server, the Torque plugin is the server that receives data directly from the client. It should be `local` instead of `cloud`.
- The client sends data to the server as needed. This plugin will NOT poll for data. It should be `push` instead of `poll`.
* Run hassfest
Co-authored-by: Franck Nijhof <git@frenck.dev>
* Deprecate mode_command_topic for MQTT climate
* Correct deprecation and remove support release inf
* Do not use future tense for comment
* Extend deprecation period to 6 months
* 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
shbatm
starkillerOG
Martin Hjelmare
J. Nick Koston
GitHub Action
Shay Levy
Robert Svensson
Guido Schmitz
Luke
Kevin Worrel
Ville Skyttä
Maciej Bieniek
Mike Degatano
Eugenio Panadero
epenet
Malte Franken
tronikos
Franck Nijhof
Jovan Gerodetti
Teju Nareddy
Yuval Aboulafia
Aaron Bach
Erik Montnemery
Osma Ahvenlampi
Jan Bouwhuis