Understood, thanks.
In this case, is there a way to make it that the custom updater last update stays in the “stable releases” (0.8). If not, I’ll just take out this component from it, no problem.
Yes that would be very nice, automatic creation of all 4 sensors next to the motion sensor. Temp, light_level, lux and battery.
I have 12 sensors… and have all handmade template sensors. Imagine the code I had to write which the component could have done for me. I realize much of this code is customization, but even without that automatic sensor creation would have saved lots of effort and errors…
A yes/no option would be awesome and make this work for all users and suit each level of usage.
I would suggest to follow and follow only Philips Hue Hardware and their official api.
Hue friends ea might add functionality but could possibly interfere with Philips Hue design, simply because of that.
1 Like
ok, tried:
still
Unable to find component sensor.hue
And it’s really there as far as I can tell…
I’m confused a bit about the “no manual settings needed”… nothing in sensor? (IP, tojen, etc…)
@sfnetwork do you have your Hue bridge configured on the Integrations page? 0.9+ is relying on this configuration only.
Also, this error (Unable to find component sensor.hue) should indicate that hass couldn’t locate or import the module. Please enable debug-logging and paste the log somewhere. The only problem I could imagine here is either dependency issue, or some Python syntax/compatibility error.
BTW, do you have a Discord?
tried and tested successfully, after a (rather long) wait after restart, and below error many times for all of my sensors (which are customized based on the site of the sensors)
2019-01-02 23:10:13 ERROR (MainThread) [homeassistant.helpers.entity] Update for sensor.corridor_office_motion_sensor_light_level fails
Traceback (most recent call last):
File "/usr/local/lib/python3.6/site-packages/homeassistant/helpers/entity.py", line 221, in async_update_ha_state
await self.async_device_update()
File "/usr/local/lib/python3.6/site-packages/homeassistant/helpers/entity.py", line 347, in async_device_update
await self.async_update()
File "/usr/local/lib/python3.6/site-packages/homeassistant/components/sensor/template.py", line 215, in async_update
setattr(self, property_name, template.async_render())
File "/usr/local/lib/python3.6/site-packages/homeassistant/helpers/template.py", line 138, in async_render
return self._compiled.render(kwargs).strip()
File "/usr/local/lib/python3.6/site-packages/jinja2/asyncsupport.py", line 76, in render
return original_render(self, *args, **kwargs)
File "/usr/local/lib/python3.6/site-packages/jinja2/environment.py", line 1008, in render
return self.environment.handle_exception(exc_info, True)
File "/usr/local/lib/python3.6/site-packages/jinja2/environment.py", line 780, in handle_exception
reraise(exc_type, exc_value, tb)
File "/usr/local/lib/python3.6/site-packages/jinja2/_compat.py", line 37, in reraise
raise value.with_traceback(tb)
File "<template>", line 1, in top-level template code
TypeError: '<=' not supported between instances of 'NoneType' and 'int'
the sensors are finally seen and get their values.
there’s an enormous amount of this in the logs though:
2019-01-02 23:10:20 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/config/custom_components/sensor/hue.py", line 174, in async_update_info
await asyncio.wait([api.sensors.update() for api in apis])
File "/usr/local/lib/python3.6/asyncio/tasks.py", line 313, in wait
return (yield from _wait(fs, timeout, return_when, loop))
File "/usr/local/lib/python3.6/asyncio/tasks.py", line 396, in _wait
yield from waiter
concurrent.futures._base.CancelledError
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/config/custom_components/sensor/hue.py", line 174, in async_update_info
await asyncio.wait([api.sensors.update() for api in apis])
File "/usr/local/lib/python3.6/site-packages/async_timeout/__init__.py", line 45, in __exit__
self._do_exit(exc_type)
File "/usr/local/lib/python3.6/site-packages/async_timeout/__init__.py", line 92, in _do_exit
raise asyncio.TimeoutError
concurrent.futures._base.TimeoutError
2019-01-02 23:10:26 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/config/custom_components/sensor/hue.py", line 174, in async_update_info
await asyncio.wait([api.sensors.update() for api in apis])
File "/usr/local/lib/python3.6/asyncio/tasks.py", line 313, in wait
return (yield from _wait(fs, timeout, return_when, loop))
File "/usr/local/lib/python3.6/asyncio/tasks.py", line 396, in _wait
yield from waiter
concurrent.futures._base.CancelledError
@yottatsa @robmarkcole is this the place you want this to be reported? Will you take this to the Github repo?
cheers!
Yes I already use hue for lights in ha.
I have a discord « sfnetwork »
Please try using this version and adding next options:
logger:
default: error
logs:
custom_components.sensor.hue: debug
homeassistant.components.light.hue: debug
hue:
bridges:
- host: DEVICE_IP_ADDRESS
Then look if those messages are appears together with the sensor values:
DEBUG (MainThread) [homeassistant.components.light.hue] Finished light request in 0.080 seconds
DEBUG (MainThread) [custom_components.sensor.hue] hue_api_response {....
I suspect that the bridge either loaded late, or it just unresponsive. So I removed timeouts and added proper exception.
In the end it was because of inter-dependency between two files. Will fix in 1.0.2
Thanks, will do.
Just a small worry …: since this is now depending on Hue integration, I do fear it will be frustrated by the same issues that component suffers ever since the architectural change to asyncio.
2019-01-03 13:43:53 ERROR (MainThread) [homeassistant.components.hue] Error connecting to the Hue bridge at 192.168.1.212
2019-01-03 13:43:53 ERROR (MainThread) [homeassistant.components.hue] Error connecting to the Hue bridge at 192.168.1.212. Retrying in 2 seconds
has been in the logs ever since, no matter how small the setup is.
The CC has been rock solid even though Hue component sees many connecting problems and lights and groups showing Unavailable.
When I booted after installing the new CC I saw the same in the front end and log: unable to connect to Hue bridge and as consequence lights not found, and now sensors not found… in up to the 0.8 version, the sensors where always immediate and initialized correctly at boot.
Most fervently hope this step forward won’t prove to be a step back irl.
If your move from timing to exception proves to be the solution to this. you might have a look at the Hue component itself, which relies on a timing of 4 ( or 5, not completely certain) before it errors out.
wait, I am using 1.0.1…
is that what you want me to do, or is there a different version with the exception method? Unless the sensor on your page is a different one from the one on the official repo… Ive dl your version now:
same errors during startup of the sensor being NoneType and the templates are invalid… Big difference is the sensors are loaded at first view in Frontend, so that’s progress.
Here’s whats’s plenty the log while starting up:
2019-01-03 11:25:34 ERROR (MainThread) [homeassistant.helpers.entity] Update for sensor.corridor_terrace_motion_sensor_light_level fails
Traceback (most recent call last):
File "/usr/local/lib/python3.6/site-packages/homeassistant/helpers/entity.py", line 221, in async_update_ha_state
await self.async_device_update()
File "/usr/local/lib/python3.6/site-packages/homeassistant/helpers/entity.py", line 347, in async_device_update
await self.async_update()
File "/usr/local/lib/python3.6/site-packages/homeassistant/components/sensor/template.py", line 215, in async_update
setattr(self, property_name, template.async_render())
File "/usr/local/lib/python3.6/site-packages/homeassistant/helpers/template.py", line 138, in async_render
return self._compiled.render(kwargs).strip()
File "/usr/local/lib/python3.6/site-packages/jinja2/asyncsupport.py", line 76, in render
return original_render(self, *args, **kwargs)
File "/usr/local/lib/python3.6/site-packages/jinja2/environment.py", line 1008, in render
return self.environment.handle_exception(exc_info, True)
File "/usr/local/lib/python3.6/site-packages/jinja2/environment.py", line 780, in handle_exception
reraise(exc_type, exc_value, tb)
File "/usr/local/lib/python3.6/site-packages/jinja2/_compat.py", line 37, in reraise
raise value.with_traceback(tb)
File "<template>", line 1, in top-level template code
TypeError: '<=' not supported between instances of 'NoneType' and 'int'
more important for now I think are these:
2019-01-03 11:20:24 DEBUG (MainThread) [homeassistant.components.light.hue] Failed to fetch group:
2019-01-03 11:20:24 DEBUG (MainThread) [homeassistant.components.light.hue] Finished group request in 7.501 seconds
2019-01-03 11:20:24 DEBUG (MainThread) [homeassistant.components.light.hue] Failed to fetch light:
2019-01-03 11:20:24 DEBUG (MainThread) [homeassistant.components.light.hue] Finished light request in 7.524 seconds
2019-01-03 11:20:28 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/config/custom_components/device_tracker/hue.py", line 109, in async_update_info
await asyncio.wait([api.sensors.update() for api in apis])
File "/usr/local/lib/python3.6/asyncio/tasks.py", line 313, in wait
return (yield from _wait(fs, timeout, return_when, loop))
File "/usr/local/lib/python3.6/asyncio/tasks.py", line 396, in _wait
yield from waiter
concurrent.futures._base.CancelledError
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/config/custom_components/device_tracker/hue.py", line 109, in async_update_info
await asyncio.wait([api.sensors.update() for api in apis])
File "/usr/local/lib/python3.6/site-packages/async_timeout/__init__.py", line 45, in __exit__
self._do_exit(exc_type)
File "/usr/local/lib/python3.6/site-packages/async_timeout/__init__.py", line 92, in _do_exit
raise asyncio.TimeoutError
concurrent.futures._base.TimeoutError
2019-01-03 11:20:29 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/usr/local/lib/python3.6/site-packages/aiohue/api.py", line 12, in update
raw = await self._request('get', self._path)
File "/usr/local/lib/python3.6/site-packages/aiohue/bridge.py", line 70, in request
) from None
aiohue.errors.RequestError: Error requesting data from 192.168.1.212: None
This happens while the sensors are initialized and displayed in the frontend.
The hub or the lights don’t like this new setup or logger setting though:
If I take out the
hue:
bridges:
- host: !secret hue_ip
again, the sensors aren’t loaded at startup, and it takes minutes again (3 just now) for the sensors to get initialized. Adding to that, the lights keep showing the Unavailable.
All in all this move to async isn’t as desirable just yet, Ill move back to CC .8, but be glad to assist in further developing.
back on 0.8, there’s immediate respons for the sensors, which are rocksolid again…This must add to the worries about asyncio for the current Hue implementation.
1 Like
I’ve set the timeout for 10 seconds by default, added exception handling, and fixed various races. Also, sensors are not losing their data if the hub is unavailable.
Please try a 1.0.2 and the manual configuration:
hue:
bridges:
- host: !secret hue_ipwill do and test.
Please know that I’ve had extensive chats with HA founder about the timer, and if that could be longer than the current setting. This all started after asyncio and the change to show the lights to become unavailable (even when the hub isn’t at all, I’ve 3 sensors to prove that, and the Hue App shows all lights available and responsive.
This was not allowed, since philosophy is, that if that would be necessary, something else is wrong, and HA integration shouldn’t try to solve that. Core issues should be tackled. There are many threads on this community or the GitHub about HUE light turning unavailable or so-called ‘flapping’.
Considering the above, It might be against the same design philosophy to adjust the timing for this CC.
That being said, the enormous amount of timing issues in the logs for the Hue sensors led me a long time ago to set the update frequency to 1 second. Still many errors, but /10 
1.0.2 working perfectly so far (no error in logs, nothing)
great work!
Now I’m curious to see if the remote sensors works better now that it’s using HA HUE integration… (detects every time)… We’ll see
1 Like
just asking: if we need to configure the bridge again here, it doesn’t identify it over the Hue component?
quick result trying 1.0.2:
sensors arent loaded immediately after restart, (took about 1 minute, and lights were loaded earlier) but they did arrive
most notable change: no errors in the log about hue sensor took longer than scheduled update interval! Cant believe my eyes, and will check log for a few more…
1 Like
I didn’t get you question. Lemme guess.
I asked you to configure the bridge with the platform because [I’m not sure but] I suspect config_flow to be really slow for you, and the platform initialisation is more predictable.
When you configure the bridge the way I’ve posted, it just kick-start the Hue platform to avoid all new machinery. Considering the size of your deployment it helps.
I need to buy a remote to test
1 Like
i asked because I thought the main advantage here was not having to set the ip address and have the component take care of it all.
Could it be that 2 version down, the sensors were immediate , and now they take about 1 minute or so to load?
I have this configured:
device_tracker:
- platform: hue
sensor:
- platform: hue
hue:
bridges:
- host: !secret hue_ip
I configurated my hue brigde over the GUI Integration. Do I need to add the hue bridge in the cofiguration.yaml aswell?
hue:
bridges:
- host: !secret hue_ip
It’s because I’m now using PlatformNotFound, which is adding exponential backoff there.
Please try both variants (with and w/o IP address). Logs would be highly appreciated.