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?
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
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
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.
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.
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
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
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
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.
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. 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.
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