User enhancements

Development
1

Can we please have a discussion about the future of OpenHAB with out it degrading to throwing food, spitting and biting.

For reference, I’ve recently written a couple example rules to contribute to the tutorial section of the forum. I’m new to writing rules, the community has been great in helping me and several times I’ve heard folks say we needed simple rules examples so it was a way to contribute. In the first rule example thread I compared two times. The second example involved a step making a decision based on the day of the week.

There is a lot of talk about changing this or that but if the goal is truly to attract more ‘non technical’ type users, asking people to convert joda time types to rules dsl time types to discern if two event occurred before or after one another is, well… kind of asking a lot. I read a thread recently where someone was saying the whole astro binding should be built in because whether it is daylight or not is such a basic home automation task. I’m starting to agree. Shouldn’t what day of the week it is be… I’m almost scared to type the word for fear of attracting trolls… but… easier?

I understand the rules dsl may soon go away. I see a graphical rules writing interface similar to ITTT (which I’ve used a little) or node-red (which I’ve seen but haven’t gotten to try) as being the obvious goal if non programmers are the audience. I am not ignorant to the fact that creating such a thing is no small task. I know nothing about JSR223 but what I wonder is could rules dsl or JSR223 be enhanced similar to what jquery did for javascript? Not a direct example of what I talking about but more of a make easy things really easy and make hard things much easier. Rules dsl means domain specific language right, like specific to OpenHAB right? Seems to me, if the application is going to have it’s own language anyhow…

Anyhow, just some thoughts… again please… try to have a productive discussion with only suggestions that include (hypothetical) solutions and no name calling or flame throwers

2 Likes
2

I agree, I have been using Openhab since Christmas. I am confident with computing and gadgets etc but know very little about coding, having done nothing with code for many years. I have got to grips with Openhab, but then I have the time to learn and understand. Not to mention the stubbenness to not be beaten by a bit of software. There have been plenty of times when I have wondered why I am doing this. Most people would have given up, as most stuff can be done easily in other ways. E.G google home assistant, IFTTT or tasker. If you want to attract more users you need to be able to easily set up the basics. I would have liked a lot more samlpes for things like rules and sitemaps. Even with being able to set up things in paper ui, I have found I still need to add these things to sitemaps and items files to make stuff work how I want it to work. Saying all this I have managed to create a system with 13 lights, 4 switches, 2 chromecasts, 4 google assistants, 1 enigma2 satalite box. I still have 3 ip cameras and a broadlink mini to add and will get these done soon

3 Likes
3

Probably not.

Everyone has opinions and some are passionate. And everyone seems to fit with a spectrum with “everything is horrible, throw it out and start over” on one side and “don’t you dare change a thing” on the other side. And the closer a user’s opinion is to one side or the other, the more vocal they are.

There actually was a PR almost a year ago now I think that had to be rolled back. It was an attempt to remove Joda and it was going to make some of this stuff easier. It broke just about everyone’s Rules. So the benefits of any change like this is going to have to be weighed against the degree of changes that get imposed on the thousands of users who will be impacted by the change.

Have you reviewed some of the work that David is doing in the PaperUI NG Design Study? It includes a whole new approach to scheduling and such which can address some of this.

A goal is to attract more ‘non technical’ type users. This is not THE goal. It is one goal competing among many goals. A balance needs to made between power, flexibility, complexity, and support for advanced users and the needs for simplicity, fewer options and choices, and less to learn for the non-technical users. If we move too far in one direction or the other then OH over all suffers.

As long as OH remains as powerful and flexible as it is, non-technical users will complain that there is too much to do and learn. I don’t see how we get away from that without removing options and reducing that power. There is a reason why commercial HA hubs typically support < 10 technologies/APIs. As long as we try to make things easier for non-technical users the “power users” will complain that we are breaking their carefully crafted development process.

Also, JSR223 already doesn’t use Joda I believe. And there are extensive libraries for making this sort of thing easier for the JSR223 Rules. Furthermore, the UI driven Rules will have a “Script Action” which will be JSR223 written code as well.

Perhaps @5iver can provide some more details if it is desired.

DSL does mean Domain Specific Language, and that is actually a problem. When Rules DSL becomes deprecated or becomes not the default (it will not just disappear) it will be replaced with a regular purpose language(s), not a DSL. In short, the future is OH is not going to have it’s own language. It will support writing Rules in general purpose languages with an extensive OH specific library to make writing of Rules easier. The Jython library is already very impressive in how few lines of code it necessary to create a Rule.

Anyway, with discussions like this there is one very important thing that has to be remembered and taken into consideration.

Nothing in OH gets built without someone volunteering to do the work to make it happen. We can have all sorts of discussions about stuff like this but unless and until an issue is filed and a developer volunteers to do the work it will never happen. And even then, the maintainers will have to balance a proposed change like this against the disruption that will occur to the user base as a result.

1 Like
4

very well said Rich and understood

I know zip about JSR223 but it may be a good option, Is time learning to write rules in dsl wasted time? Should I go check JSR223 out? My understanding it I can use javascript, groovy or one other as well? I already know some js

5

Not at all. One of the not very well held secrets is once you know how to program in one language, you can quickly come up to speed in pretty much any language. The overall concepts are the same. If human languages were the same, you could learn to speak French by learning a dozen new words and a handful of grammar Rules. Most programming languages are very similar in structure and how they are used.

With the JSR223 libraries, you can even build Rules that look a lot like Rules DSL Rules.

