I would expect that you would implement your algorithms as a module (i.e. library that can be called from Rules) so, from a user’s perspective, it would be called pretty much the same as an Action which is what Hilbrand’s recommendation for implementation would be.
Right, so you would submit the algorithm to the Helper Library, and the user would write in their Rule:
from community.lars_algorithms import foo
# in a Rule somewhere
result = foo(value1, value2)
When submitted to the Helper Libraries, it will be installed and available to users as soon as they install Python support, which will be installed by default in OH 3 if current plans see fruition. Note, at that point the Helper Libraries will become part of OH proper I expect and not an external repo like it is now.
The alternative with having it as an Action would be
result = actions.getAction("lars_algorithms", "some thing ID").foo(value1, value2)
Still pretty easy so I’m not really arguing here between one approach or the other. But I don’t think you understand how Scripted Automation currently works and is expected to work because some of your arguments comments about it don’t make sense.
Eventually we will get to a point where users put stuff like this in something like the Eclipse IOT Marketplace and users find and install Rules and Modules just like they install add-ons. A lot of it is already in place.
There a number of things you can do for this. All of Python is available to you so you could:
- store it in a variable
- store it in a file
- store it in Items (you can create the Items from your code if they don’t exist or have configuration, see below, to have the user tell you what Items to use)
Absolutely, and this is supported today with several configuration options available to you.
- have the users provide a Group or Item to use with the values you need, right now there is a configuration.py file (or what ever language you are using) for that but that will improve I’m sure
- Item metadata for more complex data (e.g. a light Item that has in metadata defined when it turns on and to what dimming level based on a Mode state machine)
- when we get to the ability to find and install rules and modules, you will have a form to fill out when you import/install them to provide the configuration data
Again, I’m not arguing against a binding/action. But a Rules module is also viable from a user’s ease of use perspective I think.
Given the dependency on information from other bindings required to drive these algorithms I wonder if the configuration of it all through Things would become a nightmare. I’m not even certain it’s possible for a binding to access the values of Items that are not linked to it’s own Channels. I’ve never seen that.
Given this cross binding requirement outlined in your scenario, I think using scripted automation would result in a better user experience over all. Orchestrating activities between the various bindings is what Rules are for. But that’s just my opinion.