All Projects → robmarkcole → Hue-remotes-HASS

robmarkcole / Hue-remotes-HASS

Licence: Apache-2.0 License
PLEASE READ THE README

Programming Languages

python
139335 projects - #7 most used programming language

Projects that are alternatives of or similar to Hue-remotes-HASS

Kelvin
Kelvin - The hue bot
Stars: ✭ 256 (+753.33%)
Mutual labels:  philips-hue, home-assistant
Home Assistant Config
Home Assistant config files, rewritten to use the latest features, 100+ documented automations, automatically generated ToC 🏠 🤖
Stars: ✭ 926 (+2986.67%)
Mutual labels:  philips-hue, home-assistant
hass-hue-icons
Additional vector icons for home assistant to model Philips Hue bulbs and fixtures.
Stars: ✭ 161 (+436.67%)
Mutual labels:  philips-hue, home-assistant
home-assistant-frigidaire
Custom component for the Frigidaire integration
Stars: ✭ 11 (-63.33%)
Mutual labels:  home-assistant
home-assistant-custom-components
My custom components for Home Assistant
Stars: ✭ 70 (+133.33%)
Mutual labels:  home-assistant
addon-airsonos
AirSonos - Home Assistant Community Add-ons
Stars: ✭ 50 (+66.67%)
Mutual labels:  home-assistant
lovelace-canary
🐤 Adds many useful extensions to lovelace, such as templating secondary info, stacking within a card and more!
Stars: ✭ 28 (-6.67%)
Mutual labels:  home-assistant
HomeAssistant
My Home Assistant Configuration
Stars: ✭ 71 (+136.67%)
Mutual labels:  home-assistant
huelib-rs
Rust bindings for the Philips Hue API
Stars: ✭ 19 (-36.67%)
Mutual labels:  philips-hue
hass-pfsense
pfSense integration with Home Assistant
Stars: ✭ 44 (+46.67%)
Mutual labels:  home-assistant
hass-neeo
NEEO custom component for Home Assistant
Stars: ✭ 17 (-43.33%)
Mutual labels:  home-assistant
esphome-weather-station
ESPHome version of Elektor weather station v2
Stars: ✭ 140 (+366.67%)
Mutual labels:  home-assistant
home-assistant-glow
⚡ The power of energy measurements in your house
Stars: ✭ 383 (+1176.67%)
Mutual labels:  home-assistant
hass nibe
Home Assistant Nibe Uplink Integration
Stars: ✭ 117 (+290%)
Mutual labels:  home-assistant
aioesphomeapi
Python Client for ESPHome native API. Used by Home Assistant.
Stars: ✭ 52 (+73.33%)
Mutual labels:  home-assistant
addon-base-python
Docker Python base images (Alpine) - Home Assistant Community Add-ons
Stars: ✭ 12 (-60%)
Mutual labels:  home-assistant
Raspberry-Pi-Clock
A quick and simple Raspberry Pi touchscreen clock with Philips hue, Tado, Dark Sky and Philips TV JointSpace API controls/data
Stars: ✭ 23 (-23.33%)
Mutual labels:  philips-hue
button-entity-row
Adds buttons to call services to entity cards
Stars: ✭ 73 (+143.33%)
Mutual labels:  home-assistant
hass-actron
Actron Air Conditioner Add-On for Home Assistant
Stars: ✭ 14 (-53.33%)
Mutual labels:  home-assistant
entur-card
Home Assistant Lovelace card card for the Entur public transport component.
Stars: ✭ 38 (+26.67%)
Mutual labels:  home-assistant

Code style: black build status Coverage

FOR COMMUNITY SUPPORT PLEASE USE THIS THREAD

For Hue motion sensors checkout Hue-sensors-HASS

If using Home Assistant >= v0.108, please read the deprecation and suggested migration section

Hue-remotes-HASS

Custom integration for Hue & Lutron Aurora Friends of Hue (FOH) remotes with Home Assistant.

Overview

This custom integration provides the missing support for remote devices in the official Hue integration of HA Core, by registering the platform in the main integration and sharing the sensor data with it.

As this new platform imposes a lower scan_interval for all hue sensors (of 1Hz), sensors from the main hue integration will also increase their refresh rate to 1 Hz.

