hass-core/homeassistant/components/tplink
Steven B. 03c3d09583
Enable overriding connection port for tplink devices (#129619)
Enable setting a port override during manual config entry setup.

The feature will be undocumented as it's quite a specialized use case generally used for testing purposes.
2024-11-08 14:41:00 +01:00
..
__init__.py Enable overriding connection port for tplink devices (#129619) 2024-11-08 14:41:00 +01:00
binary_sensor.py Add motion detected binary_sensor for tplink (#127883) 2024-10-21 23:39:23 +02:00
button.py Add reboot button for tplink (#127935) 2024-10-11 12:21:36 +02:00
climate.py Increase tplink climate precision (#127996) 2024-10-11 13:15:30 +02:00
config_flow.py Enable overriding connection port for tplink devices (#129619) 2024-11-08 14:41:00 +01:00
const.py Add siren platform for tplink (#124934) 2024-09-20 16:11:02 +02:00
coordinator.py
deprecate.py Deprecate tplink alarm button entities (#126349) 2024-09-25 14:47:40 -05:00
diagnostics.py
entity.py Deprecate tplink alarm button entities (#126349) 2024-09-25 14:47:40 -05:00
fan.py
icons.json Add motion sensor setting to tplink (#129393) 2024-11-06 13:40:17 +01:00
light.py
manifest.json Bump python-kasa to 0.7.7 (#129817) 2024-11-04 18:39:39 +01:00
models.py
number.py Deprecate tplink alarm button entities (#126349) 2024-09-25 14:47:40 -05:00
README.md
select.py Deprecate tplink alarm button entities (#126349) 2024-09-25 14:47:40 -05:00
sensor.py Add last alert timestamp for tplink waterleak (#128644) 2024-10-30 23:25:30 +01:00
services.yaml
siren.py Add siren platform for tplink (#124934) 2024-09-20 16:11:02 +02:00
strings.json Add motion sensor setting to tplink (#129393) 2024-11-06 13:40:17 +01:00
switch.py Add motion sensor setting to tplink (#129393) 2024-11-06 13:40:17 +01:00

TPLink Integration

This document covers details that new contributors may find helpful when getting started.

Modules vs Features

The python-kasa library which this integration depends on exposes functionality via modules and features. The Module APIs encapsulate groups of functionality provided by a device, e.g. Light which has multiple attributes and methods such as set_hsv, brightness etc. The features encapsulate unitary functions and allow for introspection. e.g. on_since, voltage etc.

If the integration implements a platform that presents single functions or data points, such as sensor, button, switch it uses features. If it's implementing a platform with more complex functionality like light, fan or climate it will use modules.

Adding new entities

All feature-based entities are created based on the information from the upstream library. If you want to add new feature, it needs to be implemented at first in there. After the feature is exposed by the upstream library, it needs to be added to the <PLATFORM>_DESCRIPTIONS list of the corresponding platform. The integration logs missing descriptions on features supported by the device to help spotting them.

In many cases it is enough to define the key (corresponding to upstream feature.id), but you can pass more information for nicer user experience:

  • device_class and state_class should be set accordingly for binary_sensor and sensor
  • If no matching classes are available, you need to update strings.json and icons.json When doing so, do not forget to run script/setup to generate the translations.

Other information like the category and whether to enable per default are read from the feature, as are information about units and display precision hints.