Hi Phil, This is my first time looking at this integration is detail. With the binary_sensors, I take it we can’t use an input_number as the elevation value? (so it an be adjusted from the UI)
Pretty sure you can’t
It would be a nice addition. I guess my question was a back-handed feature request!
Usecase for wanting to change it like that? I don’t see it as particularly useful
Currently I have a trigger to close some roller shutters at a particular sun elevation on hot days to prevent the sun cooking my bedroom. Being able to adjust this via the UI made it nice a simple to tune that automation perfectly without playing with code in-between testing days.
Released 2.3.1b0
There appears to be a bug in the sun phase sensors that can sometimes throw an unexpected exception around solar midnight and solar noon. This obviously doesn’t always happen and probably depends on your location and time of year.
Anyway, I think I found the cause and provided a fix in this beta release. If anyone experiences this problem, please let me know, and then try the beta release to see if it fixes the problem for you. FWIW, this bug seems to have existed for quite some time, so maybe it doesn’t manifest very often.
UPDATE:
Released 2.3.1
2 Likes
Released 2.4.0b0
This is a pre-release. It adds a basic azimuth sensor that effectively mirrors the implementation of the built-in sun integration. I.e., it simply adjusts its update period based on the sun’s current elevation, rather than attempting to update by constant incremental values like the elevation sensor. It turned out to be more difficult to do the latter, so as a workaround, it does the former. This way you can now have multiple azimuth sensors for different locations.
UPDATE:
Released as 2.4.0
2 Likes
In configuration.yaml I have:
- platform: sun2
entity_namespace: Home
latitude: 38.500
longitude: -82.12
I created long/lat sensors based on my mobile phone location. What I’m looking to do is base sun2 on the phones location so when I travel I have accurate, local info. Is sun2 able to use sensor values instead of static and if so how might I do that? Thanks!!
That’s an interesting idea. However, there are really four values that are required to specify another location - latitude, longitude, elevation and time zone. It might be possible to automatically determine time zone from latitude & longitude (that is an option in my composite tracker), but elevation would still be missing. I suppose it would work reasonably well enough if elevation was assumed to be zero.
I’ll have to think about this some more.
In general, of the people currently using, or thinking about using, this sun2 integration, how many might want to use this kind of feature?
3 Likes
Raw GPS data (given sufficient # of satellite signals) should provide altitude. I’ve seen this in hand held and mobile GPS receivers from way back. In my tinkering, I put various values in for elevation and noted any difference in sunset/sunrise etc. etc. times. It didn’t seem to make much of a difference so I think assuming it’s zero is a good start.
I wonder how often HA looks at the longitude/latitude/altitude coordinates in Sun2? If it’s just on start up, this might not be as useful as I would hope. I’m a beginner HA enthusiast so this may not be an issue, just something I was considering that could be an obstacle. Thanks!
Unfortunately, the altitude/elevation is not reported by the HA device tracker entities, at least in my experience.
If the optional location is specified in the sun2 config, then only at startup. If a location is not specified in the sun2 config, then it uses HA’s location configuration, at least once at startup, or if the user changes it during runtime.
If I were to implement the feature you’re asking for, in that case, the corresponding sun2 entities would update whenever the latitude and longitude entities changed.
give the fact I really like the device localization of these entities we make with composite, I would welcome the option here too. Aware we need our device owners to enable the HA app for that to work, and that in itself is a challenge… I would indeed start with my own device and turn on that functionality.
I would however not require that to be updated on each lat/long change, but, let’s say twice a day if in fact not in the same timezone as home is. Writing it like this, why not simply only on change of timezone?
moa app provides that directly, and I use that to show the local time for my phone:
- type: custom:button-card
template: button_wereld_tijd
name: Marijn
variables:
timezone: >
[[[ return
states['sensor.marijn_geocoded_location'].attributes['Time Zone']; ]]]
and template in JS:
label: >
[[[
return (new Date()).toLocaleDateString(
variables.language,
{hour:'2-digit',
minute:'2-digit',
day:'numeric',
month:'short',
timeZone:variables.timezone}
);
]]]
icon: >
[[[
var hourNamesIndexed =
['twelve','one','two','three','four','five','six',
'seven','eight','nine','ten','eleven','twelve'];
var timeParts =
(new Date()).toLocaleTimeString(variables.language,
{timeZone:variables.timezone,hour12:true}).split(':');
var hour = parseInt(timeParts[0]);
var minute = parseInt(timeParts[1]);
return 'mdi:clock-time-' + hourNamesIndexed[hour] + '-outline';
]]]
based on what Pieter made before.
Id love to template that in jinja but apparently we can not.
Anyways, I’d +1 on the offer, if you offered that 
btw I also have these:
state: >
{% set id = this.attributes.get('id') %}
{% set tracker = 'device_tracker.marijn_composite' %}
{% set state = states[tracker] %}
{% if state.attributes is defined and state.attributes.time_zone is defined
and state.attributes.time_zone != 'unknown' %}
{% set n = now() %}
{{(n.astimezone(state.attributes.last_seen.tzinfo).utcoffset() -
n.utcoffset()).total_seconds()/3600}}
{% else %} onbekend
{% endif %}
as you prescribe in the Composite, but that is another approach. Just mentioning it to illustrate the use of timezone differences, and why I would welcome the extra functionality
likewise I keep hoping the worldcclok integration would offer that dynamically based on device:
sensor:
- platform: worldclock
name: Marijn Wereldtijd
time_zone: device_tracker.marijn #_composite
and not have us hardcode that timezone like it is now:
- platform: worldclock
name: Marijn Wereldtijd
time_zone: Asia/Ho_Chi_Minh
I wouldn’t think only updating when the time zone changes would be appropriate. Time zones are very large areas, and the value of the various sun attributes could be wildly different in different parts of a time zone, especially in the north-south direction.
yes, you are right.
was merely figuring to reduce all too frequent updating.
might not be too chatty, otoh we dont want to overload the config with data we only check when we arrive ?
I could imagine a few options. E.g., update location every time latitude or longitude change, update location periodically at some specified rate, or “on demand”, which could be via a service and/or button.
Still, this would be a not insignificant amount of work, and I’d only want to do it if I thought many people would make use of it.
1 Like
I wouldn’t need that feature, just to report back. 
1 Like
Released 2.5.0b0
Added a new elevation_at_time sensor. The time can be specified by a static time string, e.g. '12:00', or via an input_datetime sensor that includes time. (If it also includes a date, that will be ignored.) At midnight it will calculate the sun’s elevation at the specified time for the new day. For the input_datetime option, it will also update whenever that entity updates as well.
1 Like
Released 2.5.0b1
Improved input_datetime error handling.
Regarding using an input_datetime entity, I’m thinking of using the date if it has one. There could be a use case where the elevation at a certain time on a certain date is wanted, regardless of what the current date it. But I think it should always have a time. Thoughts?
1 Like
Released 2.5.0b2
If using input_datetime entity, and it has date attributes, use them. In this case, the sensor will not have yesterday, today and tomorrow attributes.
1 Like
Released 2.5.0b3
Adds suggested display precision where appropriate. Minimum HA version is now 2023.3.
1 Like