Simplification and better HA integration

[azogue]

cc @robmarkcole, don't merge this one to master yet.

Description

Simplified to its minimal expression, and fully covered, with better HA integration. Instead of handling our data and listen to bridge changes, the platform is registered in the bridges, so it operates like the main platforms sensor and binary_sensor.

Now we do things like HA and rely on its data coordinator to handle the aiohue sensors.

Details

• Mimic official hue in HA for binary_sensors and sensors support, and define HueRemote_AIOHUEType_ classes for remote entities which extract the state and attributes from aiohue sensor data. These are:
  • HueRemoteZLLSwitch: for RWL021, ROM001 and Z3-1BRL (Hue Dimmer Switch, Hue Smart button, Lutron Aurora).
  • HueRemoteZGPSwitch: for ZGPSWITCH and FOHSWITCH Hue tap switches.
  • HueRemoteZLLRelativeRotary: for Z3-1BRL, Lutron Aurora Rotary.
• Do platform setup by registering the remote platform in the sensor manager data coordinator, so bridge updates will call class constructors to create remote entities :) This change requires ~HA v0.108, as depends on home-assistant/core#32732
• Set the high freq scan_interval by adding our own scheduler to run in each tick
• Remove parse_hue_api_response and sons, as now we access to each aiohue sensor individually in the HA entity. Replace actual definitions to state mappings for each kind of remote, also using aiohue press definitions.

Notes about convergence with HA

From this point on, the next steps up to a PR for the official integration would require better integration, by using config_registry, and some minor changes inside the main hue, so IMO we stop here for the CC, as it is easier to do it on HA directly

(I'm already working on it on https://github.com/home-assistant/core/compare/dev...azogue:feature/add-remotes-to-hue)

Also, I have to thank @balloob for his guidance on the remotes refactor :)

BREAKING CHANGE

This PR relies on a small change on HA Core which is not included in the last HA release, so this one won't work on production systems, be advised!

[azogue]

Do not trust Travis on this one :)

Access to HA is mocked in tests. Under HA v0.106.6 it will miserably fail ;-)

[robmarkcole]

Ok will wait for HA 0.108 before merge

[codecov-io]

Codecov Report

Merging #7 into master will increase coverage by 9.61%. The diff coverage is 97.36%.

@@            Coverage Diff             @@
##           master       #7      +/-   ##
==========================================
+ Coverage   87.91%   97.53%   +9.61%     
==========================================
  Files           4        3       -1     
  Lines         240       81     -159     
==========================================
- Hits          211       79     -132     
+ Misses         29        2      -27

Impacted Files	Coverage Δ
custom_components/hueremote/implemented_remotes.py	100% <100%> (ø)
custom_components/hueremote/remote.py	95.45% <95%> (-4.55%)	:arrow_down:

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 5bcc1c2...a3e41bb. Read the comment docs.

[elmigbot]

Hello, it looks like this will split the Lutron Aurora into two remotes, the button as ZLLSwitch, and the dial as ZLLRelativeRotary. Is there anyway to link them together? Otherwise it could be confusing when more than one is implemented.

[klada]

Since HASS 0.108 is out and has support for remotes (thanks @azogue) this could be merged, right?

[robmarkcole]

Appears the test failed

[azogue]

Now it is ready to work seamlessly with the latest HA Core, I think, @robmarkcole

BUT, now that remotes are recognized in main hue, this CC is not really necessary anymore (I think that is a good thing!). But this PR makes it work better with HA anyway.

Let's review the current status in the HA-Hue ecosystem:

• Main hue registers remote devices, fires events with button presses, and generates battery sensor entities. Also presents the button presses as 'device triggers' for automations :)

• This CC:

  • Exposes the switches as remote entities,
  • Shows them with fixed state mappings
  • Modifies the hue update interval to a fixed, faster, rate (1Hz by default, customizable with scan_interval: X)
  • It needs HA restarts to enable/disable

• New Fast-Hue CC (https://github.com/azogue/fasthue):

  • Modifies the main hue update interval to any value, different for each bridge
  • Monitors the current refresh rates with sensor entities
  • Enables a service to change the refresh rate anytime :)
  • It is UI configurable, no restarts needed. Removing it restores the original behavior.

• New EventSensor CC (https://github.com/azogue/eventsensor):

  • Monitors some event in a sensor entity, to reflect, for example, the last button pressed in its state (so the sensor.remote_x entities are analog to the remote.remote_x entities created here)
  • Define any custom mapping for the button presses, or just show the raw code (default behavior if the state is not found in the given mapping, also very useful to 'debug' new device kinds)
  • It needs HA restarts to enable/disable, as it needs some yaml :(

IMO (but I cannot be objective here, obviously), the best combination is to use fasthue + eventsensor. And if you don't need to 'see' some entity, the latter is not required. And the former is just to set a faster refresh rate (or make it dynamic). If comfortable with the 5s of the main hue, then no CC is needed!

[azogue]

BTW, the 2 new CC's that I pointed are already in queue to be added to HACS:

• https://github.com/hacs/default/pull/301
• https://github.com/hacs/default/pull/328

but in the meanwhile, they can be used by adding the repos in the HACS config.

The fasthue one could even be installed and executed without any HA restart! (it was a beautiful surprise to me)

[robmarkcole]

OK great work @azogue! The hue CC ecosystem is getting quite busy, but you give a good summary above. Where do you think is the best location to document this?