I am using only the sun elevation attributes in some automations… Is you component able to do also this?
If yes, ok i’ll disable sun component from configuration.yaml
Well, my first attempt at enhancing the sun component (i.e., Enhanced Sun Component) could, but the newer sun2 can’t. The closest it can do is to report max_elevation. I wrote it in such a way that it’s possible to add an elevation sensor, but I never got around to adding it.
I’m going to take a stab at adding the elevation (and possibly azimuth) option. My idea is to make it update such that the delta between updates is a fixed, possibly configurable, amount, rather than based strictly on time. E.g., have it update so that it changes by 0.5 degrees. (Also, have it update at solar midnight & solar noon for min & max as well.) So obviously near solar midnight and solar noon it will update less often, but between them it will update more frequently.
I’ll post again if/when I have something working.
Ok thanks… i’ll wait your update…
In the meantime can i use the enhanced sun component for my automations?
And in this case i will delete every recall to the sun component from configuration.yaml…
Is it ok?
Sorry to disturb you but i’m having a lot of confusion about the default sun component, the enhanced and the sun2 sensor.
Actually i have installed into custom_components both sun and sun2 and in the configuration.yaml i have it:
sun:
monitored_conditions:
- azimuth
- elevation
- max_elevation
- next_dawn
- next_dusk
- next_midnight
- next_noon
- daylight
- next_daylight
- prev_daylight
- sunrise
- sunset
scan_interval:
minutes: 1
After installing sun2 i put in sensor.yaml this:
- platform: sun2
monitored_conditions:
- sunrise
- sunset
- solar_midnight
- astronomical_dawn
- nautical_dawn
- dawn
- solar_noon
- dusk
- nautical_dusk
- astronomical_dusk
- daylight
- civil_daylight
- nautical_daylight
- astronomical_daylight
- night
- civil_night
- nautical_night
- astronomical_night
- max_elevation
But i don’t have any sensor.sun2_xxxx
Can you advice me about what i must have and must not have in my configs?
I need the sensor sun.sun for (as i said you before) automations based on the sun elevation.
Thanks in advance…
The sun2 integration creates sensors whose entity_id’s (by default) are sensor.xxx where xxx is the monitored_condition. So, e.g., sensor.sunrise. If you want the object_id’s to start with sun2_, then you need to specify entity_namespace. E.g.:
- platform: sun2
entity_namespace: sun2
monitored_conditions:
- sunrise
- sunset
- solar_midnight
- astronomical_dawn
- nautical_dawn
- dawn
- solar_noon
- dusk
- nautical_dusk
- astronomical_dusk
- daylight
- civil_daylight
- nautical_daylight
- astronomical_daylight
- night
- civil_night
- nautical_night
- astronomical_night
- max_elevation
Ok thanks, but now, having both custom components installed i make only confusion, so, waiting your update about sun2 i think the best thing to do is delete the ‘sun’ custom component and for automations use only the built.in sun integration… Is it ok?
You can do whatever you like. The two custom integrations can be installed and used at the same time. Note that the older “sun” custom integration overrides the standard sun component, but the newer “sun2” custom integration is completely independent of the other two.
I don’t recommend using my older “sun” custom integration. I don’t really support that anymore. If it works, it works, but if it doesn’t, then I have no plans to fix it. But you’re more than welcome to use one or the other or both. If you do want to use my custom integrations, though, I’d recommend using the newer “sun2”. You can either use it in conjunction with the standard “sun” component, or wait until I’ve implemented the elevation sensor. It’s completely up to you.
Ok but the two custom it seems create the same sensors or not?
I will use the built-in integrated with the sun2… and when i’ll have sun2 elevation i’ll use only that!
Thanks
The older “sun” custom integration replaces the standard “sun” component, so it creates only the sun.sun entity (with configurable attributes.)
The newer “sun2” custom integration has nothing to do with the standard “sun” component. It creates sensor entities, one for each of the selected monitored_conditions – e.g., sensor.sunrise. And if you use entity_namespace: blah, then they will be named, e.g., sensor.blah_sunrise.
Assuming I get the elevation sensor working with my sun2 integration, then there would be no need to use the standard sun component at the same time (at least given what you describe you want.)
BTW, I generally have it working, but I’m testing it to see if it works as I expect. I might have something to try later today or maybe tomorrow.
1 Like
Ok all is clear now… good explanation!
FWIW, I use both your sun and sun2 custom components and they both work fine together.
If you add the custom sun component to the custom_components directory the change is completely transparent and no other configuration changes are needed since it uses all of the standard sun component monitored conditions by default.
if you want to use the extra conditions to me monitored that are offered by the custom sun component then you just add the new conditions to the list of “monitored_conditions”.
1 Like
So I think I have it working reasonably well. The goal is to update the sensor when the elevation changes to the next whole integer degree, although the state is the “raw” elevation rounded to one decimal point, mainly because there are some boundary conditions that have to be handled specially. I wrote a program to test the algorithm and ran it through a simulated cycle of three days for my location and the numbers look good. I converted that into the actual custom integration code and now I’m testing it “live.” Tomorrow I’ll probably try to run the test program for various interesting days throughout the year for my location, and then maybe try a few other interesting locations. If all goes well I’ll check the change in and release it.
2 Likes
@maurizio53 I’m still working on it. I’ve found a better way to implement it, and I think I can still improve it a bit more. And once I like it I’ll probably add azimuth, too.
I have a question, though. Do you think one degree resolution is good enough, or should I make it 1/2 degree? I’ve actually implemented both. Making the resolution smaller just means it will update more often. For my location with 1/2 degree resolution for the most part it updates every 3 or 4 minutes, whereas with 1 degree resolution it obviously updates about half as often. I guess it depends on the use case, but I’m thinking, will anyone really need 0.5 degree resolution?
Hmm, it just hit me. If the use case is determining when the elevation goes above/below a certain threshold, then that can be done much more easily and accurately by implementing a binary_sensor with a configurable threshold. Then it just has to update twice a day – once when the sun goes above that elevation and then again when it goes below. And a sensor like this would use way less CPU resource. Hmm… 
Oh, i think it’s up to you and I will use it following your docs, but using less CPU resources for who uses raspberry is a very important thing… Actually I use also 1/2 degree in my automations but I can quietly change them accordingly to the component.
Ok, I think I’m pretty happy with the current implementation. It updates at each 1/2 degree change (and tries to be as close to x.0 & x.5 as possible.) So this differs from the current sun component’s implementation in that it updates as necessary, not just on a fixed schedule (where the schedule changes during the day/night.) Here is what my integration does:
And here is what the standard sun component does:
And the difference between them looks like this:
You’ll see that the amount of difference varies throughout the day. This is due to the way the standard sun component works – i.e., it changes how often it updates throughout the day, updating very infrequently during the night. Also note that the differences are not due to errors. It’s strictly a function of when these two update – mine updates as close to 0.5 multiples as possible, whereas the standard component updates on a fix schedule and will hence update at fairly random points relative to elevation.
I think I’ll check in what I have and release it, probably later today.
I’ve also tested the concept of creating a binary_sensor that will update whenever elevation crosses a configurable threshold. I.e., when HA first starts it will update immediately and be 'on' or 'off' based on whether the sun is above or below the specified elevation, respectively. It will then not update until the sun crosses the threshold again. So normally it will update twice a day - when the sun goes above the threshold (and change to 'on') and when the sun goes below the threshold (and change to 'off'.) It even works in the case where the threshold is not reached during parts of the year. In this case it may not update for days, weeks or months (and will output a warning stating so.) And if the threshold is never crossed, it will just update once at startup and then output an error stating it won’t update again. Now I just need to actually write the binary_sensor.py file (based on my test code.)
1 Like
Released sun2 1.4.0
Adds option for elevation.
The latest version is failing to install via HACS. It seems to be re-installing 1.3
it installed 1.4.0 for me and it’s working correctly with new sensors
Not me. I had to install 1.4.0 manually to get the elevation sensor and HACS still indicates I have 1.3.0 installed with an available update to 1.4.0 and if I update it does indeed reinstall 1.3.0 again.
Updated: I fixed it by hand-editing the hacs.* files in .storage. Must be some HACS weirdness after the big update.