Only these can be used in rule triggers as shown below. Note that they have their own offset configurations that are independent from offsets configured on the start or end times of e.g. the rise or set channels.
yes, it is.
First of all try to link an item by MainUI. You will see that your item needs to be of type „string“ and you need to provide a profile (Trigger Event String).
You could also provide a timestamp to your item.
Event Channels are not really supposed to be linked to Items. Event Channels represent momentary occurrences, not a persistence state.
Each solar event has four Channels, the start Channel, the end Channel, duration Channel, and the Event Channel. Why do you need to store the sunrise event in an Item? Once the rise event occurs, it’s pretty much meaningless thereafter.
This strongly smells of an XY Problem. There is almost certain a more appropriate approach to achieve your overall goal.
If you need to trigger a rule when sunrise starts or ends, use the event Channel to trigger that rule directly. No Item required.
If you need to know when sunrise started or ended or if you are between the start and end, link the start and end Channels to DateTime Items and compare now with the states of those Items. If you want to know how long sunrise takes, you don’t even need to do the math yourself, just use the duration Channel.
I can’t think of a single use case where you would need to put “START” and “END” into a String Item to achieve anything you’d need to do with a sunrise event.
That’s the part that makes this smell like an XY Problem. You can already get the date time from the start and end Channels. You can trigger a rule directly from the event Channel, no Item involved. So what’s the use of linking the Event Channel to an Item? It doesn’t provide anything that isn’t already available.
I have linked all my alarm triggers to persisted items. In case a device triggers an alarm and for any reason that alarm cannot be processed (rule terminates because of syntax error, OH crashes, …) that alarm will be gone. If you link an alarm to an item, that alarm is still there and at least you can create a popup widget that shows your alarm even if OH crashed before or your alarm rule terminated.
I’m not questioning the use of the profile in general, though your use case sounds like a poor design in the binding and there should be a “lastAlarmTime” Channel or some such.
What I am questioning the utility of doing this with the Astro solar events in particular. There are already state Channels that provide all the information needed to do anything related to the Astro event. Linking the event Channel to an Item adds complexity with no benefit.
That makes some sense. In 1.8 and early 2.x versions, there wasn’t such a thing as an event Channel. So Astro “faked” it by toggling an Item when the event occurred then toggled it immediately off.
Since the creation of event Channels, such momentary events which do not carry a persistent state are supposed to be represented through these new Channel types which can directly trigger a rule instead of needing to go through an Item.
Other cases where you might see event Channels are button presses, motion detection (though a lot of bindings still use state Channels for this unfortunately), etc. In general, any time where once the event has occurred there isn’t a meaningful state to keep track of an event Channel should be used. (Note, this is why I said above that @Oliver2’s use case points to a bad design since the time of the alarm is a state that should be stored in an Item).
Another thing to note is that you can trigger a rule based on the state of a DateTime Item. So in the case of Astro you could use the DateTime Item for sunrise start as the trigger to the rule and the rule will trigger at that time. So theoretically Astro could eliminate the event Channels entirely. But I don’t see that happening because it would be quite disruptive out of proportion to the benefits.
got your point regarding astro binding.
Just to complete my use case, it is not just about the time of alarm, as that would not help in case the rule terminates or OH crashes because the event triggering channel also submits the type of alarm (overheating, overvoltage, etc). There are several alarms per device and no alarm trigger channel for each individual alarm type. In case of rule termination or OH crashing I would know the time but not which alarm has been risen.
To me that is a very good approach how the binding handles alarms.
I don’t argue that. I argue that the binding is not modeling this very well. Overheating, overvoltage, et al are states. The device will be overheating for some period of time. They are not instants. Therefore these should be captured in state Channel(s) somehow.
The fact that you are using the profile to work around this doesn’t change the fact that the binding is modeling this wrong in the first place.