After far too long away from even checking in on my OH2 setup (it’s been mostly reliable), I set about trying to sort a few niggles, like upgrade my server OS from Jessie etc, migrate to an RPi4 I’ve have sitting waiting etc… and got quickly distracted by OH3.
Looks fabulous, the tutorials pulled me in and I installed OH3 on the RPi4 instead of migrating my OH2 setup…
First question - what’s the consensus/guidance on moving to OH3 from an existing OH2 setup - migrate or start over? (the second option doesn’t really appeal with over 270 items).
I guess, from what I’ve seen I want to make use of the model as much as I can for maintenance etc. (I’m of the Automation = “make things automatic” school of thought so UI’s for switching lights on/off isn’t a concern (looks fab though!)).
Most of my rules are written in the old DSL - presumably these will still work, but I understand it’s not the preferred option - what’s the default now, and are rules files still an option (“feels” easier than web based which never seems as easy)?
Same questions with .items files etc - I went with things through the UI for OH2 and items via files…
Great work, looks fab, looking forward to losing endless hours
This only you can answer for your setup. Note there’s a tool button in Main UI to import items which is what I did on my migration (900 items BTW).
There has never a “default” or “preferred” option (except when there was only rules DSL in the beginning. They’re absolutely fine to stick with, but again it’s anyone’s individual choice he/she must take.
It’s Christmas in lockdown times so thank you for releasing it just in time.
Note there’s a tool button in Main UI to import items which is what I did on my migration (900 items BTW).
So there is … is there a way to specify the Semantic classes in the .items file as it will be much quicker than point/click/point/click etc… The only reference I seem to be able to find in the docs is for icon which “Category”…
As someone who recently migrated I wanted to give you my (highly subjective, of course) take on things. My setup has a couple of rules files with a couple of rules each (60 rules maybe?) I’ve maintained all of my things in PaperUI and kept all of my ~120 items in an items file. Sounds pretty similar to your setup.
From my personal experience starting with a clean install is not that much of a hassle. I personally didn‘t want to carry over any legacy remains or anything that could possibly cause problems. Also, starting with a clean install sounds worse than it is. For me it was mainly installing & configuring the bindings, accepting the things form the inbox and tossing the configuration files in the appropriate folders.
Everything should pretty much carry over without problems. A much mentioned and notable exception is the difference in time APIs in the rules DSL. And of course you need to do a lot of “search and replace” in your items file(s) to account for the channel changes.
But apart from that, that was it for me. Your mileage may vary, of course!
Kinda where my head is right now - doesn’t look too bad and would help me clean out and tidy up a bunch of stuff which I’ve never gotten around to, and I’d hate to have that legacy hanging over into OH3.
1st, make certain that you have moved away from 1.X bindings. (I was running 1.x MQTT for example). The weather binding is not moving, so you will need to replace it with something as well.
After that, my upgrade from 2.5.x to 3.0 RC went very well. My biggest problem was the move from joda time to java time. Next problem was changes to "executeCommandLine. After that, things just worked. I have a LOT of items also and use ecobee binding on 3 thermostats, zigbee, zwave and mqtt.
Everybody has their own plan. I plan on moving from a native Linux installation of OH2 to a Docker installation of OH3.
I will set up the OH3 container to use different web ports an use the remoteopenhab binging to connect to OH2. This will let me set up Items with semantic models & UI in O3. It will also let me gradually migrate my rules over to OH3.
When satisfied I can cutover my Z-Wave controller to OH3 and relink my Items to complete the migration. This process allows testing & reverting to wa working configuration if needed.
In my case, I am not planning as elaborate of a phased transition as you are (but that’s only because I only have handful of simple non-critical rules). Rather in my case it’s just that I have finally come around to drinking the Docker kool-aid (in general).
So I am starting to migrate all of my services over to container based architecture.
Well, you give me some ideas, anyway. Maybe I end up following your lead after all.
I am not in a hurry though. System working fine as is. So I’ll just keep studying docs as they progress and forum posts and keep letting all the anxious folks charge ahead and iron out the wrinkles. I should thank those brave souls for their efforts BTW.
I am working a little on a project that would, among other things, be based on OH3. I feel the release & distribution could be simplified by standardizing on a docker installation instead of all the various distribution packaging schemes. If Microsoft had not broken device access in WSL2, it would work for Windows too. I have not yet explored the workarounds for that issue.
Your existing OH 2 setup should work almost as is with minimal changes.
But it doesn’t have to be an all or nothing. You can recreate your Things, import your Items, and elave your rules unchaged in .rules file, for example.
I don’t know if there is a consensus but I’m rebuilding from scratch (and I’ve an order of magnitude more Items than you do). I started by importing them from my .items files but stopped doing even that. It’s so easy to just add them from the model that I’m not recreating them all that way instead. It’s ending up being less work over all that way.
Yes with minor changes, such as you might need to change some of your lines that work with DateTime and now.
I don’t think there is a preferred option. As far as I’ve seen all rules approaches have seen the same level of effort and attention.
If you are basing this on PaperUI, you should at least give MainUI a trial run. A lot of things it makes really easy and the syntax is never wrong.
Yes of course. Rooms are Groups with one of the location tags. Equipment are Groups with one of the equipment tags. Points are Items with one of the Point tags and an optional property. Points are made a part of Equipment by adding them to the Group. Equipment and Points are made a part of a location by adding them to the Group.
But the point and click stuff is one of the big reasons why I have moved to recreating my Items through the model page instead of importing them. I’ll add a binding and discover the Things. Then I’ll go to the model, click on the location Group I want to put the Equipment and use “create equipment from Thing”. Then I can set the Equipment tag, select the Channels, change the names of the Items and tags that will be created if necessary and hit save and the new Items will be created all at once in the right spot in the model. I’ve found it to be faster to do that then to edit my .items files prior to import or to add the Items to the model after importing.
Another way you can do Items along the lines of the above, if you can run two instances of OH at the same time you can set up OH with the Remote openHAB add-on which will create Things out of your OH 2.5 instance’s Items. Then you can “create equipment from Thing” in the model page to duplicate your Items and place them in the model where they go at the same time. And then as you migrate your bindings over relink the Items to the “real” Things and away you go. I’m using this approach for Zwave/Zigbee so I can get my Rules rewritten and tested (I’m moving them to JavaScript through the UI) before I switch over the controller/coordinator.
That initially looked like a problem as I’m using a Veralite and it doesn’t look as though the binding is being migrated to OH3 - I’ll go with the OH2.5 remote for the time being as suggested by @Bruce_Osborne and @rlkoshak.
Pretty much mirrors my initial experience and approach I’ve now taken.
The more I’ve played with it, the more I’m liking it - getting used to tabbing between different browser windows instead of editor/browser and where to find things.
Out of interest, are you using the browser based UI to develop .js rules or still using an editor - if so any tips for keeping the process efficient? (personal preference I know…).
I understood the DSL rules were being moved away from, at least have limitations - hence am taking a similar path of migrating to .js - I spend sometime over summer looking at python, but it seemed suboptimal - the main UI looks good - I particularly like the ability to run a rule without having to trigger it somehow!
Having just been placed into the strictest lockdown in the UK, I’ve got more time than I anticipated…
I’m using the browser for Rules and VSCode or vim for libraries.
I don’t know much about efficient but this works for me.
If I have to figure out how to do something (e.g. call a new Action, call another rule, etc) I’ll create a new Script (right under Rules in the settings in MainUI) and experiment with that until I figure out how to do it. Once I do figure it out, I keep the Script for reference and transfer that to the Rule I’m working on. From there I’ll move the code to a library (see OH 3 Examples: Writing and using JavaScript Libraries in MainUI created Rules) or just copy and paste it into a new rule when I need to do that again.
When building a Rule I’ll do so in the browser. I’ll start building the logic little by little. Most of my rules are pretty short so this doesn’t take long. I have lots of logging and I run the rule manually with the play button frequently. If I can tell what’s going on from Item events, I’ll have the Event Stream open in the Developers Sidebar with filters so I only see the events I care about. In addition, I may have multitail up in a terminal following openhab.log.
There are some cases where I may need to trigger the rule with an Item (e.g. I need access to event.oldState). In that case, I’ll pin the Items I care about in the Developer’s Sidebar. If it’s not a read only Item, I will be able to command the Item from there.
For other Items, I may go and add a custom default card widget to the Item (that’s what gets displayed in the Developer Sidebar) so I can command it. Or if I just need something quickly and/or I don’t want to change the default widget for this, I’ll open the Scratchpad Script (created and easily accessible from the Developer Sidebar) in another tab and sendCommands or postUpdates from the scratchpad.
Sometimes I’ll be writing a rule that has to deal with a certain set of Items. In those cases I’ll pin all those Items to the Developer Sidebar so I can easily look at them to get names, current states, etc.
I think that’s it for my tips and tricks.
Note, if you install the Python add-on, you can use Python in MainUI Scripts. Any language you can write text based rules can be used in MainUI for Script Actions and Script Conditions.
… is there a way to specify the Semantic classes in the .items file as it will be much quicker than point/click/point/click etc… The only reference I seem to be able to find in the docs is for icon which “Category”…
