I’m an openhab 1.8 holdout. I’ve been using it for five years and been very happy with OH. But I’m tired of hacking things back into 1.8, and wouldn’t mind ditching all the workarounds and having bug fixes and new features. I’ve decided it’s time to put 1.8 out to pasture.
The question I have now is… since I’ve waited so long to upgrade, OH 3 is on the horizon. Would it make sense to jump directly from 1.8 to 3? (Either now, or in 1 or 2 months?)
The reason I’m asking is because my rules (in the xtend rules engine) are pretty hefty. 1M of text rules, split into 610 rules. (Or at least those are the numbers according to grep… ) There is a lot of institutional knowledge coded in these rules. I know that I’m going to have to make tweaks and adjustments to go upgrade to OH2.
…but then I was reading that there’s going to be a next generation rules engine in OH3? This is the point where I get confused. I’m unclear if the rules engine means I’d need to re-write all my rules in yet another new language, or does it mean something else?
I’m not against rewriting all my rules in order to facilitate upgrading. Don’t get me wrong, I’m not looking forward to doing it either, but eggs, omelette, all that. It could be done marathon style over a looooong weekend, such as Thanksgiving coming up.
But what I DON’T want to do is rewrite six hundred rules, only to have to re-write six hundred rules again once OH3 comes out. Is that what I’m looking at if I upgrade from 1.8 -> 2.5, then from 2.5 -> 3.0?
I guess what I’m looking for opinions on my upgrade path. Should I upgrade to 2.5? Upgrade to 2.5 and rewrite all the rules in XYZ? Chuck everything and start over with 3.0 and rewrite all the rules in MNOP? What would you do if you were me, and why?
It’s funny, I’ve been using OH for five years but feel like I know absolutely nothing looking at OH3.
Duh. Given you have so much working code that you won’t want to recode, you won’t want to change the programming language so it won’t make a large difference if you go OH2 or 3. There’s a new rule engine yes but it’s rather another implementation to accept the same rules DSL input. You don’t have to change the rules code itself because of the engine
You will have to adapt rules though when moving OH1->2 as there are some differences in rules DSL. There’s some less differences when 2->3 (joda ‘time’ related code basically only). So I’d move to current OH2. It’s stable and you can start now. All of what you have to do for that you will have to do when you go directly OH3, and almost nothing of what you change in going 1->2 you’ll have to change again.
For 1->2, the major issue is to move to the thing concept, and to configure your things and - most of the work - items. There’s essentially no differences 2->3 here.
There’s GUI and text input means in 2+3 now and the 1 text item config will need to undergo major changes so it’s really worth considering moving to GUI provisioning. Then again FWIW, OH3 has a means to import OH2 text files in the GUI. OH2 has no such feature for OH1 items. So it’s probably a good idea to stay with text files only in 2 and to import them when you migrate to 3.
Make sure you read and the follow the 1->2 migration guide, there’s a link in the docs.
1->2 don’t aim for a big bang type of migration, rather take your time to migrate as much as you can in smaller parts while your new box is still offline.
Use smarthome:send commands to simulate events to test your rules.
In either case you will probably be better off basically all but startng over from scratch. it’ll be less work in the long run. Given that, skip OH 2 and go straight to OH 3.
If you want to bring your current config over with only minimal changes (still pretty significant) moving to OH 2 is your only option. none of your 1.x binding’s ate available on OH 3 and 2.x versions work fundamentally differently. You can’t move to OH 3 gradually.
Rules haven’t changed too terribly much, but I suspect you could apply some design patterns and new to OH 2 concepts like “Member of” rule triggers and the item registry to drop your rules lines of code by half or more.
Rules DSL, the language in . rules files is still supported. “Real” programming languages like Python and JavaScript and Groovy are also supported. The thing that executes the rules is different but the language is mostly the same (there are some differences added over the years.)
No, that’s not what you are looking at. First, OH 3 is coming out around Christmas so it’s not like you have to wait long for the official release. you can keep your rules in Rules DSL, make the changes necessary so they will work (see the migration tutorial). Then either consider rewriting in a different language or rewrting using Rules DSL but apply the Design patterns tutorials to make your rules more generic (and shorter). The advantage of the other languages is they support libraries. There might be some code it there already written you can just download and use.
Most of the work you are facing will be dealing with is the be concept of Things.
As for what I’m doing? I’m taking this opportunity to start over from scratch. Over got OH 3 running in n parallel and am moving everything over manually add if I were staying from scratch. This is helping me learn all the be stuff and resulting in a better config over all. And I’ve kept up with the latest and greatest all this time, often running the snapshots.
Duh? Duh what? What about my question or your answer should I intrinsically know? (And if that’s the case, why have a forum at all?)
OK that wasn’t clear from reading the “what’s hot about OH3”. I always thought of the rules engine as xtend vs jsr223. Guess that’s not the case, and if not then it’s kind of a moot question. (Seems like it’s an organizational internal change vs. a user facing change.)
I recognize all of the words, but I can’t make that mean anything to me. (I’m lost.)
That’s really my intrinsic sense, and really what’s been keeping me on oh1.8 for so long. It’s a failure of success, really; if I hadn’t had so much good stuff with 1.8 I wouldn’t have stuck with it so long!
Here’s a question… is the rules DSL on its way out? Is it a second class citizen? If so then since I’m going to be rewriting everything anyhow, might as well change languages since I’m no longer wed to the rules DSL. If it’s still a first class citizen then I need to balance pros and cons a bit more.
Ahhh, good to know! Obviously things might change, but if that time frame holds then there’s a good chunk of time I can block out then to re-write everything. (And in the meantime, transcribe all my existing rules into pseudocode to make the transition easier.)
I might wind up freezing and running OH1 during the day and switching over to OH3 at night for a while writing rules on the same box. Shouldn’t be too hard to pull off. (FLW!) Right now my WAF (and KAF) is extremely high, and I’d rather not burn that unnecessarily.
You run it off an sd card on pi and another backup one plugged into usb stick with a full backup. It runs on zram so it is important to never turn it off without shutting down correctly so I use a power brick as a UPS.
You can run the systems parallel to each other and move groups/sections of control over as you please.
I am toying around with OH3 not using it for any important control and I would suggest it is a good option for you to explore. Install it on a separate machine and see what bindings are missing from your list.
It was more of a comment like “oh dear, you have to embark on quite a journey” so never mind. OH2->3 is way less changes.
There’s no definitive answer because of the way OH development is organized. Some devs still use it, others prefer Python and yet others JavaScript. But for sure rules DSL is the most stable and safest choice for the time being.
You will have to fundamentally change your item definition files in order to use them as input files to OH2 so you can as well spend the time to insert everything in the GUI instead. For things (new in OH2) you will need to use that anyway.
Then again if you go GUI as Rich correctly notes it’s better to leapfrog to OH3 as the GUI is a lot better there. But mind you need replacement for your OH1 bindings.
You can move to 2.5 gradually though. The problem is none of your bindings that you are currently running are compatible with OH 3.
Probably not, but I suspect JavaScript to become the default language used in the getting started docs for OH 3 and therefore it will gradually become more of a dominant language. But there is a decade’s worth of examples and institutional knowledge with Rules DSL. That won’t be dropped lightly.
No, not second class, but now a peer with the other supported languages as opposed to the default.
The only reason I’d recommend moving is the number of rules that you have and the number of lines of code implies you have a lot of duplicated code. The other languages have more opportunities to avoid duplicated code than Rules DSL. But even if you stick with Rules DSL, there are ways that you should be able to reduce the lines of code count by half.
And don’t spend hours spinning your wheels. Ask for help when you need it.
) There is a lot of institutional knowledge coded in these rules. I know that I’m going to have to make tweaks and adjustments to go upgrade to OH2.