Homematic Support (clean)

[pvizeli]

The original PR form @danielperna84 was broken. This is a reimport an cleanup version from original PR #2366

Description:
Adding bi-directional Homematic support. This includes lots of actors (switches, rollershutters etc.), thermostats and sensors (motion, brightness, shutter contacts etc.). I roughly estimate that we cover more than 60% (maybe even more) of all the currently available Homematic RF products, which are widely spread in Europe (primarily Germany, Austria and Switzerland).
Configuration of devices might be complex, but we'll cover that in the documentation (working on that). Basic setup is described within the component/platform files.
We also have an (experimental) autodetect feature, which discovers and configures every device we're capable of handling, although without friendly names. But for beginners this will quickly show which of their devices are supported and can be manually configured accordingly.

Thanks to @danielperna84 for leading this project and the pyhomematic module
Thanks to @jazzaj for starting the Homematic implementation based on pyhomematic.
Thanks to @pvizeli for making radical improvements to pyhomematic and jazzajs implementation.
Thanks to @bimbar for support of MAX! Thermostats.

Pull request in home-assistant.io with documentation (if applicable): home-assistant/home-assistant.io#586

Example entry for configuration.yaml (if applicable):

homematic:
  local_ip: "<IP of device running Home Assistant>"
  local_port: <Port for connection with Home Assistant>
  remote_ip: "<IP of Homegear / CCU>"
  remote_port: <Port of Homegear / CCU XML-RPC Server>
  autodetect: "<True/False>" (optional, experimental, detect all devices)

Checklist:

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated in home-assistant.io

If code communicates with devices:

• Local tests with tox run successfully. Your PR cannot be merged unless tests pass
• New dependencies have been added to the REQUIREMENTS variable (example).
• New dependencies are only imported inside functions that use them (example).
• New dependencies have been added to requirements_all.txt by running script/gen_requirements_all.py.
• New files were added to .coveragerc.

[balloob]

Instead of line 165-180, you can use:

from homeassistant.helpers import discovery

discovery.load_platform(hass, component, DOMAIN, {
    ATTR_DISCOVERED_DEVICES: found_devices
}, config)

Please note here that it is very important that you pass the config that you get in setup(hass, config). If you don't, you will break configs because for example the users switch config is now being ignored!

[balloob]

This is awesome ! 💃 🍺 👍 I've added a few comments. Mainly around the flow how the main component is loading its children components.

[danielperna84]

As an explanation why we allow both auto detection and manually configuring interfaces:
First, the automatic fetching of device-names depends on the setup the users have (installed plugins etc.). It might not always work, which leads to the need to manually override the automatically generated entity-names.
Second, there are a lot of devices, which combine multiple functions into one piece of hardware. These devices operate on multiple channels.

An example: There is a motion detector device, which basically is 6 devices in 1.

1. Motion detector (binary_sensor)
2. Brightness sensor (sensor)
3. Button 1, short press (binary_sensor)
4. Button 1, long press (binary_sensor)
5. Button 2, short press (binary_sensor)
6. Button 2, long press (binary_sensor)

When using autodetection, all these get created correctly as their corresponing HA-entity. But the buttons are actually not relevant within the UI. For this case we have added the option to configure an entity to be hidden. That way the entity and it's state can be used for automations, but does not clutter the UI. Essentially the badge would at max flicker when the button is being pressed, but doesn't serve any other interactive purpose. Hence we provide the choice to hide it, resulting in a clean UI. To demonstrate how a configuration without names and hidden binary_sensors looks like when a lot of devices are present (and it doesn't even show all because of the height), here's a screenshot:

I hope this is a valid reason to stick to this approach.

[balloob]

Breaking up the platform setup for discovery/config is good. I don't mind supporting both and the new approach is 👍 The quality of the code is high and that's awesome 💯

This is ready to be merged 🐬

To limit the number of entities, there is no need to create an entity for button presses. Instead, you should consider firing an event. Z-Wave does it like this for example for when a scene gets activated (source). Anyway, that's not for this PR, that will be for the future.

Moving forward, I'll be less picky when you submit PRs on the homematic code as we're having a solid foundation. I'll be giving you commit access so you can improve it yourself over time. I'll also not squash your commits to ensure that your collaboration will not get lost in history :-)