etc etc.
just to see if this will be less of a burden for the processor, and generate less errors or warnings in the logs.
nothing automatic as your custom component of course, but very interesting to build, get to understand the system, and create different ways for the same result
Its just that i suspected one of my Hue lights, because it was not responding properly. Seemed to correlate with this error-log.
Of course the challenge lies in finding which causes what the light causing the delay in updating, or the delay causing the response of the light.
@foxys and @Cain I have added the ‘on’ and ‘reachable’ attributes in release v0.5. You can see the changes required to the code here are minimal so I would encourage people to submit PR’s for such requests. That will be fastest and guarantee your requirements are met.
Cheers
Nice!
since you ask: would be possible to have the last_updated display the time first and then the date/year? that way at first glance, without clicking for the more-info, we would see the actual time, and not 2018…
@Mariusthvdb you could break out last_updated in the format you want using a template_sensor. If dropping the date by default that could be a braking change for others. However if you have a nice solution, please submit the PR?
Cheers
well, im not a big python programmer, so wouldn’t resume to have a solution.
it’s just I would find it more convenient to have the last update time displayed in the sensor first, rather than the year:
I’ve put them in a group, so this is less of an issue, and you’re right, I breakout the date/time in a separate sensor, and will figure it out there
i use: "{{states.sensor.philips_hue_sensors.attributes['23'].state.lastupdated | timestamp_custom ('%H:%M')}}" or
As a general rule, if there is a way to achieve the desired outcome using existing HA functionality, then that is the preferred approach. Adding unnecessary complexity to components is a recipe for headaches due to unintended consequences.
Btw python is easy to pickup, and you will get a lot more out of this platform with a little python experience. I recommend experimenting with python_scripts as a way to get your feet wet.
Cheers
well, i trying. having more ideas than capabilities for the time being though
would love to automatically find the scenes and lighting schemes the Hue offers, so one can set them from within Hassio. As it stands now, i find myself going back to the Hue-app to find the correct settings for scenes.
One could hard code these i believe, by issuing the rib settings in an automation. But what would be so much nicer is when these settings popped up as available options, or at least as templatable states attributes.
Another effort would go to reading the programmed scenes from the button switches, the so called schedules and scenes in the Api. We now can see which button is pressed, but in the Hue Api the name of the scenes belonging to that button is available also. Might that be an enhancement for your component maybe?
Groups could be another cool set to extract, but there Hue itself offers some support, though a bit cryptic .
Well enough to be excited about and to look forward too.
Hope to be able to extract some of the above from the sensors.