core/homeassistant/components/insteon_plm.py

121 lines
3.3 KiB
Python
Raw Normal View History

New component 'insteon_plm' and related platforms (#6104) * Connect to PLM and process simple protocol callbacks * Baseline commit * Connect to PLM and process simple protocol callbacks * Baseline commit * Connection working again * Async add devices is working via callback now * Beginning to interface with PLM library for control and state * Deal with brightness in 255 levels with library * Change sub names to match API changes * Remove PLM-level update callback * Support dimmable based on underlying PLM device attributes * Expand to non-light platforms * Stubs for turn on and off * Current version of Python library * Amend to use switch device attributes * Use asyncio endpoints for control * Add logging line * Bump module version to 0.7.1 * Auto-load platforms, display device info/attributes * Unify method name for getting a device attribute * Require Current version of insteonplm module * Import the component function in each platform in the balloob-recommend manner * For consistency, handle switch state as onlevel just like lights * Use level 0xff for on state, even with binary switches Observing the behavior of a 2477S switch, it looks like even the non-dimmable devices use 0x00 and 0xff for off/on respectively. I was using 0x01 for on previously, but that yields unnecessary state change callbacks when message traffic ends up flipping the onlevel from 0xff to 0x01 or 0x01 to 0xff. * Use sensorstate attribute for sensor onoff * Move new device callback to devices attribute * Add support for platform override on a device * Bump version of insteonplm module * Default overrides is an empty list * Avoid calling private methods when doing common attributes * Remove unused CONF_DEBUG for now * flake8 and pylint code cleanup * Move get_component to local function where it is needed * Update to include insteonplm module. * New files for insteon_plm component * Legitimate class doctring instead of stub * Docstring changes. * Style changes as requested by @SEJeff * Changes requested by @pvizeli * Add @callback decorator to callback functions * Opportunistic platform loading triggered by qualifying device detection Instead of loading all the constituent platforms that comprise the insteon_plm component, instead we defer and wait until we receive a callback for a device that requires the platform.
2017-02-21 07:53:39 +00:00
"""
Support for INSTEON PowerLinc Modem.
For more details about this component, please refer to the documentation at
https://home-assistant.io/components/insteon_plm/
"""
import logging
import asyncio
import voluptuous as vol
from homeassistant.core import callback
from homeassistant.const import (
CONF_PORT, EVENT_HOMEASSISTANT_STOP)
import homeassistant.helpers.config_validation as cv
from homeassistant.helpers import discovery
REQUIREMENTS = ['insteonplm==0.7.5']
New component 'insteon_plm' and related platforms (#6104) * Connect to PLM and process simple protocol callbacks * Baseline commit * Connect to PLM and process simple protocol callbacks * Baseline commit * Connection working again * Async add devices is working via callback now * Beginning to interface with PLM library for control and state * Deal with brightness in 255 levels with library * Change sub names to match API changes * Remove PLM-level update callback * Support dimmable based on underlying PLM device attributes * Expand to non-light platforms * Stubs for turn on and off * Current version of Python library * Amend to use switch device attributes * Use asyncio endpoints for control * Add logging line * Bump module version to 0.7.1 * Auto-load platforms, display device info/attributes * Unify method name for getting a device attribute * Require Current version of insteonplm module * Import the component function in each platform in the balloob-recommend manner * For consistency, handle switch state as onlevel just like lights * Use level 0xff for on state, even with binary switches Observing the behavior of a 2477S switch, it looks like even the non-dimmable devices use 0x00 and 0xff for off/on respectively. I was using 0x01 for on previously, but that yields unnecessary state change callbacks when message traffic ends up flipping the onlevel from 0xff to 0x01 or 0x01 to 0xff. * Use sensorstate attribute for sensor onoff * Move new device callback to devices attribute * Add support for platform override on a device * Bump version of insteonplm module * Default overrides is an empty list * Avoid calling private methods when doing common attributes * Remove unused CONF_DEBUG for now * flake8 and pylint code cleanup * Move get_component to local function where it is needed * Update to include insteonplm module. * New files for insteon_plm component * Legitimate class doctring instead of stub * Docstring changes. * Style changes as requested by @SEJeff * Changes requested by @pvizeli * Add @callback decorator to callback functions * Opportunistic platform loading triggered by qualifying device detection Instead of loading all the constituent platforms that comprise the insteon_plm component, instead we defer and wait until we receive a callback for a device that requires the platform.
2017-02-21 07:53:39 +00:00
_LOGGER = logging.getLogger(__name__)
DOMAIN = 'insteon_plm'
CONF_OVERRIDE = 'device_override'
CONFIG_SCHEMA = vol.Schema({
DOMAIN: vol.Schema({
vol.Required(CONF_PORT): cv.string,
vol.Optional(CONF_OVERRIDE, default=[]): cv.ensure_list_csv,
New component 'insteon_plm' and related platforms (#6104) * Connect to PLM and process simple protocol callbacks * Baseline commit * Connect to PLM and process simple protocol callbacks * Baseline commit * Connection working again * Async add devices is working via callback now * Beginning to interface with PLM library for control and state * Deal with brightness in 255 levels with library * Change sub names to match API changes * Remove PLM-level update callback * Support dimmable based on underlying PLM device attributes * Expand to non-light platforms * Stubs for turn on and off * Current version of Python library * Amend to use switch device attributes * Use asyncio endpoints for control * Add logging line * Bump module version to 0.7.1 * Auto-load platforms, display device info/attributes * Unify method name for getting a device attribute * Require Current version of insteonplm module * Import the component function in each platform in the balloob-recommend manner * For consistency, handle switch state as onlevel just like lights * Use level 0xff for on state, even with binary switches Observing the behavior of a 2477S switch, it looks like even the non-dimmable devices use 0x00 and 0xff for off/on respectively. I was using 0x01 for on previously, but that yields unnecessary state change callbacks when message traffic ends up flipping the onlevel from 0xff to 0x01 or 0x01 to 0xff. * Use sensorstate attribute for sensor onoff * Move new device callback to devices attribute * Add support for platform override on a device * Bump version of insteonplm module * Default overrides is an empty list * Avoid calling private methods when doing common attributes * Remove unused CONF_DEBUG for now * flake8 and pylint code cleanup * Move get_component to local function where it is needed * Update to include insteonplm module. * New files for insteon_plm component * Legitimate class doctring instead of stub * Docstring changes. * Style changes as requested by @SEJeff * Changes requested by @pvizeli * Add @callback decorator to callback functions * Opportunistic platform loading triggered by qualifying device detection Instead of loading all the constituent platforms that comprise the insteon_plm component, instead we defer and wait until we receive a callback for a device that requires the platform.
2017-02-21 07:53:39 +00:00
})
}, extra=vol.ALLOW_EXTRA)
PLM_PLATFORMS = {
'binary_sensor': ['binary_sensor'],
'light': ['light'],
'switch': ['switch'],
}
@asyncio.coroutine
def async_setup(hass, config):
"""Set up the connection to the PLM."""
New component 'insteon_plm' and related platforms (#6104) * Connect to PLM and process simple protocol callbacks * Baseline commit * Connect to PLM and process simple protocol callbacks * Baseline commit * Connection working again * Async add devices is working via callback now * Beginning to interface with PLM library for control and state * Deal with brightness in 255 levels with library * Change sub names to match API changes * Remove PLM-level update callback * Support dimmable based on underlying PLM device attributes * Expand to non-light platforms * Stubs for turn on and off * Current version of Python library * Amend to use switch device attributes * Use asyncio endpoints for control * Add logging line * Bump module version to 0.7.1 * Auto-load platforms, display device info/attributes * Unify method name for getting a device attribute * Require Current version of insteonplm module * Import the component function in each platform in the balloob-recommend manner * For consistency, handle switch state as onlevel just like lights * Use level 0xff for on state, even with binary switches Observing the behavior of a 2477S switch, it looks like even the non-dimmable devices use 0x00 and 0xff for off/on respectively. I was using 0x01 for on previously, but that yields unnecessary state change callbacks when message traffic ends up flipping the onlevel from 0xff to 0x01 or 0x01 to 0xff. * Use sensorstate attribute for sensor onoff * Move new device callback to devices attribute * Add support for platform override on a device * Bump version of insteonplm module * Default overrides is an empty list * Avoid calling private methods when doing common attributes * Remove unused CONF_DEBUG for now * flake8 and pylint code cleanup * Move get_component to local function where it is needed * Update to include insteonplm module. * New files for insteon_plm component * Legitimate class doctring instead of stub * Docstring changes. * Style changes as requested by @SEJeff * Changes requested by @pvizeli * Add @callback decorator to callback functions * Opportunistic platform loading triggered by qualifying device detection Instead of loading all the constituent platforms that comprise the insteon_plm component, instead we defer and wait until we receive a callback for a device that requires the platform.
2017-02-21 07:53:39 +00:00
import insteonplm
conf = config[DOMAIN]
port = conf.get(CONF_PORT)
overrides = conf.get(CONF_OVERRIDE)
@callback
def async_plm_new_device(device):
"""Detect device from transport to be delegated to platform."""
New component 'insteon_plm' and related platforms (#6104) * Connect to PLM and process simple protocol callbacks * Baseline commit * Connect to PLM and process simple protocol callbacks * Baseline commit * Connection working again * Async add devices is working via callback now * Beginning to interface with PLM library for control and state * Deal with brightness in 255 levels with library * Change sub names to match API changes * Remove PLM-level update callback * Support dimmable based on underlying PLM device attributes * Expand to non-light platforms * Stubs for turn on and off * Current version of Python library * Amend to use switch device attributes * Use asyncio endpoints for control * Add logging line * Bump module version to 0.7.1 * Auto-load platforms, display device info/attributes * Unify method name for getting a device attribute * Require Current version of insteonplm module * Import the component function in each platform in the balloob-recommend manner * For consistency, handle switch state as onlevel just like lights * Use level 0xff for on state, even with binary switches Observing the behavior of a 2477S switch, it looks like even the non-dimmable devices use 0x00 and 0xff for off/on respectively. I was using 0x01 for on previously, but that yields unnecessary state change callbacks when message traffic ends up flipping the onlevel from 0xff to 0x01 or 0x01 to 0xff. * Use sensorstate attribute for sensor onoff * Move new device callback to devices attribute * Add support for platform override on a device * Bump version of insteonplm module * Default overrides is an empty list * Avoid calling private methods when doing common attributes * Remove unused CONF_DEBUG for now * flake8 and pylint code cleanup * Move get_component to local function where it is needed * Update to include insteonplm module. * New files for insteon_plm component * Legitimate class doctring instead of stub * Docstring changes. * Style changes as requested by @SEJeff * Changes requested by @pvizeli * Add @callback decorator to callback functions * Opportunistic platform loading triggered by qualifying device detection Instead of loading all the constituent platforms that comprise the insteon_plm component, instead we defer and wait until we receive a callback for a device that requires the platform.
2017-02-21 07:53:39 +00:00
name = device.get('address')
address = device.get('address_hex')
capabilities = device.get('capabilities', [])
_LOGGER.info("New INSTEON PLM device: %s (%s) %r",
New component 'insteon_plm' and related platforms (#6104) * Connect to PLM and process simple protocol callbacks * Baseline commit * Connect to PLM and process simple protocol callbacks * Baseline commit * Connection working again * Async add devices is working via callback now * Beginning to interface with PLM library for control and state * Deal with brightness in 255 levels with library * Change sub names to match API changes * Remove PLM-level update callback * Support dimmable based on underlying PLM device attributes * Expand to non-light platforms * Stubs for turn on and off * Current version of Python library * Amend to use switch device attributes * Use asyncio endpoints for control * Add logging line * Bump module version to 0.7.1 * Auto-load platforms, display device info/attributes * Unify method name for getting a device attribute * Require Current version of insteonplm module * Import the component function in each platform in the balloob-recommend manner * For consistency, handle switch state as onlevel just like lights * Use level 0xff for on state, even with binary switches Observing the behavior of a 2477S switch, it looks like even the non-dimmable devices use 0x00 and 0xff for off/on respectively. I was using 0x01 for on previously, but that yields unnecessary state change callbacks when message traffic ends up flipping the onlevel from 0xff to 0x01 or 0x01 to 0xff. * Use sensorstate attribute for sensor onoff * Move new device callback to devices attribute * Add support for platform override on a device * Bump version of insteonplm module * Default overrides is an empty list * Avoid calling private methods when doing common attributes * Remove unused CONF_DEBUG for now * flake8 and pylint code cleanup * Move get_component to local function where it is needed * Update to include insteonplm module. * New files for insteon_plm component * Legitimate class doctring instead of stub * Docstring changes. * Style changes as requested by @SEJeff * Changes requested by @pvizeli * Add @callback decorator to callback functions * Opportunistic platform loading triggered by qualifying device detection Instead of loading all the constituent platforms that comprise the insteon_plm component, instead we defer and wait until we receive a callback for a device that requires the platform.
2017-02-21 07:53:39 +00:00
name, address, capabilities)
loadlist = []
for platform in PLM_PLATFORMS:
caplist = PLM_PLATFORMS.get(platform)
for key in capabilities:
if key in caplist:
loadlist.append(platform)
loadlist = sorted(set(loadlist))
for loadplatform in loadlist:
hass.async_add_job(
discovery.async_load_platform(
hass, loadplatform, DOMAIN, discovered=[device],
hass_config=config))
_LOGGER.info("Looking for PLM on %s", port)
New component 'insteon_plm' and related platforms (#6104) * Connect to PLM and process simple protocol callbacks * Baseline commit * Connect to PLM and process simple protocol callbacks * Baseline commit * Connection working again * Async add devices is working via callback now * Beginning to interface with PLM library for control and state * Deal with brightness in 255 levels with library * Change sub names to match API changes * Remove PLM-level update callback * Support dimmable based on underlying PLM device attributes * Expand to non-light platforms * Stubs for turn on and off * Current version of Python library * Amend to use switch device attributes * Use asyncio endpoints for control * Add logging line * Bump module version to 0.7.1 * Auto-load platforms, display device info/attributes * Unify method name for getting a device attribute * Require Current version of insteonplm module * Import the component function in each platform in the balloob-recommend manner * For consistency, handle switch state as onlevel just like lights * Use level 0xff for on state, even with binary switches Observing the behavior of a 2477S switch, it looks like even the non-dimmable devices use 0x00 and 0xff for off/on respectively. I was using 0x01 for on previously, but that yields unnecessary state change callbacks when message traffic ends up flipping the onlevel from 0xff to 0x01 or 0x01 to 0xff. * Use sensorstate attribute for sensor onoff * Move new device callback to devices attribute * Add support for platform override on a device * Bump version of insteonplm module * Default overrides is an empty list * Avoid calling private methods when doing common attributes * Remove unused CONF_DEBUG for now * flake8 and pylint code cleanup * Move get_component to local function where it is needed * Update to include insteonplm module. * New files for insteon_plm component * Legitimate class doctring instead of stub * Docstring changes. * Style changes as requested by @SEJeff * Changes requested by @pvizeli * Add @callback decorator to callback functions * Opportunistic platform loading triggered by qualifying device detection Instead of loading all the constituent platforms that comprise the insteon_plm component, instead we defer and wait until we receive a callback for a device that requires the platform.
2017-02-21 07:53:39 +00:00
plm = yield from insteonplm.Connection.create(device=port, loop=hass.loop)
for device in overrides:
#
# Override the device default capabilities for a specific address
#
if isinstance(device['platform'], list):
plm.protocol.devices.add_override(
device['address'], 'capabilities', device['platform'])
else:
plm.protocol.devices.add_override(
device['address'], 'capabilities', [device['platform']])
New component 'insteon_plm' and related platforms (#6104) * Connect to PLM and process simple protocol callbacks * Baseline commit * Connect to PLM and process simple protocol callbacks * Baseline commit * Connection working again * Async add devices is working via callback now * Beginning to interface with PLM library for control and state * Deal with brightness in 255 levels with library * Change sub names to match API changes * Remove PLM-level update callback * Support dimmable based on underlying PLM device attributes * Expand to non-light platforms * Stubs for turn on and off * Current version of Python library * Amend to use switch device attributes * Use asyncio endpoints for control * Add logging line * Bump module version to 0.7.1 * Auto-load platforms, display device info/attributes * Unify method name for getting a device attribute * Require Current version of insteonplm module * Import the component function in each platform in the balloob-recommend manner * For consistency, handle switch state as onlevel just like lights * Use level 0xff for on state, even with binary switches Observing the behavior of a 2477S switch, it looks like even the non-dimmable devices use 0x00 and 0xff for off/on respectively. I was using 0x01 for on previously, but that yields unnecessary state change callbacks when message traffic ends up flipping the onlevel from 0xff to 0x01 or 0x01 to 0xff. * Use sensorstate attribute for sensor onoff * Move new device callback to devices attribute * Add support for platform override on a device * Bump version of insteonplm module * Default overrides is an empty list * Avoid calling private methods when doing common attributes * Remove unused CONF_DEBUG for now * flake8 and pylint code cleanup * Move get_component to local function where it is needed * Update to include insteonplm module. * New files for insteon_plm component * Legitimate class doctring instead of stub * Docstring changes. * Style changes as requested by @SEJeff * Changes requested by @pvizeli * Add @callback decorator to callback functions * Opportunistic platform loading triggered by qualifying device detection Instead of loading all the constituent platforms that comprise the insteon_plm component, instead we defer and wait until we receive a callback for a device that requires the platform.
2017-02-21 07:53:39 +00:00
hass.data['insteon_plm'] = plm
hass.bus.async_listen_once(EVENT_HOMEASSISTANT_STOP, plm.close)
plm.protocol.devices.add_device_callback(async_plm_new_device, {})
return True
def common_attributes(entity):
"""Return the device state attributes."""
attributes = {}
attributekeys = {
'address': 'INSTEON Address',
'description': 'Description',
'model': 'Model',
'cat': 'Category',
New component 'insteon_plm' and related platforms (#6104) * Connect to PLM and process simple protocol callbacks * Baseline commit * Connect to PLM and process simple protocol callbacks * Baseline commit * Connection working again * Async add devices is working via callback now * Beginning to interface with PLM library for control and state * Deal with brightness in 255 levels with library * Change sub names to match API changes * Remove PLM-level update callback * Support dimmable based on underlying PLM device attributes * Expand to non-light platforms * Stubs for turn on and off * Current version of Python library * Amend to use switch device attributes * Use asyncio endpoints for control * Add logging line * Bump module version to 0.7.1 * Auto-load platforms, display device info/attributes * Unify method name for getting a device attribute * Require Current version of insteonplm module * Import the component function in each platform in the balloob-recommend manner * For consistency, handle switch state as onlevel just like lights * Use level 0xff for on state, even with binary switches Observing the behavior of a 2477S switch, it looks like even the non-dimmable devices use 0x00 and 0xff for off/on respectively. I was using 0x01 for on previously, but that yields unnecessary state change callbacks when message traffic ends up flipping the onlevel from 0xff to 0x01 or 0x01 to 0xff. * Use sensorstate attribute for sensor onoff * Move new device callback to devices attribute * Add support for platform override on a device * Bump version of insteonplm module * Default overrides is an empty list * Avoid calling private methods when doing common attributes * Remove unused CONF_DEBUG for now * flake8 and pylint code cleanup * Move get_component to local function where it is needed * Update to include insteonplm module. * New files for insteon_plm component * Legitimate class doctring instead of stub * Docstring changes. * Style changes as requested by @SEJeff * Changes requested by @pvizeli * Add @callback decorator to callback functions * Opportunistic platform loading triggered by qualifying device detection Instead of loading all the constituent platforms that comprise the insteon_plm component, instead we defer and wait until we receive a callback for a device that requires the platform.
2017-02-21 07:53:39 +00:00
'subcat': 'Subcategory',
'firmware': 'Firmware',
'product_key': 'Product Key'
}
hexkeys = ['cat', 'subcat', 'firmware']
for key in attributekeys:
name = attributekeys[key]
val = entity.get_attr(key)
if val is not None:
if key in hexkeys:
attributes[name] = hex(int(val))
else:
attributes[name] = val
return attributes