New user observations and suggestions for growth and development

Organisation
1

Is it possible for me to make a suggestion here as a new user?

It seems to me that while the best part of openhab is it’s flexibility, everyone approaches their installation with a blank slate and seems to start from scratch. There are people who post their rules around and examples exist scattered about to cut and paste. As a system administrator and not a programmer it feels a lot like coding still.
I know OH2 plans include approachability for newer and more novice users. Here are some of my thoughts to achieve that:

What about finding a way to incorporate some of the better implementation rules into the addons release? The divided efforts could become collaborative and in the end everyone benefits.
Example: I was surprised to see thermostat functionality (which to me is likely to exist in almost all installs) actually missing from release. I thought for sure there would be some kind of binding or similar which gave nest/ecobee like functionality (or greater) right in the addons package.
Common and basic functionality built collaboratively and modularly. These could maybe called “rule modules”? If these rule modules were designed in such a way that they were driven by seperate configuration files then they could be easily upgraded with new releases without reconfiguration. These files could basically be a list of device aliases and yes/no questions on functionality desiredExample (I’ll keep referencing thermostat control for continuity): .cfg could contain number of zones, item identification for thermstat, if presense is desired, if temp should be in “real feel”, do you have dual stage heating, is there cooling, etc.
A repository exists for code branches but rules aren’t really built off a repository in the same way which is a shame. These could be uploaded to a repository right off the openhab website (or better in the web interface) where popular rule sets could be voted on. As a new user I might look at this to see what the top 10 rated/downloaded rule modules are to see if I could use them. an INI style file is a lot more approachable than coding rules and could be filled in by a form wizard in the web interface for even easier novice use.

Please don’t see this as begging or complaining. I’m not a programmer so I really can’t contribute by means of code, but I hope that maybe I can share some thoughts and ideas which someone with more skill could use to better the project if anyone found value in it. I understand every configuration is unique and making some rules generic is highly complex, but I think the value in approachability & new user appeal could pay off on common tasks.

2

Some of my comments below are philosophical in nature and may not directly address your question.

The tl;dr as it addresses your question:

  • this is a good idea and when the new OH 2 rules engine that supports reusable rules is ready for general use a library of reusable rules will be written and perhaps made a part of the base or as part of the demo or as its own thing

  • there is no mechanism to do this with the existing rules engine

  • even when this is made available, defining your home automation behavior will always be programming

  • I question the benefit of replacing whole cloth the smarts built into the devices themselves with OH rules instead of augmenting what is already there

To a large extent this is because it really is programming. Home automation is about defining behavior and no matter how hard one tries to hide it, defining that behavior will be either strictly limited to a very small set of possibilities or will require programming.

Kai is working on an experimental new Rules Engine that will allow for the writing and sharing of generic rules. Once this is ready for prime time a library of common reusable rules can be created (and I will push for this) that will become either part of the base install or part of the Demo (more likely), or as its own thing.

Bindings are used by OH to connect to a technology/API. Behavior is defined in rules. As such a Binding is not an appropriate way to deploy behaviors like a thermostat. In OH 1 there is no way to package and distribute behaviors (i.e. rules) beyond the demo, posting them to the wiki, and this forum.

But I would push back a little bit on your expectation to see Thermostat rules as part of every install. The vast majority of thermostats that OH will connect to are themselves smart with lots of built in algorithms and capabilities. These thermostats, which are the result of millions of $ of investment will have algorithms that far exceed anything that this community would be able to come up with in the near future. So it makes more sense to communicate with the thermostat over its API and set parameters (e.g. home verses away, turn on the fan, set the temperature) based on information that OH knows but the thermostat doesn’t (e.g. that you are coming home) but let the thermostat use its own internal algorithms to determine when and how to bring the house to temperature than it does to implement all of those in OH.

That isn’t to say that some sort of exemplar HVAC rules might not be useful and I would expect to see them in a rules library. Irrigation and Alarm systems are two others that should be included. I just wanted to point out that just because openHAB is a central hub it doesn’t mean that it should override and replace the smarts built into your devices.

We will have to wait and see how the new Rules Engine will work and support reusable rules to know whether this is possible and how it might be possible. But again, if you already have a smart thermostat, why not just use the built in smarts of the thermostat instead of trying to recreate that? On-the-other-hand, I see this being very applicable to irrigation.

This bring up the perennial balancing act when it comes to any user interface. You can have something that is flexible or you can have something that is easy to use. You can’t have both. Honestly, if you are willing to give up flexibility to have something easy to configure I would recommend one of the more commercial closed environments like HomeKit, Wink, Vera, or SmartThings. In an open source project like this, flexibility will always trump usability if that usability comes at the cost of flexibility.

Some steps in this direction can be taken though. OH 2 is the first big step towards at least hiding some of the icky programming aspects. But like I said above, it will always be programming.

Finally, many users, myself included, come to OH because some existing device does not do something I want it to. For example, I don’t have an air conditioner but I do have a forced air heater in the basement. In the summer, the basement is a good 10-15 degrees F cooler than the top floor so if the house is warmer than the target temp and outside it is warmer than the target temp I want to turn on the fan. So I integrated my Nest and wrote a simple 20 line rule to implement this. I let the Nest do the rest when it comes to controlling the house. I’ve augmented the behavior of the Nest, not replaced the entire smarts of it. I don’t want to replace the smarts of the Nest.

1 Like
3

Thank you for the well thought out and elaborate reply!
The rules engine you mentioned sounds exciting and I was not aware it was in development, thank you for sharing that information! I look forward to seeing what it could be.

