Writing jython scripts and accessing personal modules

Setup, Configuration and Use Beginners
,
15

There are a number of statements here that need clarification.

That is not what I said. You complained that it was challenging to deal with the problems that arise when using the mix of Java and Python in rules. Because OH is written in Java, the only way to avoid that is to write your rules in Java, or use some external rules engine that interacts with OH through the REST API.

I fully expect the two Java rule automation add-ons to remain relatively niche. But I suggested it because it solves one of the major problems you complained about.

But if one is looking for stable and always supported Rules DSL has always been there and as long as the upstream Xtend project is maintained it will always remain.

Did you see the announcement for the Marketplace? Rule Templates - openHAB Community

Rule templates have always been on the roadmap and now they are here. Note that you can write rule templates in any supported language. I personally recommend sticking with JavaScript or Rules DSL so that users don’t have to install extra stuff to use the rule template, but that’s just a recommendation.

In addition, the problem caused by the rules languages alone are not very useful and require some helper libraries to be installed is also being addressed but including the helper library in the add-on. So that means no more need to clone git repos and copying files around.

See https://www.openhab.org/docs/tutorial/model.html

This is a challenging problem that is highly hardware dependent. But see Generic Presence Detection which uses the Debounce [3.2.0;3.4.9] rule template which you can just install and use, no coding required.

OH 3 support any number of users which can be one of two different roles: user or admin. Furthermore, while not a security mechanism, widgets on the UI can be hidden from users based on their role which can do a little to approach access control.

See Scene Control Suite - Scene Activation, Scene Control Suite - Scene Modification, and Scene Control Suite - Scene Control Widget.

See Energy Meter and I’m sure more will follow.

I’m not sure what this means

See

And for UI widgets see

I won’t link to bindings but see the following UI widgets

Again I won’t link to the addons but Timeline would be useful for scheduling.

How is this different from lighting and appliance control?

openHAB is not and never will be a security system. However many people do implement security system features using openHAB.

It depends on what you mean but openHAB is a self hosted system that stores the persistence data locally. As the administrator of the data you necessarily have access to all the data stored on your system. openHAB has no control over privacy concerns for data collected by cloud services it might integrate with but you have the choice not to use those services.

See https://community.openhab.org/c/marketplace/ui-widgets/75

Note, everything I linked to above: the add-ons, the rule templates, and the UI widgets are all installable through MainUI and require no manual editing of any code to use. And I did not provide an exhaustive list.

My point is:

  • OH does already have the concept of standard bricks one can just plug together without code
  • there already is a library of such bricks
  • the library is only going to grow larger.

All of these are also customizable by users, especially the UI Widgets and the rule templates. Once added the user can modify the code to their heart’s content to meet their needs.

If they are happy with the simpler capabilities offered by commercial offerings like Alexa, HomeKit, SmartThings or Google then no they don’t. However, if they want to flexibility to do exactly what they want the way they want to then yes, they do. At some point customization becomes coding and you need to understand that stuff to code.

The amount of complexity that OH already hides from the user is huge! But as is often the case with these sorts of posts, OH doesn’t get credit for the stuff it already does for the user nor for the stuff that is in work to help the user. It only gets dinged because it’s not enough.

Rules DSL was the stable solution for OH 1.8. JSR223 was niche at best used by only a handful of users.

Rules DSL remained the stable solution for rules development in OH 2.x (all versions). JSR223 took some strides in development during this time but it remained “Experimental” the entire life of OH 2.x. And to use them it required the use of the Helper Libraries which never became a part of the openHAB project. They were and at least for Jython and Nashorn JavaScript a third party repo heroically maintained but still not a part of the openHAB project proper.

There were breaking changes to all the rules scripts in OH 3. But the breaking changes were relatively minor for Rules DSL which continues to remain the stable default language for rules development. If you want stable, Rules DSL is where it’s at.

All the rest of the languages are under active development. It’s unclear which, if any of them will become a default. GraalVM JavaScript is the most likely candidate because it’s actually a part of the OH project, work is ongoing to distribute the helper library with the add-on, the helper library is also a part of the OH project, and it will likely be the language that backs the Blockly implementation.

2 Likes