I think it would be useful even with a very simple documentation, since there is so much quantity of code to look through and learn from. The more we have in the Community section, the better. I am putting finishing touches on an addon that installs Jython (and the helper libraries). After that, I plan to put some time into dumping all of my scripts into the repo as examples.
Oh thanks for the nice word. Actually much of it has evoled from asking in the community and learning (“debugging”) the hardway with print statements. So much of the credit belongs to somebody else, I am just good at using Ctrl+C / Ctrl+V 
2 Likes
Looks very interesting. My only concern is the dependency on the Astro 1 Action. I fear that this may not continue to be supported in the long term if/when the 1.x compatibility layer is dropped.
I probably won’t have a chance to look at the code soon but will do so. I’m wondering if this can be made more generic and less focused on lighting only. I really like the idea of the rule count idea and can see benefits for other things like call for heat. But, as with dimmers, you will have to figure out how to manage conflicting calls (e.g. one Rule calls for 50% and another one calls for 75%, which one wins?). Maybe there can be rule a priority?
I think this overall approach will come pretty naturally in the UI based Rules where it will be super easy to write Rules that follow your exact input, condition, output type pattern
I agree. My problem right now is that the Astro Action best suits my needs. I was trying if I could setup a channel trigger for the Astro Binding, but it didn’t figure how to trigger this on startup (where I would need initialization of Astro data). I didn’t spent much time on it so there might be a solution. I guess it could be done somehow, just need the 10 minutes to figure it out 
It can be made more generic. SInce it was started about the time when the first release of the predecessor of openhab-helper-libraries I think a lot could be “optimized”. This job is in progress.
One of the reasons I didn’t implemented it (besides from time).
Can you give me a pointer,s o I can start documenting already? I really like the idea of doing it the right way from the beginning. Rework takes too much time .-)
To start, fork the repo and then clone your fork. Open it in VS Code and create the directory structure… /Sphinx/Python/Community/[friendly name].rst. Then create a directory /Sphinx/Python/Community/[friendly name]/. Take a look at /Sphinx/Python/Community/ideAlarm.rst for an example.
I know you have done some development, so I’m assuming this is all pretty straight forward. If not, I can help you through it or you can just provide the text and I can submit it for you.
1 Like
Use an Item linked to the Channel. The Item will get the DateTime of the event. That is how my Time of Day DP works, both the Rules DSL version and the Python version. In fact, my Python version doesn’t use the Channel triggers at all any more and only relies on the DateTime Items. That way it can work with any source of a date time, and not just those bindings that provide a Channel trigger at a given time. For example, you could use your Android alarm clock time which can get send to OH through the Android app as the start of the MORNING time period.
The Rules DSL version can only use Astro Channel triggers or statically defined times to drive Time of Day.
Another alternative would be to use the elevation or azimuth Channel linked to an Item. That should tell you when the sun has gone down. But even if you look at the Rules DSL version, you will see how I manage figuring out the current time of day at system started by using the Astro Item that corresponds to the Channel event.
Both versions of the code are available at [Deprecated] Design Pattern: Time Of Day. The version I submitted to the Helper Libraries uses Ephemeris so you can have different times of day for different day types.
I guess that would still require the Item to be persisted?
Or will it be initialized during startup?
In my experience Astro will populate the Item long before your Rules will start executing. I’ve never had that not happen. But if you do, then yes, persistence with restoreOnStartup would be a sufficient mitigation to ensure the Item has a value before the Rule runs.
It is not impoortant if it is ready or not when rules is executed first time. The problem will be if I need to wait until it is triggered by an event.
I think a simple way would be to either allow items to be provided in the setup, and then check if the link is correct :-). I guess that could be done programatically.
Another way to go would be to create items to store the values behind the scenes, that would also work.
The Item get’s populated with the current day’s value when the Astro binding first starts up and 30 seconds after midnight. It’s completely independent from the Channel trigger.
It sounds like it could work then.
I might prefer to create my own item, behind the scenes. because I would really like to be independent of items changing over time in a config, as well as the item could (theoretically) be manipulated in some other way.
Hmmmmm. No excuse to get started
It seens quite straight forward…
Another option… the Mode (Time of Day) example may be of interest. It allows Modes to be configured in configuration.py using times and or Channels.
As I understand the Mode (Time of Day) it requires separate configuration. The Astro Action allows me to use already configured values (lat. / long. from openHAB system settings). So there is no need for any additional config, the drawback of the alternative solutions is that I need to rely on something not under my control.
I am also considering if the code from Astro Binding could be activated, the drawback of this, is that it requires Astro Binding to be installed.
There is certainly enough options, ikt is just to identify the one that best support the needs 
Correct, but isn’t user configuration needed to choose the appropriate Astro event? Lots of options… I love it! I just wrapped the Jython addon and included the helper libraries… installs everything in one click! Hopefully, there will be even more people providing even more options!
Yes and No. If you have setup Lat. Long in openHAB system settings, then the value is read from there (unless antoher value is configured specifically). And Yes because you need to configure it in openHAB settings (if not done).
I was thinking more along the lines of configuring which Channel/event is used for sunset or sunrise. Civil, nautical, etc., everyone has their preferences.
Yes, but I’m not recommending that you adopt Time of Day or Mode. I’m recommending that your use it as an example for how you can do this without the Astro 1 Action. You will have to do it at some point anyway when the Astro Action goes away so why not do a little bit of work now to not become broken in the future? The fact that to use this one would need to have both the Astro 1 binding and Astro 2 binding installed, since 90% of us have long since moved to the Astro 2 binding, is a big draw back as well.
When you set your lat long and install the Astro 2 binding, an Astro Thing for that lat/long automatically get’s created and shows up in your inbox. So it’s not like users have to go out of their way to do a lot of complicated configuration. And most will have already installed and set up their Astro Thing anyway.
And I’ll second Scott’s comment, users will want to configure this anyway. For example, I live up against the mountains. The sun actually goes behind the mountains an hour or more before actual sunset. I need to account for that in any of my Rules that care. So when using a library like yours, I want that control.
That would definately be an option
I agree with you
I was thinking of an simple mode along with the option for advanced mode. The first option should be more or less to use what is already configured in system settings, without the need for mapping items in a config file. People like you and I off-course need the option to configure everything detail. For that I would make it possible to configure astro settings in the config. I have thought of supporting some keywords in my schedules, eg. like sunsetStart and maybe even with the option to add a time offset, omething like this: sunsetStart - 30m The latter means that the time is 30 minutes before the Astro event sunset start.
I completely agree that I need to find something else than Astro Action in the future.
So bottomline I guess we do agree .-)