OH2: Which interface allows me to do what I could in OH1

I eventually got myself to install OH2 on a test Pi…

I will comment on the installation in a separate post later… however, I can say kudos to those who developed the scripted install; very nice, very impressive! It works!

So, I got to the state where I select the initial package, and got stuck.
I am uncertain where to go from here as existing OH user. Yes, I selected EXPERT… but…

The question is – and I may not have seen all the documentation… given that I have some OH1 experience, which interface or mode to I chose in order to work with the minimum interface set to manage all of the functions of OH2?

I wanted to ask this question, because – as a regular on the forum – I see all these posts: can’t do this here and can’t do this there; and need to do this in a config file, because the UI can’t do this yet, etc.
… it has confused me to the point, that I do not know where to go next in order to avoid those pitfalls.

Given that I want to ‘transfer’ my OH1 config to OH2 as easy and as straight forward as possible, and use either one ‘tool’ or method to do all the config of OH2, what should I do next to get there.

I am not even sure, whether OH2 is fully functional to the point that one tool can be used OR is that even the goal, and I need to use say 3 tools/methods to configure it?

Also, do I need a different Designer version? Or is config done differently now?

Any hints pointers appreciated.

[edit – for a central point of additional questions]

I have to add that I do use the odd binding, no wireless, all Ethernet and MQTT based sensors and actuators (based on the Arduino platform); no cloud, etc.

So is there – as part of OH2 – one tool to configure all OH2 functionality, if possible regardless of UI being used?

1 Like

Hi Max,

I still use mostly OH1 style file based configuration (items, rules, persistence, sitemap) using a recent designer download. For zwave related stuff (device config) I use habmin; things and cloud config I do maintain with paper UI. As UI I use basic UI. This combination works well for me.

with kind regards,
Patrik

1 Like

Usually you write and check your rules with the visual studio code add-on nowadays. Parsing of the item and thing files is more strict now so it failed for some people in the past when they migrated. Paperui can replace item and thing files, personally I prefer the UI but it depends if you still need OH1 bindings. KNX and MQTT are being worked on but right now they are only available as OH1 bindings.

Cheers,
David

Is VisualStudio a Microsoft product (cost or free)? Where is the add-on from? Is it for a specific language? E.g. C, Java?

You prefer the UI… which one? Paper UI?
“Depends on using OH1 bindings”. I use MQTT for almost anything. How does this fact change your statement WRT the UI being used?

OH1 bindings can not be managed by any OH2 UIs like PaperUI. You are stuck with text files in this case until the MQTT support is merged.

Visual Studio Code is from Microsoft and available for free. The add-on was developed in the community and can be installed within VS.

Cheers David

1 Like

I hope you have seen and are at least nominally following the Migration Tutorial.

minimal

This will have just core OH without anything else installed, including PaperUI.

Over time the UIs have grown more and more capable. But there is nothing that requires the UIs. The migration tutorial tries to present both the UI approach and text file based approach. Coming from OH 1 you will probably desire to stick to more text based and relegate PaperUI et al to experimentation and play until you learn a bit more how they work.

Follow the text based configurations sections of the Migration Tutorial. It walks you through getting your current OH 1.x working on OH 2.x core without using any OH 2 specific concepts or bindings (i.e. all text based configs, all 1.x version bindings, no changes to .items, minimal changes to .rules, no changes to persistence and sitemap). Then you can choose to migrate to the 2.x version of bindings you are using (or never migrate) at your leisure.

You can use all text based configs. You might need to use the karaf console for some debugging but that is unlikely.

Yes, you will need Eclipse SmartHome Designer 0.8 (look at the installation section of the Docs for links and instructions). It is essentially the same old Designer updated to work with new concepts and files added to OH 2. It is missing some functionality, mainly it is unable to recognize stuff defined outside of the text files (e.g. Items created in PaperUI) and it is missing recognition of non-core Actions.

There is a new Experimental Rules Engine but for your purposes coding is done exactly the same with a few very minor differences, the main one being you no longer need all those imports at the top of your rules.

Right now text based config file editing using Designer is your one tool to rule them all. PaperUI and Habmin are growing in capability with every release but sitemaps are still not supported.

You can use the Free VisualStudio and @kubawolanin wrote a plug-in for it that can syntax highlight OH config files. I don’t think it does as deep and thorough a job of syntax checking as Designer but it does include the ability to insert code snippets and I know he has included a lot of the Design Pattern examples as snippets.

You can read more about it here

2 Likes

Thank you kindly for your detailed explanation, I am sure will help others to decide going forward as well…

Documentation is a weird thing; it is either too much or not enough… and this also depends on whether someone is new to the thing, or has an idea about the previous version.
After diving into the documentation, it makes sense and becomes a lot clearer.

I literally went step-by-step through the openHabian install, and stopped after I got to the decision on which version to install. I picked the EXPERT; not that I am one, but for people migrating from OH! this seems to be it.

I reckon it takes a full day to read up on it all; follow links to the UI, what they do…
However, your post gives me the information I am after: either minimal (or expert), text-based config, Designer 0.8, and without getting fancy, this is all I need to work when wanting to migrate from OH!

I will continue reading and take notes of any problems encountered which may update the documentation or at least lead to questions.

On a side note: I installed OH2 on a new rPi3, simply to check out, whether I can go there – as in, rather than trying to figure out OH1 and potentially bug people with OH1 questions, and realising quite a few have gone to OH2, I’ll do the same and keep working with something that will have a life for a while than working with a superseded version.

Again, a big THANK YOU to those who seem to drive the development and as importantly, who wrote the documentation AND the openHABianPi script. The latter will most likely lead to one single way of installing OH (at least for most) thus decreasing the ‘support’ effort in the forum.

2 Likes

A few things to clarify :slight_smile:

  • It’s Visual Studio Code extension - not standard Visual Studio.
  • Syntax checking is on the roadmap - Pull Requests are welcome as soon as there’s a new version of Xtext in Eclipse SmartHome framework.
  • The extension has syntax highlighting, Basic UI preview, tree view for Items, quick go-to PaperUI link for items, dynamic rules creator and more. See this thread for more details.
  • It also allows you to quick copy item’s name and state, which is pretty convenient when you work on textual rules.
  • Some Rich’s design patterns are included there indeed. The list of all snippets is in this folder. I need to revisit it and add some more in the near future :slight_smile:

The project is still in heavy development, but I believe it has its momentum and is pretty stable for the end users :wink:

Cheers!

3 Likes