Confused on what kind of rules / rules engine I should be using

[rlkoshak (Rich Koshak)]

@TheCraiggers

I’ve also been a developer for decades.

What language(s)?

@TheCraiggers

Sitemaps were changing to pages (I think that’s correct?)

Not changing, sitemaps and MainUI (and HABPanel) live side-by-side. But MainUI is by far the most capable and most complete UI which is why it’s the default. It’s the only UI that serves as both an end user’s UI and an admin UI.

@TheCraiggers

rules and things and such were moving from individual text files to some new thing built in the web UI, etc.

Again, not so much as moving from as being given emphasis. Even in OH 2.x it was possible to define Items, Things and even Rules in the UI (the now defunct PaperUI). But it was awkward and not very user friendly to do so, so much so that even in the official docs it was recommended to only use PaperUI to discover Things and use text files for everything else. In OH 3, with MainUI’s introduction, that advice changed to emphasize UI to create and manage everything supported. But the text based ways are still supported and available.

@TheCraiggers

And yesterday, I’m trying to build a state machine to control my HVAC system better than slew of cron-based individual rules that have accumulated over the years into a hairy mess.

Are you aware of rule templates? I have published a time based state machine for solving use cases like these. Time Based State Machine [3.2.0;3.4.9]. Rule templates can be installed and a rule or rules instantiated from them. So all you’d have to do is configure the rule and Items as necessary. In this case, you’ll create a set of DateTimeItems with static datetimes or datetimes from some other source (e.g. Astro, iCal, etc.) and the rule will command a TimeOfDay Item with a String representing the current time of day state. You can use that String to drive the rest of your rules.

@TheCraiggers

So I search, and I see Rich say I should really be using vscode and an extension to write my rules. Sweet, I already have Code, so I install the extension and hook it up. But I only get my Things and Items… even mounting /etc under NFS to my desktop doesn’t help.

That’s probably a really old post. But the advice is still true if and only if you are writing your configs as text files and not managed (i.e. in the UI). And even then the code checking only supports Rules DSL so if you are using some other language, VS Code doesn’t buy you much.

@TheCraiggers

After further reading and digging, I guess all the rules I’ve written over the years are basically useless because not only are they stored in some json file somewhere, but they’re a whole different language that’s only used in the web UI, which feels like a dead end to me since it doesn’t look like anybody is using them.

This isn’t correct. More and more is moving towards managed configs (i.e. that stuff in the JSONDB) as the emphasized approach. But, like I said, you wouldn’t be using VSCode for managed rules anyway.

If you do want to use VSCode, then you need to stick to text based rules and not defining rules through the UI.

As for the formatting and language, it depends a lot on what you’ve done. A UI defined rule is defined and serialized as a JSON string. This “object” consists of zero or more triggers, zero or more conditions, and zero or more actions. There is an option to write conditions or actions as a Script. The Script can be written in any programming language you have the add-on installed to support (in OH 3.4 you get Rules DSL, Nashorn JavaScript, and Blockly by default; in OH 4 you only get Rules DSL by default and must install an add-on to get the other languages).

When writing a rule in a text file, the whole shebang is written in the language chosen.

But I can say that the vast majority of users these days are using UI rules over text based rules, if the activity on the forum are any indication.

@TheCraiggers

So, I’m slightly aggravated because I thought I was future-proofing myself back when I decided to do things the “new” way.

Both ways will continue to be supported for the foreseeable future. Though even on OH 2.x some things were not supported in text based configs (e.g. you can configure device parameters for Zwave devices when using .things files) and support for file based configs for new stuff may not materialize (e.g. custom UI widgets for MainUI) or may not make any sense as text files (e.g. Blockly).

So either way, managed or file based, you are future proof.

@TheCraiggers

and the impending release of OH4 which possibly has its own changes to the above

Not really. Mostly just Nashorn JS has moved to an add-on instead of being there by default and Blockly now requires the GraalVM JS Scripting add-on and “compiles” to a more modern JavaScript than Nashorn JS. Rules wise, everything is pretty much the same, with some new stuff added but full support for all the old stuff remaining.

@TheCraiggers

If the built-in rule language isn’t standard / the best, what is?

The “DSL” in Rules DSL stands for Domain Specific Language. It’s largely based on XTend (a relatively obscure language) with lots of customizations for openHAB. For a long time I’ve advocated users who are programmers to not use Rules DSL. Since the release of OH 3.0 I’ve advocated new users who are not programmers to use Blockly instead of Rules DSL.

Over time fewer users will continue to use Rules DSL as their rules language of choice. And it might be the case that something happens upstream in XTend which may make OH’s continued support untenable, but that’s true for all the OH languages.

I wouldn’t start with the Jython add-on today. It’s stuck on Python 2.7, upstream shows no indication that Python 3.x support is coming anytime soon (and even if it did I’m not sure there is anyone left on the OH side to adopt it). If Python’s your thing, look into HABApp.

Beyond that, choose what ever language is closes to what you know. Decide if you want to stick to file based or managed rules (I’ve moved to managed because it has some advantages, not the least of which is rule templates can only be written as managed rules). I think the Java and maybe Groovy add-ons do not support UI rules (I really know very little about Groovy so could be wrong on that).

The two most mature languages with good built in helper libraries (abstract the Java which openHAB uses to native language Classes, Objects, and ways the language work) are GraalVM JavaScript and jRuby.

You don’t have to choose just one. All of these add-ons can live side-by-side and you can write rules in all of them at the same time. So you can experiment to see what works best for you.

Speaking from a personal perspective, to get a data point of one, I started with Rules DSL in OH 1.5. In OH 2.3 (IIRC) I moved everything to Jython in text files. In OH 3.0 I moved everything first to Nashorn JS managed rules. I can’t remember when but I was able to influence the direction of the GraalVM JS Scripting to make it better support managed rules. Because of support for modern ECMAScript and a good helper library greatly improved the overall coding experience, I moved once again to that.

A lot of people are very happy with jRuby as well which was a little behind on the managed rules support but has since caught up.

And a lot of work has gone into Blockly to make it feature complete with all the other languages so the less technical users do not have to give up on language features and capabilities for the easier to use coding environment.

tl;dr: Pick what ever supported language floats your boat. Decide if you are happier using VSCode (text file based) or MainUI (managed) to write your rules. Experiment a bit. Nothing currently supported in OH 3 is planned on going away in the foreseeable future. The only risky one I see is Jython.