[OH3] No offset profile


I am trying to create an offset item for sunrise and sunset.
However there is no offset profile available in the GUI.

That’s correct. The offset profile would not function with DateTime type Items, it is for use with Number Items.

Are you deriving this from Astro binding?
Astro allows you to apply individual event offsets in your Thing settings.
If you want one event with more than one offset, say Sunrise and Sunrise+30 then you can create another Thing.

1 Like

Ahh okay.
I was trying it with OpenWeatherMap.
Is there any way to do it with OWM?

Sure, write a javascript that parses the OWM output, adds your offset, and returns a new value. You’d need to understand what the binding supplies here - an epoch or a DateTime etc. - but it’s just maths really.
Use your script with a transform profile applied to the channel.

Or get what you want from Astro - you can make Things for any location, any offset.

Hello all,

I think it would be a nice enhancement for the existing offset Profile to support DateTime Items too (or introducing a new Profile for it). Thus I vote for opening a feature request on GitHub for discussion.


1 Like

How can I create a thing in the OH3 Astro binding with an offset?
I’ve tried this in the UI:
I think it was the wrong place :confused:!
On which place can I put in the offset value?
Many thanks in advance for a short example!

Simple answer; you can’t create a Thing with an offset.
You can create a Thing and apply individual offsets to its channels.
You create a Thing exploiting that solar events time depends on location. “Offset” the location by 15 degrees of longitude for an hour.

Many thanks for your quick answer!
Unfortunately I don’t know on which place I have to put in the offset. Can you give me a little help with a short example or a screen-shot?

See the docs, search the forum. Come back when you’ve tried something.

I’ve tried something and reading a lot of docs. But I found in this case only docs for textual configuration of things like this in the Astro binding docs:

astro:sun:home [ geolocation="52.5200066,13.4049540,100", interval=60 ] {
        Type rangeEvent : rise#event [

Now I’ve created my first textual things-file and it works :+1:.

But I found nothing for offset implementation in the UI-driven way. I think it is important for the openHAB acceptance for people with not so deep programming know how.
It would be great, then you can show me, how I can do it in this way :handshake:.

So you know that you need to edit the properties of a channel belonging to your Astro Thing. I suppose you might look at those channels in the GUI and see if there are options.

Yes, now I found the solution to create offsets in channels over the UI. It’s a really long way.

1 Like

Hi all,

I will implement a timestamp-offset by the end of the week. What do you think is the preferred notation for the offset parameter?

  1. Integer value in seconds?

  2. Duration similar to expire?

offset="1h 30m 45s"
offset="55h 59m 12s"

For the second approach I not sure if I am able to add support for negated values prepended by a minus sign "-".

1 Like

Hi Christoph,

I mean, the first point is the best workable one - with the possibility of negated values.

Many thanks and get healthy!

I have to say, yet another profile looks like clutter.
“It would be nice” if the existing offset profile could recognise when it is targeted to a DateTime type Item, and modify what it does, but I suspect that may be technically difficult.

On a practical point, people are going to use this to shift timezones. And then get in a knot with DST changes twice a year. An additional suggested use would be to supply a target timezone instead of a fixed offset. e.g. some external service reports in UTC and we convert to local time.

@rossko57 I had the same two thoughts. It would be best to not increase the number of profiles. But when we are talking about applying a timezone - which is a reasonable improvement in the future - we are definitely far away from the original offset profile.

Let’s call it a timeshift profile then :wink:

Is there any advantage in presenting this as a Transformation service instead? It can then still be employed on a generic transform channel link profile, but may have uses in UI display or directly at a binding channel?

Check this out:

Did you test for the issue suffered by other timestamp profiles? (Though I imagine this one is less likely to be used in a multi-linked situation)