Hello,
I am trying to create an offset item for sunrise and sunset.
However there is no offset profile available in the GUI.
Hello,
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.
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.
Thanks.
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 !
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.
Or
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 ] {
Channels:
Type rangeEvent : rise#event [
offset=-30
]
}
Now Iāve created my first textual things-file and it works .
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 .
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.
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?
Integer value in seconds?
Duration similar to expire?
offset="1h 30m 45s"
offset="1h05s"
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 "-"
.
Hi Christoph,
I mean, the first point is the best workable one - with the possibility of negated values.
Many thanks and get healthy!
Henry
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
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)