Hi,

I am fairly new to HA. Im getting this error stated below. Anything I am missing?

My configuration looks like this:
hue:
bridges:
- host: 192.168.x.x
allow_unreachable: true
allow_hue_groups: true

remote:

• platform: hueremote

Log Details (ERROR)
Wed Apr 08 2020 09:13:21 GMT+0200 (Central European Summer Time)
Error while setting up platform hueremote
Traceback (most recent call last):
File "/srv/homeassistant/lib/python3.6/site-packages/homeassistant/helpers/entity_platform.py", line 150, in _async_setup_platform
await asyncio.wait_for(asyncio.shield(task), SLOW_SETUP_MAX_WAIT)
File "/usr/lib/python3.6/asyncio/tasks.py", line 358, in wait_for
return fut.result()
File "/home/homeassistant/.homeassistant/custom_components/hueremote/remote.py", line 40, in async_setup_platform
config.get(CONF_SCAN_INTERVAL, DEFAULT_SCAN_INTERVAL),
File "/home/homeassistant/.homeassistant/custom_components/hueremote/data_manager.py", line 159, in async_add_platform_entities
async for is_new, model, dev_id, _ in self._iter_data(platform_models):
File "/home/homeassistant/.homeassistant/custom_components/hueremote/data_manager.py", line 56, in _iter_data
await bridge.sensor_manager.coordinator.async_request_refresh()
AttributeError: 'HueBridge' object has no attribute 'sensor_manager'

Now there are better options, as documented in the readme, we are archiving this repo. This is to indicate that its time to move onto the better options, and prevent unwanted issues being opened here. This integration will remain on HACS until it (eventually breaks), then be removed.

During the realization of the new architecture of this custom integration, a scan setting was introduced to diverge form the default 0.5 hz frequency:

remote:
  - platform: huesensor
    scan_interval: 1

is this still available in the new split-up configuration? I ask because it isn't mentioned any more in the docs, but very much needed in the real life setup...to not Hammer the Hue Hub with an overdose of requests

Hey there, I followed the steps and added the hue_remote folder to custom_components

➜  homeassistant git:(master) ✗ ls custom_components/hueremote
implemented_remotes.py  __init__.py  manifest.json  __pycache__  remote.py

I am getting the following error

Platform error remote.hueremote - cannot import name 'TYPE_ZLL_ROTARY' from 'aiohue.sensors' (/usr/local/lib/python3.7/site-packages/aiohue/sensors.py)

Any ideas what I need to do to fix this?

I think this requires a PR on the HACS repo

• https://hacs.xyz/docs/publish/start

Splitting the sensors and remotes is a good idea. Will the remotes repo be added to HACS?

The official remotes integration by @azogue is under active development, but it would be useful to clarify the functionality of this CC vs the official

To api_samples.py or samples.py ?

On the Philips Hue Dimmer Switch, the last button event seems to "stick" until a different button is pressed. This prevents the user from pressing the button a second time, even if hours later. Can we add an option clear the last event immediately after (or shortly after) a button press?

Example:
I use the 3_click_up event (fan off button) to turn off a fan. Let's say I used the button to turn off the fan three hours ago. Then I later turn the fan back on by some means other than the remote. I now cannot use the 3_click_up event to turn off the fan because the last registered button event is still the 3_click_up from three hours ago. If I press the button, no new "to" 3_click_up event is registered now.

This is demonstrated in the screenshot below. The 3_click_up event triggered 3 hours ago, so I cannot trigger it again unless I click another button first.

As title, could rename to class HueData or HueRemoteData?

This may not be so much of a bug, but more of a how do I workaround this now.

I have a single automation for a remote, it looks like this:
trigger:

• entity_id: remote.abc_bedroom_switch
  platform: state
  condition:
• condition: or
  conditions:
  • condition: state
    entity_id: remote.abc_bedroom_switch
    state: 1_click_up
  • condition: state
    entity_id: remote.abc_bedroom_switch
    state: 2_click_up
  • condition: state
    entity_id: remote.abc_bedroom_switch
    state: 3_click_up
  • condition: state
    entity_id: remote.abc_bedroom_switch
    state: 4_click_up
    action:
• data_template:
  button: '{{ trigger.to_state.state }}'
  room: abc_bedroom
  service: script.abc_bedroom_hue_remote

The script it calls looks like this:
abc_bedroom_hue_remote:
alias: ABC bedroom bedside hue remote
description: Call various scripts depending on the button/press type

sequence:
- service_template: >
{% set group = 'group.' ~ room ~ '_lights' %}
{% set script = {
'1_click_up': 'script.lights_off' if is_state(group, 'on') else 'script.lights_on',
'2_click_up': 'script.lights_increase_brightness',
'3_click_up': 'script.lights_decrease_brightness',
'4_click_up': 'script.lights_off',
}
%}
{{- script[button] -}}
data_template:
room: '{{ room }}'
lights: >
{% set group = 'group.' ~ room ~ '_lights' %}
{% set lights = {
'1_click_up': expand(group) | map(attribute='entity_id') | join(','),
'2_click_up': expand(group) | selectattr('state','eq', 'on') | map(attribute='entity_id') | join(','),
'3_click_up': expand(group) | selectattr('state','eq', 'on') | map(attribute='entity_id') | join(','),
'4_click_up': expand(group) | map(attribute='entity_id')| join(',') ~ ',' ~ expand('group.abc_bathroom_lights') | map(attribute='entity_id') | join(','),
}
%}
{{- lights[button] -}}

Probably not the most efficient way to do this, but I was using it as a reason to learn more about scripts. I plan to move most of it back to the automation, and reduce the number of script calls. I originally started with a bunch of ifs, but saw someone using the Jinja dicts in a neat way and I replicated it.

With the new version of HASS/Hueremote, additional attributes are exposed, including the battery level. While the last_updated: doesn't change, I've noticed the battery can jump around a bit, mainly after being used. What's now happening is I press a button, and it triggers as expected. Let's say I pressed button 1, and my lights toggle. The state may look like:

model: ZLLSwitch
last_button_event: 1_click_up
last_updated: 2020-04-18, 03:10:00
name: ABC Bedroom switch
on: true
reachable: true
battery_level: 94
friendly_name: ABC Bedroom switch
icon: mdi:remote
supported_features: 0

Shortly afterwards, my lights turn off again and I can see the state has changed to:
model: ZLLSwitch
last_button_event: 1_click_up
last_updated: 2020-04-18, 03:10:00
name: ABC Bedroom switch
on: true
reachable: true
battery_level: 93
friendly_name: ABC Bedroom switch
icon: mdi:remote
supported_features: 0

Since the button event doesn't have a reset back to 'none', the battery level updating causes the trigger to fire, and rerun the same action.

With my limited knowledge and skill set, I can see two ways to fix this. One would be to make a template sensor/input/something that just takes the button press event and replicates it without anything else attached. The other would be to check the last_updated and see if it's changed in the last second, but I don't know how to compare times yet, although I'm sure there are plenty of examples online.

I wanted to report this in case anyone else ran across it, or has suggestions on how best to deal with it.

Edit: I've added the following condition to my automation:

{{ as_timestamp(now()) | int - as_timestamp(states.remote.ABC_bedroom_switch.last_updated) | int < 1 }}

I quickly hacked the tests, but some still need fixing. Request assistance from @azogue