Meta binding / rule advisor - looking for ideas

Add-ons Bindings
1

I was working on calculation of “efficiency” formula of my ventilation unit today and I’ve come to following idea.

openHAB currently have no way to “propose” new things (or rather items) which could be added to runtime based on other available items and their metadata (called semantics as far I understand). For example a very basic electricity meter or water meter or pulse converter can report always increasing value such as “water consumption”. It is possible to calculate “water flow”, “power consumption” and so on based on updates on this thing. Yet there is no easy way to let user know that there is applicable formula available for him. We do have rule templates, however I haven’t seen many examples of their use.

For me, a (very) lazy user such thing would be a very good addon which would allow to tune my setup quickly and provide useful insights into my house. More over making such formulas somewhat available at public index allows to advice users on what kind of input they might add in their homes to get more useful insights.

A prime example could be a recuperation unit where it is possible to calculate temperature efficiency. Some units have only supply temperature sensor and lack “efficiency” report from controller. Adding two additional sensors on pipes (return from building, intake) allows to measure temperature efficiency. With air flow sensor (built-in or additional) it is possible to calculate reclaimed power.
On top of above a basic power meter of the ventilation unit circuit it is possible to calculate power efficiency of the machine (reclaimed/consumed power).

I believe there is even more generic examples which could add a “gamification” factor to OH, increase user experience (let say), let users optimize their properties easier, tune Wife Acceptance Factor and promote re-use of most common computation logic. Do you see above conversation happening:

- My dear, could you please pick up next optimization or finding we look for in our house?

Remember that acceptance factor depends on person who made decision about investment, so let them decide! :slight_smile:

Cheers,
Łukasz

2

This doesn’t sound too far away from the Weather Calculation binding. Generating derived weather calculations with the Weather Calculations Binding. It’s not a merged binding so I don’t know how acceptable the overall approach is to the maintainers, but at least there is precedence.

How would you envision this working from the user’s perspective? Actions in Rules? Channels? Profiles? A combination of these?

The challenge from a usability perspective I think is how do you give the data to the add-on in the first place and then get the answer back given that the data may come from Items linked to all sorts of different bindings. I don’t have any experience with the Weather Calculations add-on so have no opinion on how they chose to do it (I don’t really even know right now).

3

Hi- I wrote the weather calculation binding, so I can provide a little information about the approach.

Basically the way it works is we have a set of data points we need in order to make calculations (think things like temperature, wind speed, etc). The binding configuration asks you to specify where to get these data points; for each one you choose the correct source item from a dropdown of items that provide the right data type.

Then, the binding subscribes to value change events generated by those items. Every time a value changes, it’s passed to the binding and we use it and the values we’ve stored from events sent by the other data sources to produce new values for the items that the Weather calculations binding provides.

The new rules engine works in an identical way under the covers. The mechanism is very nice: event messages are generated and listeners can register to receive these messages based on sender, etc… basically an event bus.

Certainly if you wanted to have a binding that had items whose values were based on other, unspecified items that you configured at runtime, I think this would be the optimal way to do it. As it stands, the binding I wrote provides a fixed set of meta calculations. I think that’s a useful pattern for a lot of problems. A more ambitious project might have some sort of way for that to be dynamically extendable. I’m happy for anyone to use that code as a source of inspiration or basis for something else. I’m also happy to answer any questions I can about the approach.

4

Thank you both for pointers. Indeed the goal of weather calculator and what I posted above is the same - do some math on top of existing items.

As for now the discovery of things is possible from bindings and they do pretty much everything. The dependency injection mechanism we have allows to inject to discovery service pretty much everything offered by framework, including ItemRegistry to do initial scan in order to find necessary elements.
Once this is done we jump into usual routine.

What is needed from high level:

  1. discovery service which will offer new calculations
  2. some kind of index of calculations, stating what goes in and what goes out
  3. way to distribute algorithms (if they are not full blown bindings)

I need to experiment a little bit more to see how many commonalities are there.

5

Some time ago when I was reviewing rule templates I noticed that some of them had a “filter”, “criteria” and “context” as part of configuration. I was able to exploit a little bit UI by declaring channel with extra context parameter:

      <parameter name="extractTemperature" type="text" required="true">
        <label>Extract temperature item.</label>
        <description>Name of the item receiving ventilation system extraction temperature.</description>
        <context>item</context>
        <filter>
          <criteria name="type">number</criteria>
        </filter>
      </parameter>

It turns out that config parameters are always processed in same way, at least by current paper ui making it possible to add “item” selector to a binding without forcing user to type them manually. Based on quick source code lookup there is also support for items coming from specific binding, tags and selected types. Context can be set to a Thing too!
Below screenshot shows complete nonsense (its a test instance), yet you can see item dropdown while editing thing form. One achievement completed. :wink:

image
image1910×1251 227 KB

1 Like
6

I’ve been thinking along these lines too - and I think this concept would radically improve maintainability of Items and Rules. Here’s how I would like it to work.

example.items:
Number:Temperature Estimated_Window_Temperature "EWT [%0.1f]" <temperature> {calculated="0.7*Outside_Temperature + 0.3*Inside_Temperature"}

This would define a new Item which is a calculation of two others. The Meta or Calculation binding provides a new Item value whenever either of the referenced Items change.

In this way, you can see how an Item is defined without having to look into the Rules that you would currently require to set it. To me, this seems much more intuitive and maintainable than the current way of having to have a separate Rules file.

Ideas

  • Allow calculations to be defined in the binding config file, to enable DRY.
  • Reference Channels and Items
  • Enable for Switch Items (i.e. allow complex boolean logic)
  • Enable for String Items
  • Have an entire JavaScript engine behind it?!
  • Allow use of historical data about Items (e.g. Outside_Temperature 30 minutes ago)

Thoughts?

7

An alternative way to position this would be as a profile with access to multiple Item states.

Well there’s a perfectly functional rule engine already …

Putting those thoughts together …
[channel='balh:bleh" [profile="rule", function="mySpecialRule"]
where the rule has access o everything rules usually do, like persisted data and other Item states.

You would need to invent some instruction or pigeonhole for the rules to pass back it’s single result for the channel to use.
Or maybe you wouldn’t, since the rule can update the target on its own. The channel can just stop, do nothing.

8

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.

9

I think you’re right, at the heart of my ongoing frustration with OH configs is

  1. the need to put Items, Things, Rules definitions in directories based on what’s being defined rather than the functionality; and
  2. the use of different files for Items, Things, Rules etc.

I can live with 2, but 1 I find very strange. I think it would be logical to group all my lighting Things, Items and Rules in one directory and my HVAC in another and security in yet another. Technically, I expect it would be simple to load all config files under the OH conf directory, regardless of which subdirectory they’re in.

I would be interested to know about this deliberate design choice, if you could point me in the right direction to a discussion?

Also anywhere I could put my 2c in as the NGRE is discussed.

10

You would have to dig back in the github archives 10+ years from now as it’s been this way since the beginning.

From what I understand, the separation is because the three represent very different concepts. Things represent the connections to the devices. Items are the model of your home automation. Rules are the behaviors of your automation. Hence the separate files.

I can’t offer anything about the separate folders requirement. And maybe something could be done there.

I don’t think you would get any traction with a proposal to put everything into the same file though.

If you wanted to eliminate the .items files, you can create and modify Items from OH 3 Rules Engine rules (NGRE) and have your Items and Rules in the same files. I don’t know if you can create Things from a rule though, at least not without interacting with the REST API directly.