Add scale support for MQTT Lights.

Converts 0..255 values that HA expects into a device 0..SCALE value
Example:
  HA considers "hall light" at 25 brightness or 10% of 255
  Device considers "hall light" at 100 brightness or 10% of 1000

This allows our existing MQTT devices to not change their data format to be used in HA

improve rfxtrx sensor

Fix typo in Wemo state_detail attribute.

Moved Wink binary sensors to a binary sensor class

Update Steam sensor to show currently played game

Fix mFi error handling in setup_platform

Wemo updates

The exception we were catching incorrectly referenced the client variable
in local scope instead of the module. Also, if we fail to connect we can
get a requests exception, so catch and handle that as well.

New deutsche_bahn component

Template binary sensor

Conflicts:
	homeassistant/components/sensor/steam_online.py

Fix mysensors switch & light types

Use get_component instead of importing component for mysensors

* Move S_LIGHT and V_LIGHT from light back to switch platform, to avoid
  double devices showing.
* Remove MySensorsLightPlain class from light platform, since it's not
  needed anymore.
* A light switch with only a switch, ie no dimmer or
  RGB controls, will show as a regular switch device.

Fixed the workaround for philio slim multi sensor.

This adds hot, cold, and moving sensor_class values for things that we
may want to support.

Uses the (schiene)[https://pypi.python.org/pypi/schiene/0.14] API to communicate with the webserver of bahn.de
and pulls iformation about a specific connection from the (bahn.de)[http://www.bahn.de/p/view/index.shtml]
webpage. The departure time of the next train for the given connection is shown.
In case of delay, the delay is also shown. Additional `ATTRIBUTES` are used to
inform about e.g. the type of the train, price and if it is ontime.

Usage:

    sensor:
      platform: deutsche_bahn
        from: name_of_start_station
	  to: name_of_final_station

Problems:
I'm testing it for quite some time, but I have never seen the `ATTRIBUTES` in case
of a delayed train. The `ATTRIBUTES` are directly passed from the `schiene` API. So this
usecase has not been tested yet.

deutsche_bahn ist not supporting the `schiene` api unlike in the swiss_public_transport case.
It's not guaranteed that `schiene` will work forever, infact it can happen that Bahn AG will
intentionally brake the API at some point. In the past Bahn AG has not allways been very supportive
to the opensource community.

Bring TCP component test coverage to 100%

Changed the key matching to utilize integer values. It does not report always return the hex marker '0x' in the identifier strings. This Re closes issue #1349

Fix issue #1301