Dynamically updated longitute/latitude

[wigster]

I would like to use your integration to create a sun entity for a location which can change over time -- let's say the current location when I am on vacation. Would it be possible to set the longitude/latitude of the sensors from some input_number entity?

[pnbruckner]

Yes, something like that could be possible. But besides latitude & longitude, it would also need elevation and time_zone. Elevation could easily default to zero (which is the correct value in most cases.) And for time_zone, that could come from my Entity Time Zone Sensor custom integration.

Probably the best way to do this would be to allow templates for those four config options. That way it could get the values from anyplace. E.g. (in YAML):

sun2:
  - unique_id: my_location
    location: My location
    latitude: "{{ state_attr('device_tracker.me', 'latitude') }}"
    longitude: "{{ state_attr('device_tracker.me', 'longitude') }}"
    time_zone: "{{ states('sensor.me_time_zone') }}"
    elevation: 0

I can tell you, though, this would be a lot of work. Couldn't you just create a temporary Sun2 entry for your vacation location?

[wigster]

I am currently deleting my "alternative" location integrations and recreating them, but I was hoping that it's possible to have this be automatised. As it is, it's enough work for me to only really do it when I am going for a big holiday, but I never to it for small trips. But we can't have all the candy in the world. Anyway, it would be a nice to have.

Thanks a lot for thinking about it.

[pnbruckner]

I'll leave this open because I do see that this could be a useful feature.

The problem is more, though, than just the amount of work to implement it. Most of the code needed is already in place, because if you configure it to use HA's location configuration (i.e., your Home location, time zone, etc.) it will update if those general system settings are changed. The downside, though, is there is a lot for it to do when this happens. It's not that big of a deal for something like this that doesn't change very often, if ever. But if it was tied to the location of, say, a device_tracker entity, that code would have to run a lot, and it could become a fairly large performance burden on the system, especially if it was done for several trackers. I haven't really measured how long the code would have to run when a location changes, so I'm not really sure how bad it would be, or what I'd have to do to make it reasonable. (And it's more than just the sun2 integration, because like I said, it would probably also require a time zone sensor entity for each tracker, too.) It wasn't really designed/written with this type of use in mind, so that would probably be the hardest part.

[pnbruckner]

@wigster what about an option to create an integration entry based on data provided by a service? I.e., maybe it would start with some initial location values (HA's or static values the user enters), and then it registers a service that can be called to update those values. E.g., sun2.update_xyz, where xyz is the name of the integration entry, and it would accept location data. E.g.,

service: sun2.update_xyz
data:
  latitude: ...
  longitude: ...
  time_zone: ...
  elevation: ...

It would also remember those values across restarts.

[wigster]

This sounds perfect -- it would be great if the sensor contained the current lat/lon in the attributes to cross check if the service call is necessary in the first place.

[pnbruckner]

it would be great if the sensor contained the current lat/lon in the attributes to cross check if the service call is necessary in the first place.

Yes, I can see that might be helpful. Unfortunately, there isn't just one sensor but many. It wouldn't make sense to add these attributes to all of them. But I suppose it could make sense when this configuration is used to create an additional sensor with those attributes. Or, now that service calls can return data, maybe it would make even more sense to have a service to get the current values.

BTW, I'm also working on different options for the elevation option (e.g., when there is a mountain in the way of sunrise and/or sunset), so these services would need to support those as well.

[pnbruckner]

@wigster, please check out the 3.3.0b1 release. I believe it has all the features you asked for. There's a bit more of an explanation in this post on the community forum.

[wigster]

Thanks a lot for this -- it does exactly what I need!

One question though -- what is the time_zone field for? If I ask for noon in London, I see that it is at around 13:00 in my CET timezone as it should be. If I specify "Europe/London" in the time_zone or even "America/New_York" the infomation the noon/rising etc sensors does not seem to change.

Are some specific sensors in local time as specified by the time_zone key and others in the HA time?

[pnbruckner]

One question though -- what is the time_zone field for?

For two things.

First, many of the sensors change at midnight, such as dawn, solar noon & dusk, or recalculate their intermediate data then, such as the elevation & phase sensors. So, it needs to know when midnight is at the specified location.

Second, although the state times are given in UTC (which is kind of a HA standard), the attributes are given in the specified time zone. But you won't notice that when you look at the attributes in the "more info" UI windows, because the frontend displays times in the local time zone, no matter what time zone they are specified in. You'll have to look at the attributes on the STATES page, or via a template or something.

E.g., I'm in the US Central time zone (which is currently UTC-5), and I have a sun2 location set up for London (on my test system.) If I look at the solar noon sensor for the London location, it looks like this:

All the times are shown in my local time zone. But when you look at it on the STATES page, you can see the attributes are actually specified in London's time zone (which, of course, is currently the same as UTC):

[HACS-bank]

I read in some forum post about using HA on a boat - i.e., lat and long constantly change, and are updated from the GPS navigation. After a while, the boat will also move timezone!

Is that scenario worth an FAQ? It might address lots of different questions all at once.