[Automation] Absolute datetime module type

[davidgraeff]

There is currently a "GenericCronTrigger" for recurring events, but the core is missing an "AbsoluteDatTimeTrigger".

Do you think it makes sense to add one?

[maggu2810]

Can't it be done by a CRON trigger without wildcards?

[davidgraeff]

For usability reasons.
If we have ui clients that allow users to create rules, users grasp the concept of an absolute date/time field better. It is just 40 lines of added code and 10 lines of json

[5iver]

David, could you provide more description for what an AbsoluteDateTimeTrigger would be? Is it just a specific time of day, does it recurring, every day or certain days of the week, etc.?

I recall there was a PR a while back for a time/date related trigger (or enhancement). Possibly related?

[davidgraeff]

I can even show you the description json: https://github.com/openhab/openhab2-addons/pull/5243/files?file-filters%5B%5D=.json#diff-bd55a2a4a53c76f4d2e35465addd43b3

I have implemented this trigger (and other module types) for the hue emulation service.

Another time related trigger is https://github.com/openhab/openhab2-addons/pull/5243/files?file-filters%5B%5D=.json#diff-3cc0fa19ac95bd0550c20d712c8adf31 (Timer Trigger)

[5iver]

This is what I was thinking of, but it was a condition. Are you planning on a new handler, or maybe using TimeOfDayTriggerHandler? As far as functionality, this is very much needed!

As for ModuleTypes, it would be nice to have as many time-based triggers consolidated into the same one, where the ParameterOptions would become visible/accessible based on previous selections. At least, that is the direction I'm hoping we end up going! That way, the initial dropdown/selection is a short list of triggers or conditions (Time, Item events, Channel Events, Thing events, system events, etc.) that open up with more options. Not something that can be achieved with a resource bundle.

[davidgraeff]

Unfortunately our current config description system doesn't know about dependent parameters.

So to not confuse the user with dozen parameters for a few module types I would rather say we have many module types that do exactly one job right with only a few parameters.

The module types of the hue emulation service can be moved to core at some point when they have proven to be useful.

Check the code. it's not only a resource bundle, but actual Java code.

[5iver]

Unfortunately our current config description system doesn't know about dependent parameters.

So to not confuse the user with dozen parameters for a few module types I would rather say we have many module types that do exactly one job right with only a few parameters.

The module types of the hue emulation service can be moved to core at some point when they have proven to be useful.

Check the code. it's not only a resource bundle, but actual Java code.

I looked for it briefly, but couldn't find handlers.

[maggu2810]

Would be happy about more comments from the automation experts?

[davidgraeff]

The implementation is done and available in the hue emulation service in openhab2-addons.

If others find it useful, we can move that part to core (the package names are already hue emulation service independent).

So might make sense to close this issue here?

[maggu2810]

As long as no one claims that he needs it / find it useful we can perhaps close this one.
At least me will try to remember if I ever need it. 😉

[5iver]

Would be happy about more comments from the automation experts?

Do we have any of those?!

So might make sense to close this issue here?

Sorry I missed this earlier today. No, this shouldn't be closed! This is core functionality that is needed and putting it into an addon would be the wrong thing to do. Same for the HTTPAction that has been added to hueemulation. This should be an update to the existing core HTTP action, which will need to be done anyway. IMO, the PR should not be merged until these are removed. I brought this up 2 weeks ago, with no response from maintainers (other than David).

If others find it useful, we can move that part to core (the package names are already hue emulation service independent).

Yes, please!

[maggu2810]

Would be happy about more comments from the automation experts?

Do we have any of those?!

• My understanding of your latest PRs and comments about scripting and automation has been that you are familiar with the automation. Don't put the word "expert" on a gold scale (exists that phrase on english, too?).
• I also think Kai knows the internals of the automation as he provided already some bigger PRs and refactor of the automation (and I assume he has been always involved in the design).
• My reading of [automation] Sort by filename instead of path #724 has been that there is also a scripting community that uses the automation infrastructure.
• ...

[5iver]

Would be happy about more comments from the automation experts?

Do we have any of those?!

Don't put the word "expert" on a gold scale (exists that phrase on english, too?).

No... don't recall ever hearing that. So, I take it that what you were asking was as facetious as my response? 🙂

[maggu2810]

I will be really happy if there are more comments from automation "experts" or let's say from guys with knowledge (not necessary an expert one) of this subsystem.

I did not realize that your question has been facetious, sorry.

https://www.linguee.de/deutsch-englisch/uebersetzung/auf+die+goldwaage+legen.html

[davidgraeff]

Sorry I missed this earlier today. No, this shouldn't be closed! This is core functionality that is needed and putting it into an addon would be the wrong thing to do.

Sometimes you just need things done.
Core actually benefits it we first perform public tests and real-live usage of those modules and later on move the code (battle tested etc).

[5iver]

Sometimes you just need things done.
Core actually benefits it we first perform public tests and real-live usage of those modules and later on move the code (battle tested etc).

I hear what you are saying, but there could be more usage and testing of them if they went directly into core. And since this is where they would end up anyhow, it is also less technical debt to have to clean up later.