use sunrise or sunset in a template, only to discover that next_rising and next_setting change to tomorrow’s times as soon as sunrise and sunset happen?
display today’s sunrise/sunset time(s) for the entire day?
display or use today’s (or yesterday’s or tomorrow’s) amount of daylight?
reduce the frequency at which sun.sun’s azimuth & elevation attributes are updated, e.g. to reduce the number of events in the database and log?
completely eliminate azimuth & elevation updates since you don’t use them and don’t care about them?
If so, then this enhanced sun component might be what you’re looking for!
More information about it, and the component itself, can be found in my github repository here:
I welcome all feedback, positive or negative. If you do try it out, please let me know what you think.
If I get positive feedback (and no major flaws are discovered ) I’ll make a Pull Request to update the standard component accordingly.
UPDATE: The PR to enhance the standard sun component was submitted and rejected. Which led to…
A completely new sun integration (which, due to my great imagination, is named sun2! ) This is more in line with what I think the core team wants to see happen. I.e., it creates individual sensors, based on your selection, for each type of sun related data.
Hi everyone! Just wanted to bring this to your attention again. I must have posted during a lull.
Anyway, I’d like to get feedback on this, good or bad, before making a PR. Also I’d really like to have some other people try this out and let me know how it works for them. (Thanks to those who already have. If you get a chance, please share on this public post your experience with this code.)
I think this is great, the problem I have is I can’t quite say why!
It is a big improvement on the current sun component, it does exactly what it claims to do as far as I can tell (I’m not an astronomer!) and I love the extra data it gives me. I don’t actually do much with it except look at it and think how great HA is but I whole-heartedly recommend this.
Actually I can say something constructive. I like that it is configurable, if you don’t want all the data you don’t have to have it and better than that you can define how often it ‘senses’ - something woefully missing from many other sensors.
FYI, the PR was not approved. The core team would prefer to leave this old component as is and implement these features in new platforms. Unfortunately I’m not able to take on that much work at this time, but maybe sometime in the future. In the meantime, feel free to use my custom sun component, and I’m happy to make changes to it as needed.
FWIW, I’ve updated my custom component to what I had submitted in the PR. Even though it’s not the ultimate solution to a better “sun” implementation, you may still find it useful.
Do you mean why wouldn’t they want the changes in the standard sun component? The details are in the PR, but basically the sun component is very old and doesn’t really fit the model of most (newer) components. So they’d rather not change the old component, but would prefer a whole new implementation replace it. I tend to agree, but I’m not up to all the work involved in doing that.
As I understood it, they’d like the component code to create individual binary_sensors and/or sensors (like many other “hub” components do.) E.g., a binary_sensor.sun_above_horizon that would replace sun.sun’s current state of above_horizon/below_horizon, a sensor.sun_elevation, that might have an azimuth attribute, sensor.sun_next_rising that would have the new (or coming) timestamp device_class, etc. Then you could use monitored_conditions to control which of those sensors get created.
EDIT: So basically, rather than controlling which sun.sun attributes are created/maintained, split the attributes out to individual entities that either get created or not depending on the config.
My custom component effectively replaces, or supersedes, the standard sun component. So, no, you do not need to have the sun component defined twice in your configuration, regardless of which YAML file you put them in.
no it didnt cause a config error, and yes, in a package here too. there are many entries in configuration.yaml that can be in a package too, so that’s why I asked to be sure.
I’ve never tried it, but my guess would be having sun defined in your config twice would cause it to be instantiated twice. And they’d both have the same entity_id (sun.sun), or at least they’d try to have the same entity_id. Not quite sure what would happen in this case. You might end up with two sun objects, both updating sun.sun in the state machine, which would at least cause more load on the system. Worse, they might fight each other, if they’re configured differently – meaning one would update with a particular set of attributes, and then the other would overwrite it with a different set of attributes.
In any case, probably not something you’d want to do.
Also, it doesn’t matter where in you YAML files it is defined. If you have a custom sun component, it will be the one used instead of the standard one (no matter how many times it’s instantiated.)
EDIT: Actually, as I think about it more, there can only be one ‘sun’ configuration in hass.config (since it’s a Python dictionary, and it can only have one ‘sun’ key), so if you’re not getting an error, then probably what is happening is one of the sun configurations is being used and the other is being ignored. Still, probably not something you’d want to do.
All is well.
in my post above, I was somewhat confusing I fear. I wasn’t referring to actual entities of components, but to entries for components like switch:, sensor: , customize: etc etc which one can have in all packages.
since sun.sun is somewhat special, I wasn’t sure. sensor.sun would have made better sense, just as sensor.moon
This has stopped working with 0.88 (well, not fully stopped, but I’m not seeing any extra data that this component adds). This is the error I get:
Error loading custom_components.sun.automation. Make sure all dependencies are installed
Traceback (most recent call last):
File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/loader.py", line 147, in _load_file module = importlib.import_module(path)
File "/srv/homeassistant/lib/python3.5/importlib/__init__.py", line 126, in import_module return _bootstrap._gcd_import(name[level:], package, level)
File "<frozen importlib._bootstrap>", line 986, in _gcd_import
File "<frozen importlib._bootstrap>", line 969, in _find_and_load
File "<frozen importlib._bootstrap>", line 953, in _find_and_load_unlocked
ImportError: No module named 'custom_components.sun.automation'; 'custom_components.sun' is not a package
Have you ever wanted to:
) I’ll make a Pull Request to update the standard component accordingly.
) This is more in line with what I think the core team wants to see happen. I.e., it creates individual sensors, based on your selection, for each type of sun related data.