More advanced addons

I wanted to publish this idea that has been floating around my head for a couple of days now…
Openhab is super easy to use in many ways. Bindings make it very easy to integrate hardware, but it is necessary to code my own rule for enabling functionality. I love the way I can interact with my hardware and the level of control it gives me, but sometimes it might be better to provide the user with a little more polished solution.
Now my idea would be to provide some kind of interface to developers to create something in between a rule and a binding. For example, this could be an app running inside openhab that sets up a rule (maybe transparent to the user, but it doesn’t have to be) to analyze the state of the washing machine using a power meter. The user could be guided through this process by a dialogue. I think this would greatly improve on the number of things users can do with openhab, as repetitive tasks do not need to be performed by every user, but instead can be offloaded to a program that is designed to solve this.
These apps might include interfaces, analysis and computation, or just dialogues that make textual configuration of existing functionality more intuitive to use.
I would be happy about any feedback if such functionality is in the works already, or what you think about it.

Does the new Marketplace fit the bill?

There’s even already exactly the washing machine example you postulated

1 Like

Well, seems like my idea is a little late. Happy to see this coming!
Thanks for the clarification :slight_smile:

Indeed I think the marketplace and Rule Templates fit the bill here. Now’s a great time for advanced users to start creating stuff to populate the marketplace so we can work on making the developer’s experience a little better by finding the pain points and have a good collection of stuff for users to install and use when 3.2 is released at the end of the year.

I’ve already filed one issue to support having more than one rule template per post to the marketplace. It should be relatively easy to support in JSON but right now it’s one-to-one which makes posting a solution that involves more than one rule that interact a little challenging and tedious.

Nothing really blocks you from doing your own thing which does more than rule and less than binding. The reality is that openHAB has limited capacity to accept things falling into “border” or “very specific” category. Overall rule of thumb for core and addons is that you must align with principles.

From what you said I sense that you’d like to simplify user setup or provide more advanced mechanisms. For that you can combine multiple approaches. You can use predefined item names, groups or tags (as most of marketplace stuff mentioned does) or build something combined.

Sky is the limit, so take your idea and bring it to community, let people judge. :slight_smile:

1 Like

Right on!!! :+1: :+1: :+1:

I’m confused by this statement because at least for rules and widgets that’s not how it works, or at least that is not how it is supposed to work. What is posted to the marketplace are templates with a set of defined properties. When one applies the template to create a rule, for example, the user must provide the values for each of the properties. Unless the developer posted a poor template, the Item names, groups, tags, thresholds, Thing and Channel IDs, etc. should be supplied by the user when filling in the properties. They are not predefined forcing the user to conform to the names chosen by the developer.

I’ve not reviewed all of the widgets and rule templates very closely but all the ones I’ve posted and the ones I have reviewed conform to this.

You’re right that with proper template you can point both source and target items. Yet I will use a very basic example which we can verify if its solvable with existing mechanisms.

Let say we have set of items with tag “Counter” which could be used to calculate hourly/daily increases. Items are not directly grouped since they belong to different categories (water, gas, heat) and group does not serve there any real purpose. Normal way which is promoted by openHAB is that you have a rule template which allows you to point source and target items, maybe a period for which calculation should be made. This means that for each pair of items you compute you need to declare a rule.
This works fine, yet you could do that for user. If you assume that if certain item naming pattern exists, ie. “$name_Present” (Counter), “$name_Daily”, “$name_Hourly” computation is performed automatically by extension. No need to create manually an rule for something which follows a predefined convention.

That use case can be solved with a rule that creates rules. I’ve done this in .py rules but I’ve not yet tried it in the UI so there may be an unforeseen gotcha there.

The way it works is as follows (at a high level):

  • there is a rule generator that pulls all the Items that are to be used as triggers using what ever criteria you have (name, tag, metadata, Group membership, etc.)
  • create a rule with the pulled list of Items as the triggers and the code that needs to be performed

However, there is one big limitation. There is no event when changing a tag or Item metadata or Group membership. Consequently there is no way to know when the rule needs to be regenerated. To get around that one can put the rule generator stuff into a rule and create an Item (the rule generator can create the Item too) that triggers the rule to be regenerated on command. Or simply manually run the rule generator in MainUI, at least until we can get event bus events for these types of changes, or new rule triggers (e.g. Item with Tag Temperature changes) that can handle the triggers for you in OH core. Given the hacky way the Member of triggers work though I’m not certain we can get there from here anytime soon.

It’s not something I’d expect nor recommend average users to be able to do on their own. They may as well just write the rule the way they want to in the first place. But it is reasonable for rule template developers to consider this approach in those cases where they need to handle something like this.

The way it would look from the user’s perspective:

  1. User installs the template.
  2. User creates the rule generator rule from the template.
  3. User adds the tags or what ever other criteria is desired (if not done already).
  4. User runs the generator rule which will create the rule that actually implements the behavior.
  5. Optionally the user can delete the rule generator, though they will need to rerun it if they change the criteria on any of the Items.

That’s how it would work right now. However, there are a number of discussions on Gihtub for how to best support helper libraries. Once that is straightened out we will be able to publish to the marketplace not just rule templates but rule libraries as well. When that happens we can “hide” the rule generator part in a library. So from the user’s perspective they would just have to install the add-on and the rule will appear, perhaps periodically refreshed to pick up changes made to Items behind the scenes.

EDIT: Note, it’s way easier if you don’t have to dynamically manage the rule triggers. In that case all you have to do is pull the Items from the registry based on the desired criteria (e…g Tag) and run the process on them. For example, sending an alert for low batteries in the morning using the Item tags.

Just to follow up, I’ve just posted to the marketplace a rule template that moves all the DateTime Items with a given tag (configured by the user) to today’s date. All the users need to do is install the template, instantiate the rule once with the tag of their choice and it handles the rest.

I can get away with that in this case because the rule doesn’t require the triggers to be dynamically created.

Just wanted to say, that I am very excited to try out the new marketplace, as soon as 3.2 is stable!

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.