Astro binding: offset for Sun Azimuth and Elevation

Hi,

is there a way to calculate the sun’s azimuth and elevation with an offset? For my automatic shading solution, I’d like to be able to look ahead e.g. one hour.

This is what I came up with so far

Thing astro:sun:homePlus1h "Astro sun data" [
  interval=10,
  geolocation="49.[...],6.[...]"
] {
  Channels:
    Type azimuth : position#azimuth "Azimut +1h" [
        offset=60
    ]  
    Type elevation : position#elevation "Höhenwinkel +1h" [
        offset=60
    ]
}

When I check the resulting channels in the REST API, it looks like it was propagated to the channels as expected:

[...]
   {
      "linkedItems":[
         "Sun_Azimuth_Plus1h"
      ],
      "uid":"astro:sun:homePlus1h:position#azimuth",
      "id":"position#azimuth",
      "channelTypeUID":"astro:azimuth",
      "itemType":"Number:Angle",
      "kind":"STATE",
      "label":"Azimut",
      "description":"Das Azimut des Himmelskörpers",
      "defaultTags":[

      ],
      "properties":{

      },
      "configuration":{
         "offset":60
      }
   },
   {
      "linkedItems":[
         "Sun_Elevation_Plus1h"
      ],
      "uid":"astro:sun:homePlus1h:position#elevation",
      "id":"position#elevation",
      "channelTypeUID":"astro:elevation",
      "itemType":"Number:Angle",
      "kind":"STATE",
      "label":"Höhenwinkel",
      "description":"Der Höhenwinkel des Himmelskörpers",
      "defaultTags":[

      ],
      "properties":{

      },
      "configuration":{
         "offset":60
      }
   }
[...]

However, the values I get from those channels are exactly the same as I get them without the offset.

Do position#azimuth and position#elevation even support the offset?
If they do, I’d be thankful for a hint on what I did wrong :slight_smile:

Best Regards,
Nils

Well, I have no idea whether that is possible within the astro binding, but please note that there a similar issue which I proposed to solve with the small script in this post.This is something external (python) that communicates the values to OH via mqtt, so basically everything of that will have changed from 2.3 to 2.4, but the principle remains. Time offsets are set very easily in that script, as is done in the computation for the “tomorrow” times.

1 Like

I wouldn’t be surprised if the binding doesn’t support that. I suspect what it does is just calculate “now” and then add/subtract the offset and that wouldn’t work for azimuth and elevation. Those values would need to be recalculated for the offset time.

Anyway, a trick you can use is to create a new Thing adjust your longitude by subtracting 15 degrees to add an offset of +60 minutes.

2 Likes

Thanks @rlkoshak and @Rivi for your answers!

I’d like to keep external dependencies to a minimum in my docker-based setup, so I’ll try the subtraction of 15° approach first. It seems really straight-forward and logical.

Maybe I’m going to provide a pull request for the astro binding to support the offset parameter in a similar fashion later. At the moment, I’m a bit hesitant concerning pull requests because the ESH integration and new build pipeline are not completely finished yet and consuming a lot of the team’s time.

I suspect the time offsets apply to calculation results, as opposed to parameters e.g. sunset + 1 is a time value plus 1 hour.
Azimuth being an angle, you cannot add an hour. You’d need an observation location offset i.e. a dummy location, as you’ve already figured out.