Be advised that the increased update of this custom integration may cause connectivity problems which can result in errors in the official hue integration, please do not create any issue for this. If you can't live with these errors, do not use this custom integration.

Suggested migration

Since HA v0.108 Hue switches are recognized in the hue integration, making this CC not really necessary anymore, but there are some caveats, as it is not a perfect replacement for this CC.

Now the main hue registers the remotes as devices, and fires events with the detected button presses. For easier usage from UI, it also presents the button presses as device triggers for automations. In addition, for battery-powered remotes it generates battery sensor entities.

The features of this CC over what the main hue offers are to:

  1. Expose the switches as entities (of kind remote, but they actually are sensor), showing the last button press as the state, using fixed state mappings (like code 3002 is "3_click_up", etc.)
  2. Modify the hue update interval to a fixed, much faster, rate (1Hz by default, customizable with scan_interval: X), to have a faster polling than the 5 secs of the main integration

But as this CC is not using the Integrations menu, it needs manual yaml and a HA restart for any config change. It also has some problems derived of doing too many calls to the Hue bridge, and its usage for automation triggers now presents some flaws with false positives.

In this context, this CC is being deprecated, and these are some suggestions to migrate to other HACS custom integrations to achieve the best results, depending of your own specific needs:

  • If you need a faster polling interval for the hue bridge than the 5s, use Fast-Hue CC to:

    • Modify the main hue update interval to any value, different for each bridge
    • Monitor the current refresh rates with sensor entities
    • Enable a service to change the refresh rate anytime
  • If you want to expose the remotes as entities, because you want to track their state or use it to trigger automations, use EventSensor CC

    • It is UI configurable (with no restart required) and has configuration wizards to help configure the Hue switches for this specific migration.
    • The mapping for the button presses is customizable, being the default maps the same ones used here
    • It will not generate false positives, as it listens to the events generated in the main hue (listening directly to those events, or using UI device triggers would also do the trick)

You can use both new CCs, or none of them, if you are comfortable with the main hue polling and change your automations to use 'device triggers'.

Both are configurable via UI, so no restarts are needed to install and try them. To do the smoothest migration, with just one HA restart, follow these steps:

  1. Remove the yaml config for this CC, and replace every remote.entity_name in your config (like in automations.yaml) to sensor.entity_name, as the new entities will be of sensor type.
  2. Disable all automations using the remotes, as we don't want them triggering until migration is finished :)
  3. Uninstall this CC from HACS.
  4. Restart HA. Now the remote.x entities should be gone and this CC would not be loaded.
  5. Install "Event sensor" from HACS.
  6. In Integrations, add and configure a new sensor for each old remote. Follow the wizard for Hue remotes, set the same name as before (so new entities will be sensor.entity_name), and, as the identifier, choose "id" and set the entity_name.

At that point the migration is done, and you can check the new sensor entities by pressing buttons, and then re-enable the automations to check that everything works as before.

If the fast polling interval is required, install "Fast-Hue polling" from HACS and configure it for your needs, taking into account that, if polling too fast, some logging errors may appear in the main hue. In that case, feel free of playing with different values to optimize your specific system, as there is a new service fasthue.set_update_interval to do just that in any moment.

Installation

Install via HACS. You need to set up your Hue bridge first.

Manual installation

Alternatively, place the custom_components folder in your configuration directory (or add its contents to an existing custom_components folder).

Configuration

Once installed add to your configuration:

remote:
  - platform: hueremote

The scan interval can be modified optionally, by adding scan_interval: 2.

Supported remotes

Developers

  • Create venv -> $ python3 -m venv venv
  • Use venv -> $ source venv/bin/activate
  • Install requirements -> $ pip install -r requirements.txt & $ pip install -r requirements-dev.txt
  • Run tests -> $ venv/bin/py.test --cov=custom_components tests/ -vv -p no:warnings
  • Black format -> $ venv/bin/black custom_components/* (or setup VScode for format on save)

Contributors

Please format code usign Black before opening a pull request.

A big thanks to Atsuko Ito and Eugenio Panadero for their many contributions to this work!

Note that the project description data, including the texts, logos, images, and/or trademarks, for each open source project belongs to its rightful owner. If you wish to add or remove any projects, please contact us at [email protected].