That is an OH 1.x style binding config and would not be allowed for a 2.x binding. And since 1.x bindings are now deprecated I’m certain no one would approve such a binding for inclusion into OH proper.
As rossko57 indicates, doing this sort of thing with a Channel is, by design, intended to be accomplished through one of the following mechanisms:
- profile
- rules
It appears that your primary objection is that you have to move to a different file in order to define calculations like this. And this was a deliberate design choice by the developers of OH.
I’m personally ambivalent about this personally. I can see why some might like to have everything all in one file. But I’m personally already annoyed at how much is actually in the Items file already. Where it me, I’d get rid of the Item label from the .items file. Items represent the model, sitemaps/habpanel/habapp represents the view and the label is a “view” thing.
I’m all but certain that a binding that does this in the way you propose would not be allowed. Beyond that, I’m about 80% certain that bindings don’t have direct access to the Items in the first place so it might be impossible to do technically too (without changes to the core which would not be allowed).
Similarly, a transformation is not able to do this because it too does not have access to the Items.
So that leaves us with Profiles and Rules. Profiles have two significant limitations that make them unsuitable for this at this time. Those are the fact that they only work with Channels and the result can only be applied to a String Item.
That leaves us with Rules. But all is not lost. With the OH 3 Rules Engine (formerly called the Next-Gen Rules Engine, NGRE, JSR223) one can define Item metadata (see Design Pattern: Using Item Metadata as an Alternative to Several DPs). Item metadata looks like an OH 1.x binding config on the Item. In fact, I took advantage of that fact to write a drop in replacement for the Expire binding (see Jython Drop-in Replacement for Expire 1.x Binding) because when you uninstall the Expire binding, the binding configs become Item Metadata.
So, if you define Item metadata that looks like the above you can have a generic set of Rules that trigger when the relevant Items change and recalculate the state of the Item with the result.
It’s definitely not going to be easy as you’ll have to parse the formulas and tell the difference between numbers and Items and all that fun stuff that comes up when dealing with formal grammars.
I personally don’t see that the benefits outweigh the costs but all that really means is I’m not going to do it myself. If you see a great advantage in this, than the above is I think the only viable approach that will fit within the existing constraints of the OH project.