New devices released

[whaleygeek]

The following new devices have recently been released by Energenie, and need device class descriptions adding to the Device.py file:

MiHome Light https://energenie4u.co.uk/res/pdfs/MIHome-Light-User-Guide-v1.4.pdf MIHO008 OOK White MIHO024 OOK Black Nickel MIHO025 OOK Chrome MIHO025 OOK Brushed Steel

MiHome Open Sensor https://energenie4u.co.uk/res/pdfs/MIHO033-Open-Sensor-User-Guide-v1.1.pdf MIHO033 FSK

MiHome Motion Sensor https://energenie4u.co.uk/res/pdfs/MIHO032-Motion-Sensor-User-Guide-v1.3-outlines.pdf MIHO032 FSK

[whaleygeek]

Branch new_devices_jun16 created to add and test these new devices.

[whaleygeek]

branch new_devices_jun16 now has working support for MIHO032 MotionSensor and MIHO033 OpenSensor.

The MiHome light requires a bit more of the transmit architecture to be fleshed out, so that it is possible for the device classes to pass radio parameters down the transmit pipeline.

The MiHome light requires a longer transmit burst to guarantee that it sees the transmit message. Testing in the lab has show that parameters (OUTER_TIMES=1, OUTER_DELAY=0, INNER_TIMES=75) is a good parameter that leads to good reliability.

It is not yet possible for the OOK transmit pipeline between the device class and the radio module to pass forward these parameters. Devices.py/LegacyDevice/send_message() needs to read the radio config parameters from it's most concrete instance, and use these to send to the air_interface (which is actually ook_interface, which is a OnAir.TwoBitAirInterface instance). OnAir.TwoBitAirInterface.send() then needs to read out these radio config parameters and override the defaults passed to radio.transmit() - defaults are presently outer_times=1, inner_times=8, outer_delay=0, modulation=ook. Also see the note in OnAir.TwoBitInterface.send() about having default radio parameters that are overriden by any radio parameters passed into it (so that if no parameters are provided, sensible defaults are used).

This will then allow any device class to configure any of the lower level parameters of the radio to best suit that specific device classes radio receive performance characteristics.

[whaleygeek]

Note also that when radio transmit parameters are changed, this changes the amount of time that the radio is in transmit mode (and therefore alters the amount of time it is in receive mode, and ultimately how wide or narrow the receive window is). There will eventually need to be some way for the radio module to pass back up the chain how long a certain set of parameters will leave the receive window closed, so that a deterministic message scheduler can be written that schedules messages into known transmit and receive slots. No need to implement that yet, but we need to allow for it in the future.

[whaleygeek]

OpenSensor and MotionSensor merged to master from branch new_device_jun16 - tested fine.

MiHomeLight requires some architectural improvements to the transmit pipeline as documented above, to pass down the INNER_TIMES=75 parameter and configure the radio for a longer transmit burst. Branched ook_radio_config to do this work

[whaleygeek]

MIHO008 tested in simulation and works. The new radio architecture passes forward radio parameters, and makes it possible to alter the inner_times parameter. Proved with print statements that the MiHomeLight gets 75, the GreenButton gets 8 and the AdaptorPlus gets 4.

Just need to test this on real hardware, then it is ready to merge back to master.

[whaleygeek]

MiHomeLight tested with real device. Proved that it is getting the right number of transmit bursts, and that other legacy devices get less transmit bursts.

Also added support for 3kwRelay, tested with a ENER002 plug (which is the same) and it works.

Also added support for MiHome HouseMonitor - works fine.

[whaleygeek]

MIHO014 relay (which is really an ENER002 OOK in a different box) physically tested on the Raspberry Pi, and it works fine.