This makes us track WeMo devices by serial number instead of URL. Per
@jaharkes' suggestion, tracking via URL could potentially be a problem
if a device changes to another IP and then appears to be discovered again.
Since we can't track based on mac (for static-configured devices), we
can use the serial number exposed to make sure we're always looking at
a list of unique devices.
The default configuration of the mFi controller generates self-signed
certificates which are valid for short periods of time, and which are
regnerated on start or as needed. This makes requests mad. Since most
people will be using the self-signed certificates anyway, add options
to let them choose non-TLS, or unverified connections if they want/need.
This bumps the mficlient requirement to 0.3.0 for proper handling of
verify=False.
Looking at your code suggestion below I am not sure exactly how other people might want to put in lists. (But I am missing a more general overview of the code)
```
if not isinstance(scene_config,list):
scene_config=[scene_config]
```
But it is there !
And changed "config" to "states" !
I broke this with my fix, where I assumed that we'd always have a wemo
config section if we're running the wemo code. However, if we're fully
auto-detected, we might not.
Example Config:
...
modules:
Bedroom:
- temperature
LivingRoom:
- temperature
Outside:
- temperature
Garden:
- rain
- sum_rain_1
- sum_rain_24
The three new parameters stand for:
- rain # Estimated rainfall for today in "mm"
- sum_rain_1 # Rainfall in the last hour in "mm"
- sum_rain_24 # Rainfall in "mm" from 00:00am - 23:59pm
The wemo component was tracking devices by mac to avoid adding duplicates,
but this means we'd never be able to load more than one static wemo, since
they all have mac=None.
This changes the code to track by url, which has to be unique per wemo
anyway, and which we also have for even static wemos.
Currently we interact with players regardless of thir coordinator
role, hence soco.exceptions.SoCoSlaveException are thrown. The use
of the decorator for each interactive method should address this
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