[/quote][quote=“rlkoshak, post:2, topic:11812”]
I question the benefit of replacing whole cloth the smarts built into the devices themselves with OH rules instead of augmenting what is already there
[/quote]

I’m sorry if it came off that way. I wasn’t saying we should stop utilizing smart device API’s and their integrated algorithms, but I was saying that a very complex system could be developed with quite a bit of intelligence and utilize generic smart thermostats like the CT30 for example. I personally opted to not buy an ecobee/nest because I intended to program it around additional smart home items and wanted a self contained system within my control. Yes they have spent millions, but at the same point the foundation is not rocket science and likely fairly repeatable/reusable across many deployments.

I disagree with this statement. Openhab has as a community become significantly more cohesive and approachable with the new site/forum. The old groups turned me off completely because I didn’t get the strong sense of connection and user friendlyness of the community (not the people specifically, but the environment structured for group participation). I don’t think allowing and empowering users to more easily be connected and share their configurations or build off together right from within the openhab interface is anything short of enablement. It is providing a central avenue right in the application pages to extend the feeling of community and approachability to install.

If the rules engine goes live for example, a button similar to the addons in the PaperUI could be created that attaches right to the source. Looking there could give me ideas, encourage participation, and allow more collaborative efforts across common goals.

This can make things easier which in turn encourages participation and growth. OH2 is a great move in the right direction because yes it does hide a lot of the back end but that was also completely unnecessary. Ideally someday everything you would ever want to do with OH would be accessible from any pc utilizing ONLY the web interface after install is completed.

4

My statement is primarily referring to the technical challenges, not the community.

For example, to take your INI file example. In order to write some rules that can be configured by an INI file you have to hard code certain assumptions into the code. These hard coded assumptions become static and unchangeable and therefore reduce flexibility but by taking away that flexibility the product becomes simpler and easier to use.

Like I said, it is a balancing act. How much flexibility are we willing to give up to make the system easier to use?

I agree, though doing so from within the OH interface itself is probably a long way off.

Again, what I was referencing the technical aspect while you are talking about the community building aspect.

5

Forgive me if my ignorance of what goes into the programming portions and how that relates is glaring with my posts and vision here.

I think you are looking at things as absolutes and I am looking at them as conditional structured.

What if these common goals were installed and established just like picking your addons?
Let me paint the picture of how I imagine it might work.

You browse the rule engine modules and see a list. The name and version are displayed and when highlighted you see a short description as well as the ability to click install or view page for that particular rule engine module to learn more or see user reviews/comments (think something like the firefox extensions database, or a git). I don’t see this as a page hosted within openhab but just a link that opens to the frame.

A popular common module can be installed and a pre-requirements page can be filled out after install completion - or maybe just on the installed addons page you see installed, not installed, and a little gear for configuration related to that module.
when installed if there are required things you can force them to that config page which is just a ui wrapped to a config standard options selection page. You can edit the items on that page which write to an ini/cfg/etc. file associated. Doing it this way lends flexibility as the module is developed and allows for updates.
For the advanced user and additional flexibility You can also click an advanced button to directly edit this module as you would any other typical rule and it just wraps an html text editor around the module code on page. You could edit the module directly, or edit a stub out that is viewed as part of the module in fuction but exists in a second file (continuing to allow for update capabilities of the original module)

This is an additional overhead around writing universal rules for sure, but that doesn’t mean you can’t dig in the trenches it only means you might be able to achieve what you want without doing so. The bulk of the work for common tasks might be removed though.

This same repository and format would be EXCELLENT for addons of all types. I can imagine it would be very difficult to write and a lot to implement. Adding the button to the openhab sidebar is the easy part. It’s not entirely part of the openhab install but extends a continuity to the opehab “experience”.

I do understand there are many products in this space that provide a very easy and wizard type install but those have no flexibility and are cloud based or dependent on proprietary hardware/code. I’m not interested in those. Openhab is ultimate in flexibility at cost of implementation difficulty. I think there is still room here to have our cake and eat it too.

6

I agree with this and OH 2 is making great strides in that direction. Your scenario also makes sense for the most part. It does add unaccounted complications though. By making the rule configurable by a .ini file or whatever you have added complexity to the rule itself. This is all well and good for new users because they never look at the rule. However, for new and intermediate users who need the rule to do something slightly differently this sets up a new barrier to overcome as now the rule to be edited will be significantly more complex.

And lest you think this is unlikely to occur, almost everyone’s home automation is unique so more often than not the rules will need to be changed.

So we must be very careful not to lower the bar too low for the new comers at the cost of creating barriers to advance.

It will be interesting to see what sorts of generic and reusable rules people come up with to share once the new Rules Engine gets completed.

7

I think it’s more evolutionary in the same respect of OH2 and it will get there if we plan around it.
Before we had only text editing and manual file manipulation for everything. Now we can add bindings right from the menu, add/view/manipulate/change items in the same way, and do so pretty fast. Habmin has the graphical rule designer (and I underrstand habmin <> openhab)… none of these things take away from the flexibility and functionality of the installation but only aid in making things much easier and more approachable.
I’m more than capable of setting up my openhab install, but before a lot of these things I put off my install because there was a lot of overhead to the configuration and deployment which was just wasted time. I left lots of my z wave stuff in the box and waited patiently. Now things are completely different and still moving in the right direction. I like being able to breeze through the bulk of my new install with less clicks and complications. The less I have to do that to achieve what I want, the more likely I am to use it just because it’s home automation and all about making my life easier not harder.

I’m very happy starting on 2.0 vs the time I’ve spent playing with 1.x before.