I’ve checked Karaf and I’m using Astro binding built on 27th too. I’ve checked logs too, and the events are definitely triggered. I think I might have found the root of the problem with a rule - after opening rules file in the Notepad++ I’ve found a strange hidden character between keyword Channel and the first quotation mark, instead of blank. I guess that was making a problem with triggering the rule. I’ll see if it will work tonight. Thank you for your help.
The linked example then gives astro.items including the syntax to define an offset (e.g. to display the times on a sitemap). I’ve not seen (yet!) a worked example of rules with an offset trigger but as the feature has only just been added to the Astro binding, there are several people hard at work researching just this point…
Oh no … don’t blame me … I’m just guessing. But I’m working on it … See messages on down in that other thread as we continue to try (or if someone takes pitty on us). If I get it working I’ll post something there for sure.
I recently wrestled with triggering astro events and it works with the following setup:
rule "Lights on at sunset"
when
Channel 'astro:sun:local:set#event' triggered START
then
logInfo("Sunset", "Sunset rule trigerred!")
postUpdate(Sunset_Event, ON)
end
My rule trigger looks exactly like that. The problem was hidden character between Channel and first quotation mark (I really don’t know how it got there), and it was shown only when I’ve opened rules file in Notepad++.
Hello @itheiss, @Ctrl-G, @UglyKidJoe and all the others out there. It would be a big help for everyone, if you could enhance the astro README.md with your findings.
You could enhance the descriptions or give more examples. Both would be great. You can either directly create a Pull Request for this file or create a simple Ticket proposing your changes. If you’ve got a nice set of configured items, rules and a sitemap arrangement around the astro binding, you could also post an article in the Tutorials & Examples category.
when
Channel 'astro:sun:local:set#event' triggered START
then
I wonder about the choosen syntax for events…
To me the above feels a bit “on a different” level than other triggers used in rules. What I mean is that “normally” one creates items to hide these kind of details (the mapping to a particular channel of a particular thing).
It would have been more natural (to me at least) to define the following either in an .items file (or maybe in a new kind of .events file?):
I will gladly contribute to the documentation for this or any other bindings. Being relatively new to OH2 I can help identify where the documentation is thin as I mainly rely on step-by-step instructions, and if it’s not clearly written I would stumble.
I agree and I believe the answer is 1) nobody did define that item type yet and 2) the nature of this item is unclear as an event does not have a value at a given point of time. In OH1 the astro events were simulated by switches being switched on and back off immediately, which is a workaround.
Sounds good. The first step (after stumbling) should be to create a ticket. Noting down your idea for improvement is the most important step, working out the details can still be done later by you or also others. Is there any area you would like to get active? I can help with the details.
I’ll contribute to the documentation through each step of my journey. I wen’t straight to OH2 as a beginner, so my focus would be entirely on OH2 implementations. Hopefully this approach can help eliminate some confusion between the two architectures. I found this to be a bit tricky as a novice. I’ll be mindful about where I can help along the way.
In the OH1 binding, I never understood why the switch state wasn’t defined to mean “the sun is UP” – so it is in the ON state all the time that the sun is up, and OFF all the time that the sun is down. So it’s conceptually no different than any other binary state condition. And of course, altering it by time offsets, say, 30 minutes after sunrise, would just mean the switch is ON from thirty minutes after sunrise, all the time until the ending offset. Any rule triggering on Item IsSunUp changed to ON would catch the moment of sunrise. Every time the job doing the calculation is run, it simply updates the bound switches to whatever the correct state is. Simples!
Regarding the different events you might want to check here: Explanation of eveningNight and morningNight
As you can see the idea was I believe to have the event of the sun passing the horizon as one distinguishable state rather than “The sun is up”. Why? I don’t know. I also had a rule to generate this state.
Regarding the events: not everything can be represented as a switch between states. It’s possible of course but not always meaningful. I believe more motivation is available in the respective PRs.
Maybe @kaikreuzer wants to say a few more things regarding events/triggers. Many, me included, are still not quite familiar with this silently arising new concept.
/**
* Publishes the item state ON/OFF for scheduled events.
*
* @author Gerhard Riegler
* @since 1.6.0
*/
public class ItemJob extends AbstractBaseJob {
@Override
protected void executeJob(JobDataMap jobDataMap) {
String itemName = jobDataMap.getString("itemName");
context.getEventPublisher().postUpdate(itemName, OnOffType.ON);
context.getEventPublisher().postUpdate(itemName, OnOffType.OFF);
}
}
So the Astro 1.x binding toggles a switch item, instead of putting it into the state that means “the sun is up” (for example). The point is that a rule can easily trigger on changed to ON, but subsequently other consumers would want to know the binary state of the sun. One can of course add a rule and another item to represent this, but I never understood the reason to treat the condition only as a trigger instead of a change in state, directly from the binding without needing a rule to achieve it. The same thinking in the 2.0 binding of using a Trigger channel seems to apply, but I’m not sure of that.
By the way, thanks for the link. My thinking is each of the entries in the table could be:
MorningNight ON 00:00
MorningNight OFF 04:00
Night OFF 05:02
AstroDawn ON 05:00
AstroDawn OFF 05:45
NauticDawn ON 05:45
NauticDawn OFF 06:27
...
Night ON 21:33
EveningNight ON 21:33
EveningNight OFF 00:00
