Binding or Service ? Service Code Template

I’d like to develop some optimisation algorithms (heating and energy consumption). to build it with rules is not that nice to handle i would like to encupsolate in a addon.

doing that the openhab way, what would be the best way to start ?

i think it should be a service, bindings are mor or less device related …

does an service template exits ?

Thanks in advance

Lars

There is no template. What you’re describing sounds like a trigger or action assuming it reacts to input from items and controls other items. There isn’t a lot of documentation on this, so you probably need to look at how it’s actual implemented in other similar cases in the code of openhab-core. I did some work on a pid controller implementation some time ago, but the code needs a lot of cleanup, but it might give you an idea of what it could be.

1 Like

I don’t think there is any template which you could follow and there is a diverge in the community on how to address such cases. For example @george.erhan who wanted to donate first version of PID controller was targeting a binding due to latency. Later he was told to use rules and now suggested way is a Thing Action. George’s binding idea wasn’t accepted cause it didn’t fit conceptually.

My suggestion would be to clear it upfront here or better using github issue before spending any significant time on it.

I think it’s not that unclear. A binding is something that communicates with something external that has a state. If it interacts with items it is rule related, like trigger or action. My pid controller is the re-implementation of George’s binding. But certainly true to ask for advice here.

If somebody needs to ask a question and can not find proper answer in architectural/project guidelines then it is not clear. I know you took extra mile to help George and I do appreciate that.

My criticism is rather against a unwritten policy of what is accepted and what’s not which quite often comes out when donor brings a working PR and then have to go over lengthily process of fitting into not that clear boundaries.

When I go to high level documentation about Things I see following:

I’ve checked binding development documentation and it states below:

Rules part:

While adjusting heating settings might be seen this way it might be also a continuous process on its own. Making a rule for that quite often results in additional “proxy” and “state” items which are used only temporary because rule can not have a state while thing in the binding do have.

This means that in one place of documentation Thing might represent a functionality, but when such functionality is brought in a binding, it can’t. More over there is no way to create a Thing without a binding so naturally some computations will fall into this category.
From second part of documentation it seems that if PID runs in a process next to openhab, which can be even feed from openhab, is fine to have a binding, but only then. Having same functionality implemented on top of other binding, without leaving OH (which is in essence a software service) is forbidden.

Don’t you think that making such fine separation is not that obvious?

Certainly true. Specifically there lacks some documentation related to how to implement a trigger/action.

This can be implemented as a Trigger. A trigger can contain internal state, have properties. So it doesn’t need to be a Thing. And that trigger can then be used in a Rule. Isn’t that what is needed to implement this?

Optimization of heating and energy consumption algorithms sounds more like automation to me than an addon. I’d not attempt anything involving the rules DSL though. Take a look at the new rule engine with scripted automation, Jython, and the helper libraries. You can use other languages, but Python is much more suited for writing automation, the helper libraries are much more advanced, there are more community contributions, and there is more support for it in the forum. Currently, scripted automation may not be as user friendly as an addon, but it is more powerful. It is also a much easier sandbox to play in while experimenting, before moving on to build an addon.

That may be true for the old rule engine and rules DSL, but it is definitely no longer the case with scripted automation.

The proportional integral derivative controller is not specific to climate control, it is much more helpful than this (it is used in a very wide range of applications, e.g.: motor speed control, lighting control, etc.). Indeed rules DSL can not provide the necessary speed of reaction, so I had to think about a binding that for all that it provided, offered a much better response time. I am testing a Jython script approach and I will let you know if things are as good as you say they might be.
The binding approach was mainly developed because of the existence of other similar bindings (e.g. Astro Binding).

Not 100% correct! In the PID control, you always have the time elapsed parameter, the trigger is involved only when the setpoint or measured value change, until then the whole loop has to increase or decrease the output according to specified constants/parameters.

An openHAB trigger implementation can run an internal schedule and both reacts to external input, like state changes from item representing setpoint or measured value. Here the word trigger is not used as the act of triggering, but the openHAB concept of a Trigger. Does that make sense?

1 Like

wow, that are a lot of informations …

what i have:

  • i know about rules, scripts and could use them for my own implemention, i tried new rules engine, for a simple rule really great but not for really complex things
  • i would like to provide an algorithm (heat, ernergy consuption) more user friendly, and i would like hide that complexity
  • the algorithm more or less has to handle (store/update) future data, like forcecast temperatues or energy prices
  • for the user it should be just an configuration (traiff informations, forecast source)
  • you are rirght the binding/service/action generates timeseries/states, maybe comparable to astro binidng
  • is triggerd by time 1…3 seconds

mayby one usecase could be:
load the eclectric car on energy prices below x or pv generation or at certain time. future energy prices are on 1/4hourly basis

just one case

do you think a binding like astro binding is the right way ? does the bind may run the service loop every 1…3 seconds an fetches informations about other item states like items from the kostal binding ?

thanks in advance for the discussion!

Lars B.

In what ways is it insufficient for really complex things? You have all of Python or JavaScript or Groovy available to you. Are you saying that Python is not suitable for complex things?

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.

Thank you very much for your explaination!

I would like to have an GUI for doing theparametrization, if this also available for an action bundle (action triggered by time/update of diffrent thing values) great. could point me the documentation ?

i haven’t worked with actions…

thanks in advance

where do i configure actions ?

i would like to pass: pv generation, energy consuption, ac power lovel wallbox to the action, it would be great to provide a gui to the user …

To the extent that a UI is available for an Action, it’s the Binding Thing configuration UI. The way that I would see it working is:

  1. User installs your binding
  2. User creates a new Thing
  3. User fills in the configuration properties on the Thing.
  4. The user optionally creates new Channels on the Thing, filling in the configuration properties for the Channels.
  5. In a Rule, the Action is called like I showed above. The configuration is stored on the Thing configured in steps 2-4. You tell it which Thing’s configuration to use by passing the ThingID when you call getAction.

See the Mail, Telegram, or MQTT Bindings for examples.

Alternatively, you can have the user pass in those values as arguments to the Action which may reduce the amount of a priori configuration required.

For a Rule import, a form would be presented to the user after the import with a form to fill out to create the settings. I’ve not tried this yet, I’m not sure if PaperUI implements it. But that is the vision as presented by Kai and I believe everything else is there to support that even if the UI is not.

For a Helper Library submission, the user would open configuration.py and define some variables needed by the module/scripts.

If you mean rule templates, the user imports them and then creates rules based off of them. The Triggers, Conditions and Actions are populated in the UI, but the user needs to fill in the the specific Item’s to use in the Triggers and Conditions. They can reconfigure everything just like any other rule. Imagine a UI rule where the Items haven’t been configured… that is where you start after creating a rule from a template.There are no forms to fill out, but things like Item states in Conditions might need to be given values.

I’m basing what I said on the talk Kai have a long while back where he presented importing and using rules. He showed a configuration UI where the Rule’s configuration parameters, stuff that currently goes into configuration.py, gets entered into a form. I’ll try to dig up the YouTube link when I get to a computer.

If that is no longer part of the vision I think it’s unfortunate and a bit of a usability hit over all.