Yes. It is very much worth looking into it.

Python is the third. The libraries for Python are a little more mature than for JS and it does let you write Rules that look more like Rules DSL Rules. But the JS library is pretty complete and works well as well.

I believe that we (Scott and myself) will be pushing to make Python the “default”, but all three will be supported as first class citizens.

2 Likes
6

ok, I like that to

wouldn’t that be cool, I wish
I started in qbasic in the 90s, AutoLisp (architect by trade) VB, VBA in the 00s web stuff, C#, taught myself PHP and wrote a mySQL powered 100% dynamically generated web sites, BASH for commission mail servers, CentoOS, Fedora was my playground, learning Deb for openHAB, rusty been a few years

7

OK, so maybe Lisp doesn’t translate so well. I love functional languages but they are different enough that they break my simile.

2 Likes
8

umm… AutoLisp was a sub langauge of Lisp create to run inside AutoCAD (AutoDesk product - vector drawing) It is paretheses delimited and nestable, super low level but the drawing database was a list of lists and lisp (list processing) work superbly for the task. It was uber hard to learn but stupid powerful and fast. A lot of the application’s native commands are themselves still written in it

9

That’s Lisp and it’s derivatives in a nutshell.

I’d totally write Rules in Clojure or Scheme or the like if it ever becomes supported. I’d never push for it, but would totally use it.

10

those comics are a riot… we used to have contest for best one liners and stuff it was fun

Clojure or Scheme?? you lost me off to google

11

this particular variation had no error handling (is that the norm?) in 2K MS pushed AutoDesk to implement VBA, is smelled really nasty and worked less well then it smelled. Ten years later, MS changed up there mind. AD had invested… firms had invested… much gnashing and grinding of teeth ensued.
but yeah, I liked lisp, car cadr cardrr ()())(((()))) counting parentheses until you went mad, I couldn’t write a line if you held a gun to my head anymore but remember I liked it

12

Previously, all automation in OH was scripted using the rules DSL. There is now a new rule engine, where there are more options, including using the REST API, which can be used by a UI to generate rules. This is an abstracted way of building JSON resource bundles, which are ugly and complicated and nobody will want to write them by hand. So how to do scripting? JSR223 to the rescue. Pick a supported language, Jython, Javascript and Groovy are popular, and you can write scripts. There are also language specific helper libraries that remove much of the complexity of interacting directly with the Automation API, just as the DSL did for the old rule engine. These helper libraries are providing functionality that will be absorbed into OH by migrating them into a new scripting API and ModuleTypes, so that all JSR223 languages have access to them.

JSR223 allows you to write scripts that create rules, or it can be used inside rules, but it can do MUCH more. In the new rule engine, there are Modules (Triggers, Conditions and Actions), which are further broken down into ModuleTypes. I am wrapping up ModuleTypes that will allow a script made with any JSR223 language to be used in a Condition or Action. I am also working on bundles to ease the installation of Jython, Groovy, and the helper libraries. After those, I plan to address the scripting API and creating more ModuleTypes (aka, more options in the dropdowns when building a rule in Paper UI).

Layers of abstraction… these are being built so that you can drag/drop, point/click, etc. your rules in a graphical interface, or so that you can do complex things in a script with simple commands. The rules DSL provided abstraction for the old rule engine. For the new rule engine, there are ModuleTypes (mostly for use in the graphical interface), a scripting API, ScriptExtensions, and language specific helper libraries for areas where the API has not yet been built out.

The Jython/Python libraries are a LOT more capable. We will need JDK9 support, which includes ECMAScript 6, in order to built out the same functionality into the Javascript libraries. If the other maintainers agree on it, I plan to rename the https://github.com/OH-Jython-Scripters organization to OH Scripters, and include repos for all of the languages, so that there is a single place to go for helper libraries, scripts, examples, rule templates, etc.

13

Lisp is programming distilled to its most rarefied minimal set of features. Errors are just a special case of a condition.

This post is 90% of the way to a “Getting started with JSR223”. It’d make a grate tutorial. :wink: Then we can link back to it every time this topic comes up. I’m actually wanting to start pushing JSR223 a little harder than I have over this year so we have a little more of a user base by the time OH3 comes out.

Maybe wait until your WIPs get done?

If you need a :+ I’ll add it to the issue.

14

this will be a boon for noobs and OpenHAB’s more broad adoption

sometimes folks like us are to buried in our own OpenHAB journey to forget about folks like you who are blazing the trail out a hundred miles ahead of us… thanks… sounds exciting I’ll be checking this out tonite when reading time is greater

15

very well put Rich

I agree, excellent explanation Scott, thanks and pity if it was lost in this silly thread.

16

Not OH maintainers… OH Jython Scripter maintainers :slight_smile:

Yes… best after the 2.5 M2 build. I’m not sure if the Jython bundle will be ready by then, but :crossed_fingers:. There is a lot more in my head and on paper, but small bites…

Once I’m past the current bottle neck, I’ll work on a flood of communications/documentation.

2 Likes
17

Just point me in the right direction and I’ll :+1 where ever it can do some good. :slight_smile:

18

Hopefully those posts here doesn’t get lost. They would be wonderful introductions for openhab.org/docs.

19

Actually, you could help me bug @lewie about Migrate repo to OH-Jython-Scripters? · Issue #4 · lewie/openhab2-javascript · GitHub :blush:.

20

Done

1 Like