For a Query addon that I started to develop, the things will be native queries, and I would like to support query parameters from arbitrary expressions.
Minimum requirements for those parameters expressions would be to be able to:
Expressions with current date and variations for example to have two parameters startTime=now-3hours and endTime=now
Expressions with current item values value>ITEM{itemName}
Operations on prior options (add, subtract, comparisons, …) …
Is there something that currently exists to make it more natural for users?
I think that it is not difficult to implement be parsing that parameter expressions with some scripting language like groovy or similar, but just want to know if there is something in other addons that current users are more used to.
I have no direct answer. But here are some things to consider:
Conceptual parameters are intended to be used in a user interface as such that no implicit logic should be put in values that are used as the parameter. So it’s not intended to contain (complex) expressions. For example having some keyword that references to an item is a anti-pattern. Because the user than needs to know this syntax to enter some value. Not specifically not because it’s not allowed, but it’s not what parameters are intended for. So trying to put this in the parameter seems the wrong place.
Talking about items. In general bindings don’t and shouldn’t know about items. So getting are reference to them is not as intended.
Be aware of trying to add yet another parsing language, like your suggestion of using something like groovy. It would make it more difficult for users to use. It might require a lot of extra library dependencies.
Assuming this is about creating queries. I would guess this would be a something to implement with a ThingActions method implementation. Then a user can make the query in a rule, pass the query string and parameters and the user can construct the query in the rule language itself.
Building on this and to take it a step further. It might be possible to create specific Trigger, Condition and/or Action implementation (The building blocks of rules). For example a QueryAction or something. That can be used in a rule and make constructing certain functionality easier. But I have no specific use cases in mind so I don’t know if this really is useful, or if it adds to much complexity or simple to few advancements over simply creating a ThingsAction.
Your things action approach looks very good to me, I didn’t know about them.
Combined with a cron rule will allow to flexibly execute queries and fill items periodically.
And being able to powerfully create complex expressions for parameters if needed.
Just to check I got it correctly, my plans would be to be able to define things for each DB you need,
and the call an executeQuery action on these things.
About the Trigger, I didn’t see the point as I think that a cron rule can do the job.
About the use case is simply to be able to update items with results from native queries.
That has several uses for me, for example integrating with iotawatt device queryn influxdb, more details in that topic
I don’t think I’ve seen an Action yet that does that.
Have you looked at how exec binding works? A model like that should fit the above requirement.
Set up a Thing with basic info, like the target database etc.
That Thing has a channel/Item you can pass params to - your query, here.
Optionally, that passing auto triggers an actual run.
There’s another channel/Item to get updated with results, whenever they arrive.
Another channel/Item for exceptions etc.
Thank you @rossko57
Your approach is similar to what initially I had in mind.
But @hilbrand idea about setting up parameters in rules and the to use actions seems good to me, because although is a little more complicated for the user is true that is more or less an advanced addon, and if the user can write queries in a native language is very probable to be able to write rules/scripts also.
But the approach of being able to combine simple queries on items and then being able to customize parameters on rules that offer exec binding it’s interesting.
Althought I don’t like the need to define custom items just for parameters and have two different rules for an execution (params + real one)
I have to think about that, I want to be able to work only on actions and a DB thing, but supporting item queries at least for parameterless ones seems a good idea. For parameter ones, I’m not sure if it’s simpler to just execute directly in an action.
My idea on actions is the more independent case they can simply calculate the result query and put the value in a manual item.
It’s more or less the way it works a script that I’ve to check inet speed that I copied from here a lot of time ago: Speedtest-cli Internet Up-/Downlink Measurement Integration
Don’t forget this is an asynchronous process that takes time. Stopping a rule to wait for that will be disapproved of.
So, a rule fired Action would in your scheme eventually update an Item. To do anything with the new Item state, you’d want a separate rule listening for the update.
Two rules, either way.
What happens if it fails? There’s no way to tell the Action, unless you stop the rule and wait. There’s no way to tell the target Item, unless you update to UNDEF, which isn’t very informative.
Thank you very much @rossko57
You’re absolutely right about the asynchronous nature of the commands.
I will need to think about that because then possibly having param items would be a good way,althought I don’t like it a lot initially.
Sure, like the familiar HTTP and executeCommandLine Actions. There’s no Item involved though, so the only choice is to return a string synchronously.
I’m not in a position to comment on design philosophy, but I think these are the “cruder” parts of openHAB, supplied so that we can cobble things to work when more elegant solutions are not available or are not flexible enough. They come with a performance penalty.
Note that many Actions have binding counterparts, allowing user choice of methods.
You’re the author and must do as you see fit There’s always choices to made.
Following some of your advice, I’ve updated the addon readme with initially expected usage and I think that now it’s much better than my original intention.
Any critic or suggestions will be very well received.
There’s always choices to made.