Closed mueller-ma closed 2 months ago
I like the idea.
The only tricky part is what should happen if the Item changes within the offset time? For example, if the Item changes and the offset puts the time into the past, should the rule trigger or should the rule be skipped this time around?
In the mean time, for astro events at least, you can apply an offset on the Channel config. In all other cases you can use a proxy Item and a rule to update the proxy to the changed time with the desired offset and use the proxy to trigger the rule.
you can apply an offset on the Channel config
Yes, but I can only apply one offset. However I want to turn on lights when it starts getting darker and lower blinds when it's dark. For now I'll use the three different types of dusk as triggers: nautic, civil and astro.
i've not tried this myself, but I'm wondering...
If you create your Astro thing using a .things
file, can you define additional channels on the thing (e.g. the dusk channel), each of which is defined with a specific name (e.g. lights-on, blinds-close) and a specific offset?
@rkoshak WDYT? Would this be possible?
The binding would have to be made to support it and I doubt it has. It's worth an experiment though. I doubt it would work though. It could be a cool addition to the binding though.
Yes, but I can only apply one offset.
Yes, I know and that's why that approach is just a work around, not a solution. I really like the idea of adding an offset to the Time is Item trigger. It would work with other bindings too like iCal
Another approach is you could create a rule that triggers when an Item linked to Dusk changes and update other DateTime Items with the Dusk time plus/minus the desired offsets. Or you could set timers to call your rules you want to run at the various times and avoid the extra Items.
Yet another approach is you could use a script transform to add/subtract an offset of the time coming from the Astro Channel before it gets to various Items. This approach doesn't need rules but does need more Items.
(function(input, offset) {
const baseTime = time.toZDT(input);
const offset = time.Duration.parse(offset);
return offset.addTo(baseTime).toString();
})(input, offset)
You can pass the offset
as an argument to the transform using URL formatting (e.g. <id of transform>?offset=PT1H
. Use ISO8601 formatted durations for the offset which supports both positive and negative offsets so this one transform will support going both directions. If JS Scripting isn't your thing, any of the rules languages should work too. They all support passing in arguments like that.
The binding would have to be made to support it and I doubt it has. It's worth an experiment though. I doubt it would work though. It could be a cool addition to the binding though.
Looks like a non-starter. The DSL syntax for a Thing doesn't allow a group (e.g. sunset
) as part of the specification for the channel id. So you can't do sunset#start
. And that would be necessary to specify the manually defined channels.
{
Channels:
Type sunset#start : lights-on "Turn Lights On at Night" [ offset=-60 ]
Type sunset#start : blinds-down "Lower Blinds at Night" [ offset=-30 ]
}
So no real point in even looking at what would be required in the binding.
So no real point in even looking at what would be required in the binding.
Maybe all is not hopeless. The binding could be made to support defining wholly new Channels similar to the way MQTT and HTTP do and in the configuration part of the channel definition we could supply the name of the already existing Channel upon which to base the times. Then maybe that one Channel config could generate the three Channels (start, stop, and event).
{
Channels:
Type custom : lights-on "Turn Lights on at Night" [ base=sunset, offset=-60 ]
}
One could even get crazy and create wholly new solar events based on sun angle, create a different offset for start and stop, or stuff like that if one wanted to.
I'm not sure there's a lot of demand for something like this though and I imagine it would be a lot of work. It would be easier to change the Time is Item trigger to support offsets I think to get to the same end result.
This issue has been mentioned on openHAB Community. There might be relevant details there:
https://community.openhab.org/t/subtracting-2-hours-from-datetime-item/156582/9
I'd like to use the trigger "at the time specified in an item's state" for a rule, but be able to configure an offset. Then I can define "trigger one hour before sunset".
Your Environment