I’m a semi experienced user of OH2.5, now migrating to OH3 which looks super exciting.
I’m not coming from a software development background, but I have no problem learning new coding languages. With OH2.5 I mainly used Rules DSL and got very comfortable with it.
Now during my learning process of OH3 I got aware of some other scripting and automation options I didn’t use or that were not available before (e.g. JSR223, JavaScript, Jython, etc.)
As I wish to become more advanced user, which of these tools is a better path to go?
And most important, is there a roadmap for the support for these languages? Specifically, will my many ‘.rules’ files written in Rules DSL will always work (other than some syntax changes of course)?
As I said, I’m not experienced developer and I don’t mind learning new stuff. On the other hand i would prefer to invest my time in a more future proof path.
If there are docs with guidence on the subject, I’d be happy to get a link, might have missed it.
There are no specific docs with guidance on this particular topic mostly because there are too many different use cases (more or less one-to-one mapping with number of OH users). If you spend a little time poking around with different search keywords, you’ll find a wealth of information on this subject here in this forum, it’s just not organized into a single doc. Here’s an example that gives you a great idea of the pluses and minuses of javascript versus rules DSL:
You might even want to look outside of the core OH3. Many users who want to get the fullest python integration with OH3 are using HABapp which you can find lots of information about here on the forum. You’ll also find on these forums many users who have connected OH up to Node-RED.
In my opinion the answer to this question is “why choose?”. They are all useful tools in different situations. Many of my rules are now written in javascript. I have a few still in python that I’m in no immediate hurry to convert over because they work and I’m not as familiar some of the javascript libraries. I even have some that just use the built-in blocky because the rule logic was simple enough and I was using my phone at the time I was setting them up. I make sure I tag each rule with the language used so that in my rules page I can tell at a glance what’s going on.
Over time, I imagine all my rules will converge on javascript. When the need arises, the blocky-based rules slowly get converted to javascript so that I can add features and complexity. As I learn more javascript and more of the ins and outs of OH3, I discover improved ways of doing certain things that causes me to convert a python rule over (more because I’ve started to build out my library of personal javascript utilies than because javascript is a general better solution than python).
There’s certainly an argument to be made for consistency instead of my scattered approach, but even then there’s no hurry for you. I’d recommend you first worry about getting your migration to OH3 squared away without adding to it the complication of converting all your rules.
As rules DSL does work with OH3 and I’ve not heard of any push to remove it in the near or even long-term, you have the freedom to take your time and test each of the options and see which one (or more) fits best for you. As you have stated your goal is more advanced work, it probably won’t be rules DSL just because most of the other options (as you can see from the example in the post linked above) give you access to more high-level features such as metadata manipulation.
I went through a lot of posts, that one I missed. Thank you for that.
In my very humble opinion, a guide with a collection of insights about the different tools and approaches is missing in the docs. The getting started tutorial is great and exactly what one needs when taking the first steps with OH. But for the more experienced users (and not yet experts) it’s not enogh. Again it’s just my view, while appreciate all the effort put in creating those docs.
I get your approach of slowly evolving my setup, and I have to say that this was what I started to do- first moved all my rules files, and started experimenting with the UI based rules.
My main concern was the future of rules DSL, glad to hear it’s not going away any time soon. It does relieve the pressure to migrate the rules to a new language.
@Chentadot if you are interested in moving to Python or JavaScript then you might be interested in the Helper Libraries.
@JustinG you might be interested in my work to migrate the JS libs to OH3 and match functionality with Python. It’s not complete but it’s mostly working.
That’s tricky, because the advantages and disadvantages are subjective. Also, some of the available methods aren’t officially supported, so those would be left out of the docs. There are just a lot of options being championed by different people, and I agree it can be overwhelming.
Personally, I’m sticking with DSL. I’m also not much of a programmer, so I don’t have any complex rules that would be significantly faster in another language. I mostly just use if/case staments to check conditions and execute tasks, and DSL is fine for that much.
I’ve thought about moving to UI rules, but I like being able to easily copy/paste/edit rules and add comments to remind myself of why I’ve done things a certain way. I might move some of the simpler ones to the UI just so that I can gain a better understanding of it.
I’ve been watching the discussion of your helper libraries with great interest. Right now my rules are stable enough that they are not my primary concern, but when the cycle comes back around and it’s time for my rules to catch up with the growth of the rest of the system, I will definitely take a much closer look.
Thank you for the suggestion. Since taking the sow road of evolving my setup, and after prioritizing my to do list, I’m putting the development of my rules a side at the moment.
But I went through your post and it seems a very interesting work.
Thanks!
