Yes, I run both in docker and it’s the same as it ever was.
Official images for OH 3 are available on dockerhub, though I find the snapshots tend to lag a bit at times.
As long as they are configured to use different ports and only one instance attaches to hardware like Zwave controllers at a time it runs just fine with both at the same time. Or you can stop one and start the other pretty easily. I have mine running on a separate VM but that was just because it was more convenient and I had a VM to host OH 3 on while I develop.
Yes and no.
First of all, you can write rules in JavaScript and Groovy now and Jython soon in addition to Rules DSL and Blockly. And indeed, Blockly does generate JavaScript.
But there are two ways to write rules. One is through text based files which is like the .rules files only with different syntax of course. There are helper libraries for those which make writing and editing easier. You can find lots of examples on the forum. All of these files get parsed when OH starts up or the files change and any rules they define get recreated. In MainUI they will be read only. You cannot change them.
The second way I often called JSONDB rules. These are rules that are stored in the JSONDB. That is where Blockly rules will be stored. Any language supported by text based rules are also supported as JSONDB rules. But these rules have differences. They are only created/updated through the REST API which means you’ll be creating them in MainUI for the most part. They tend to load faster I find (my OHI 3 reboot time right now is about 15 seconds). There are some bugs that only crop up with text based configs as well. These rules have a “but only if…” conditional clause that can let you avoid even running the rule unless certain conditions are met (I put error correcting code in there too). And these rules will be editable through the web based UI.
People were warned off of using rules this way with PaperUI because PaperUI is horribly broken. MainUI is working quite well though and getting better all the time.
NOTE: I don’t know if the Blockly implementation is complete so caveat emptor.
The old way of writing rules (Rules DSL or any of the other languages in 2.5) are still supported. But I’m finding writing rules through MainUI quite nice and productive. And I love how fast my boot times are. Though I’ve only moved about 20% of my config over so far.
So file based vs UI based is still applicable. You’ll have to choose. I will be recommending UI based to all from this point forward.
Not necessarily true at all. There are lots of people who jump in with little to no technical skills. I would define “technical skilled” as someone who does computer type stuff for a living or hobby. Software developers, systems administrators, and the like. These users already have a lot of skills and knowledge that is applicable to openHAB and home automation in general. Non-technical skilled would be someone who has never used a command prompt. Obviously it’s a spectrum with most people falling somewhere in the middle.
First thing to know is all those OH 2.5 examples still work! We are not starting over from scratch. There will likely be a couple of rules of thumb to watch out for but that’s it. Also I will say that “get stuff working exactly how I want” and cargo-cult programming (“finding copy & paste solutions”) tend to be mutually exclusive. If you want it to work exactly how you want, you need to know exactly how it works.
And with OH 3 we will start to see more and more ready made examples that you can just install and use. For example GitHub - rkoshak/openhab-rules-tools: Library functions, classes, and examples to reuse in the development of new Rules.. Eventually these will be installible just like add-ons.
All 2.x version bindings (those that support Things) are supported. Older 1.x version bindings are still supported in OH 2.5 but support is dropped in OH 3.
I can’t answer that for you. All I can say is were it me I’d use OH 3. But you are not me.
It’s not replacing the sitemap but, at least for me, the semantic model and the Pages in MainUI that get automatically generated from the model replaces the sitemap for me. I’ve no use for the sitemap now. Pages are less work, more flexible and the functionality is more complete than sitemaps so I don’t see myself going back to use them.
However, MainUI does have the ability to build a sitemap in the browser so you don’t have to continue to write .sitemap files by hand if you choose to continue to use them. And of course .sitemap files themselves are still supported.
I find it to look better but I never liked the look of BasicUI or ClassicUI in the first place. It was functional but not pretty. but as with sitemaps, the “cards” that make up the widgets presented by Pages get listed in one column. The only complaint would be that the information is a little more sparse than is presented in sitemaps, at least be default. You have much more ability to customize how everything appears in Pages though, even with the automatically generated Pages.
No, it continues to be supported but I don’t expect there to be any more additions or new features added to them going forward. It’s just too hard because any new feature or change requires changes to:
- ClassicUI
- BasciUI
- Android App
- iOS App
That’s because they are not. But that doesn’t mean they are worthless. And like code, docs need to be tested. And it’s sooooo much easier to involve the community in testing and contributing to the docs when they are wiki posts on this forum than it is when we have to force everyone to use Github to file issues and create pull requests.
If you want to wait for fully baked, complete, and excellent docs, you’ll be waiting for quite a long time indeed. I point you to the never completed, incorrect/inaccurate in some places, and only half done getting started tutorial for 2.5. IMO those wiki pages are already better than that.
I think focusing this on some random new user who happens along is mistaken. If they are not on this forum they will not necessarily even become aware of OH 3. OH 2.5 is going to be the only thing they find docs about. So we are talking about people who are at least reviewing this forum. And as such, I’ve posted the link to those getting started pages at least a dozen times just today. It’s posted in each and every one of the milestone release discussion threads. It may not be obvious just browsing around, randomly but if they read almost any OH 3 related thread they will find a link to them.
All I can really offer at this point is if no one else steps up and uses the docs as they exist right now in those wiki pages, and tell us where they are confusing or missing information, those wiki pages are going to get no better. Sure they might look “professional” once they get moved to Introduction | openHAB pages. But the content is going to be no better, and at the end of the day, it’s the content that matters most.
If history is any indication, OH 3.1 will be out before such a discussion reaches a conclusion, if it ever resolves to a conclusion. And it’ll be 200+posts long that no one will read.