4.2 KiB
title | sidebar_label |
---|---|
Checklist for creating a platform | Platform checklist |
A checklist of things to do when you're adding a new platform.
:::info Not all existing platforms follow the requirements in this checklist. This cannot be used as a reason to not follow them! :::
0. Common
- Follow our Style guidelines
- Use existing constants from
const.py
- Only add new constants to
const.py
if they are widely used. Otherwise keep them on platform level - Use
CONF_MONITORED_CONDITIONS
instead ofCONF_MONITORED_VARIABLES
- Only add new constants to
1. External requirements
- Requirements have been added to
manifest.json
. TheREQUIREMENTS
constant is deprecated. - Requirement version should be pinned:
"requirements": ['phue==0.8.1']
- We no longer want requirements hosted on GitHub. Please upload to PyPi.
- Each requirement meets the library requirements.
2. Configuration
- If the platform can be set up directly, add a voluptuous schema for configuration validation
- Voluptuous schema extends schema from component
(e.g.,hue.light.PLATFORM_SCHEMA
extendslight.PLATFORM_SCHEMA
) - Default parameters specified in voluptuous schema, not in
setup_platform(...)
- Your
PLATFORM_SCHEMA
should use as many generic config keys as possible fromhomeassistant.const
- Never depend on users adding things to
customize
to configure behavior inside your platform.
import voluptuous as vol
from homeassistant.const import CONF_FILENAME, CONF_HOST
from homeassistant.components.light import PLATFORM_SCHEMA
import homeassistant.helpers.config_validation as cv
CONF_ALLOW_UNREACHABLE = "allow_unreachable"
DEFAULT_UNREACHABLE = False
PLATFORM_SCHEMA = PLATFORM_SCHEMA.extend(
{
vol.Required(CONF_HOST): cv.string,
vol.Optional(CONF_ALLOW_UNREACHABLE, default=DEFAULT_UNREACHABLE): cv.boolean,
vol.Optional(CONF_FILENAME): cv.string,
}
)
3. Setup platform
- Verify that the passed in configuration (user/pass/host etc.) works.
- Group your calls to `add_entities if possible.
- If the platform adds extra actions, the format should be
<domain of your integration>.<service action name>
. So if your integration's domain is "awesome_sauce" and you are making a light platform, you would register service actions under theawesome_sauce
domain. Make sure that your service actions verify permissions.
4. Entity
-
Extend the entity from the integration you're building a platform for.
from homeassistant.components.light import Light class HueLight(Light): """Hue light component."""
-
Avoid passing in
hass
as a parameter to the entity.hass
will be set on the entity when the entity is added to Home Assistant. This means you can accesshass
asself.hass
inside the entity. -
Do not call
update()
in constructor, useadd_entities(devices, update_before_add=True)
instead. -
Do not do any I/O inside properties. Cache values inside
update()
instead. -
When dealing with time, state and/or attributes should not contain relative time since something happened. Instead, it should store UTC timestamps.
-
Leverage the entity lifecycle callbacks to attach event listeners or clean up connections.
5. Communication with devices/services
-
All API specific code has to be part of a third party library hosted on PyPi. Home Assistant should only interact with objects and not make direct calls to the API.
# bad status = requests.get(url("/status")) # good from phue import Bridge bridge = Bridge(...) status = bridge.status()
Tutorial on publishing your own PyPI package
Other noteworthy resources for publishing python packages:
Cookiecutter Project
flit
Poetry