Should I start with OpenHAB 3 now?

[tophee (Chris)]

Oh my! This is turning out to be a more difficult decision to make than I thought… But I’m happy you agree that it’s a relevant question and were able to provide equally relevant information.

I’m a bit torn between continuing this topic in a way that is useful for others (i.e. keeping questions it generic) and introducing parameters that are more specific to my own situation. So I guess I’ll do a bit of both.

Docker

How about docker? I’ve containerized (almost) all my stuff so for a moment I thought (hoped?) this might be the dealbreaker that makes the decision easier for me, but from what I can see, running OH3 M3 in a docker container is is just as easy as with OH2. Please add any caveats that my superficial judgement may have missed!

If dockerizing OH3 is not a problem (for beginners), then this may actually open up for a third solution: running both (each in their container, of course). I suppose it’snt a good idea to run both at the same time (though why not, actually, as long as I don’t set up rules for the same things - wrong terminology! Should probably be “items” - twice?), but I was thinking of switching between the two, so that my current OH2 installation becomes a kind of fallback option…

Rules

Several have mentioned rules as the locus of significant changes. Rules are important to me. I can do lots of automation without OpenHAB (e.g. with the built-in functionality of my Shelly devices), so rules is really a key reason to for using a system like OpenHAB.

One important principle I learned in OH2 is that I should use Visual Studio Code (VSC) to edit my rule files and I really like it (the code completion is just excellent and helps so much when you’re not yet familiar with the syntax). If I remember correctly, the reason for using VSC was that it’s both more robust and more flexible to go via the rule files rather than the web UI.

So, for me, a big part of continuing with OH2 would mean to familiarize myself with how to write rules. From what I read above, however, that may not be the smartest investment to make. I understand that the rules will continue to work, but with blockly being available in OH3, I don’t see the point in learning the old way. In fact: one of the things that originally troubled me with OH2 was that Blockly (or a similar visual rule engine) was not available. And if I need to code rules as text, I’d rather learn javascript, for obvious reasons. Doesn’t Blockly actually produce javascript so that the question of UI based configuration vs file-based config becomes somewhat obsolete?

Documentation (and technical skill)

Thanks for the pointers to the emerging documentation. It’s good to know where to turn to, even if it may be incomplete. I will have to take a closer look to tell how helpful it will potentially be for me.

Which leads me to the question of “technically skilled” vs “technically less skilled” users. Define “technically skilled”. I guess anyone who starts to use OH is already rather technically skilled. So, for me (no formal technical education or vocation), it’s more a question of how much of a bobby I want home automation to be. And for me it is clear that while home automation is fun, I don’t want to spend more time than necessary with it. And by necessary I mean: necessary to get stuff working exactly how I want them to work. So I’m willing to invest some time, but not for fun, just for good results.

So this is why documentation is important to me. If there is a ready-made solution that I can adopt, I’ll do exactly that. So it’s not only the official documentation but also forum content. It looks like with OH2 I have a good chance of finding copy & paste solutions whereas with OH3 I see myself posting questions to the forums rather than reading existing ones…

Bindings and setting things up

The other kind of task that I will be working on in OH is adding things (I think the terminology is correct here). Judging by the replies above, I will not encounter more (but probably less) problems doing that in OH3 than in in OH2., i.e. all bindings supported in OH2 are supported in OH3. Is that correct?

So? If each of my four headings pushes me either towards OH2 or OH3, where do I end up? (And don’t say: it depends where you start off, LOL)

[yfaway (YF)]

Rich, so the mew semantic model is replacing sitemap? Would it look good on an Android app? I like sitemap because it allows creation of UI that looks good vertically on a small screen. Does sitemap syntax get some more love in OH3? Thanks.

[rpwong (Russ)]

@tophee

I’m a bit torn between continuing this topic in a way that is useful for others (i.e. keeping questions it generic) and introducing parameters that are more specific to my own situation. So I guess I’ll do a bit of both.

I think your approach is a good one. I just thought it important to bring context for the benefit of truly new users who might come across this thread and think that it applies to them. Actually, I suppose that’s what I’m really trying to say: new users don’t know enough about OH to know which information applies to them (or not).

@rlkoshak

As a result, I fear that some users who are just getting started now will have a hard time moving to OH 3 later because the mental model that was built up of their configuration isn’t quite presented in the same way.

Yeah, I also have this concern, which I alluded to when I mentioned PaperUI. And again, I haven’t used OH3, so this statement definitely moves me in that direction.

@rlkoshak

That’s what Getting Started with OH3: rewriting the tutorial - 1. Introduction 2 is supposted to be. If you can contribute, even if by highlighting sections or passages that are not clear, please do so. They are wikis so you can edit them as well.

The thing about the wiki posts are that they present as work in progress, not as documentation that’s ready for prime time. I don’t think it’s an obvious starting point for a new user, but maybe I’m wrong about that.

Perhaps what we need at this time is a sticky post that condenses this and other discussions into the pros and cons of starting with OH2 or OH3, written for the brand-new openHAB user (and still valuable for people with prior OH experience)? I think it would probably lean people toward starting with OH3, and that’s fine if they know what the challenges will be going in. I’m less concerned about new users being confused and frustrated if we can get them pointed in the right direction right off the bat.

Really, this is just change management, which is hard enough when you actually have someone responsible for managing the change.

[rlkoshak (Rich Koshak)]

@tophee

running OH3 M3 in a docker container is is just as easy as with OH2

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.

@tophee

I suppose it’snt a good idea to run both at the same time

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.

@tophee

Doesn’t Blockly actually produce javascript so that the question of UI based configuration vs file-based config becomes somewhat obsolete?

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.

@tophee

I guess anyone who starts to use OH is already rather technically skilled.

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.

@tophee

So this is why documentation is important to me. If there is a ready-made solution that I can adopt, I’ll do exactly that. So it’s not only the official documentation but also forum content. It looks like with OH2 I have a good chance of finding copy & paste solutions whereas with OH3 I see myself posting questions to the forums rather than reading existing ones…

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.

@tophee

all bindings supported in OH2 are supported in OH3. Is that correct?

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.

@tophee

If each of my four headings pushes me either towards OH2 or OH3, where do I end up?

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.

@yfaway

Rich, so the mew semantic model is replacing sitemap?

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.

@yfaway

Would it look good on an Android app?

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.

@yfaway

Does sitemap syntax get some more love in OH3?

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

@rpwong

The thing about the wiki posts are that they present as work in progress, not as documentation that’s ready for prime time.

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.

@rpwong

Perhaps what we need at this time is a sticky post that condenses this and other discussions into the pros and cons of starting with OH2 or OH3, written for the brand-new openHAB user

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.

[rpwong (Russ)]

@rlkoshak

That’s because they are not. But that doesn’t mean they are worthless.

Just a quick clarification that I didn’t mean to suggest the docs-in-progress are worthless. I’m grateful to everyone who’s finding time to contribute and make this happen, so I don’t want to sound critical of anyone’s efforts.

[tophee (Chris)]

A quick reaction also from me (lots to think about otherwise, but that will have to wait until tomorrow (or rather: later today)

@rlkoshak

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.

Of course. I should have said: “finding copy, paste & adopt solutions”. Example: I wanted the bathroom lightswitch to turn on the hotwater circulation, but only before noon and not before 5. I found this (if I remember correctly):

@vzorglub

now.isAfter(now.withTimeAtStartOfDay.plusDays(1).minusHours(18)) && now.isBefore(now.withTimeAtStartOfDay.plusDays(1).minusHours(17).minusMinutes(30))

and turned it into this

rule "bathroom lights turn on VVC between 5 and noon"
when
  Item Shelly25_bathroom_light1 changed from OFF to ON
then
if(now.isBefore(now.withTimeAtStartOfDay.plusDays(1).minusHours(12)) && now.isAfter(now.withTimeAtStartOfDay.plusHours(5))){
  Shelly1_storage_VVC.sendCommand(ON)
}
end

I know the basic logic according to which it works but I don’t know if this is the best way of doing this or what other consequences this may have but it works and so I stop there. Hence “copy & paste” (plus X).

[rlkoshak (Rich Koshak)]

I see nothing wrong with that rule as written. It’ll have to change just a little bit in OH 3 though. now is probably the biggest change between the two that will hit people. In OH 2 it’s a Joda DateTime but in OH 3 it’s a ZonedDateTime and the methods are slightly different. It would be

if(now.isBefore(now.withHour(12).withMinute(0)) && now.isAfter(now.withHour(17).withMinute(0)))

NOTE: I’m going from memory, it might be of instead of with.

But in JSONDB rules you wouldn’t even need any code.

You can create the changed trigger with the from OFF to ON. Add a but only if conditional for “a certain time of day” and define the start and end time. And then use a send a command action.

The code view looks like

triggers:
  - id: "2"
    configuration:
      previousState: OFF
      state: ON
      itemName: aTestSwitch
    type: core.ItemStateChangeTrigger
conditions:
  - id: "1"
    configuration:
      startTime: 12:00
      endTime: 17:00
    type: core.TimeOfDayCondition
actions:
  - id: "3"
    configuration:
      itemName: aTestSwitch
      command: ON
    type: core.ItemCommandAction

Obviously you would use different Items. But for a simple rule like that you don’t even need to mess with Blockly level code. In my mind, this lowers the barrier to entry for “non-technical users” significantly.

[denominator (James Bowler)]

My view on this is it depends on the type of person you are.

If you are someone that has some time and can help with the OH3 documentation holes then 100% go with 3 as long as you can ask questions when you have problems. It is free to ask a question and the more effort and information the better the answer will be.

The new OH3 UI is very easy for someone with knowledge of openHAB workings to develop on. I think for a new user that is starting for scratch it will be the same amount of effort to learn the terminology and how it fits together.

@tophee

So this is why documentation is important to me.

So if you are someone who wants to help increase the OH3 documentation to make it easier for the next person. Document your problems from the beginning. What you or I can’t do is purge the information out of our brain to start again so we need intelligent people that are beginners to help.

There are many ways to contribute to openHAB and in my eyes every contribution has its caveat.

I can’t tell you how to contribute but know as a newbie like myself I do small chunks of changes and try and help people on the forums.

Within months you will be doing things like pulling apart a smart kettle to flash the MCU to free yourself from the cloud.

[Andrew_Pawelski]

I consider myself a strong openhab 2 user, and excited for 3 but if Im honest and I know its not ready for prime time but I just cant work out OH3 - ive looked at the wiki tutorials and they all make sense but to get a sensible page with icons that do something I have not been able to - all the examples seem to skip over the bits to make them functional and screnshots show amazing things but all mine are groups or items that show a big NULL on them.

Id love some more beginner guides - im across adding items and coming to terms with the new terminology and seantic stuff its the UX thats stumping me.

How is a newbie going to dive into this?

[rlkoshak (Rich Koshak)]

@Andrew_Pawelski

How is a newbie going to dive into this?

1. Continue to use sitemaps or HABPanel
2. If you’ve built your semantic model, a ui is built for you in the Overview page’s tabs. You can customize how the lists and cards on that page look by setting the default widget metadata.
3. Wait for new docs to be written. With the number if people contributing that might be a bit of a wait. We are all volunteers and there are not to many actually volunteering to help with the docs. Just yesterday I added about 20,000 words and a couple dozen screenshots.

[Andrew_Pawelski]

@rlkoshak

1. Continue to use sitemaps or HABPanel

Im guessing sitemaps could be imported from or be used from textual 2.5 versions?

@rlkoshak

2. If you’ve built your semantic model, a ui is built for you in the Overview page’s tabs. You can customize how the lists and cards on that page look by setting the default widget metadata.

This is where things start to unravel for me ive seen screenshots of just this - I dilligently followed the semantic tutorial - and that was really well written and easy to follow but i dont have a UI built for me as you say - I must have missed something?

@rlkoshak

3. Wait for new docs to be written. With the number if people contributing that might be a bit of a wait. We are all volunteers and there are not to many actually volunteering to help with the docs. Just yesterday I added about 20,000 words and a couple dozen screenshots.

Yes I must confess I am definately a taker not a giver in this regard and appreciate everything every volunteer does in the community and often pull myself back when I “expect” things to be different. I will keep looking and watching he official doco and the valuable work you do @rlkoshak to help raise knowledge with tutorials and your experiences.

[rlkoshak (Rich Koshak)]

@Andrew_Pawelski

m guessing sitemaps could be imported from or be used from textual 2.5 versions?

Absolutely.

@Andrew_Pawelski

This is where things start to unravel for me ive seen screenshots of just this - I dilligently followed the semantic tutorial - and that was really well written and easy to follow but i dont have a UI built for me as you say - I must have missed something?

Without more details I can’t begin to say what, but you must have missed something. When you configure your Items to put them into the model, the Locations, Equipment, and Properties tabs of the Overview page (the Page that is there by default) gets populated automatically from the model.

[sihui]

@tophee

I’m not finding the Amazon Alexa Smart Home Skill…

It is a skill, you need to install it on your amazon device.

[tophee (Chris)]

@sihui

It is a skill, you need to install it on your amazon device.

Oops, I meant to say “binding”, or whatever I need to install in order for the skill to be able to communicate with OpenHAB. But I guess I’m misunderstanding something…

So are you saying all I need is to connect my OH instance to myopenhab.org using the openhab cloud connector to establish that connection? (Plus add alexa metadata to relevant items, of course)

[sihui]

@tophee

or whatever I need to install in order for the skill to be able to communicate with OpenHAB

For that you need the skill, installed on your amazon device.

@tophee

Plus add alexa metadata to relevant items

For that you would need to install the Amazon Echo Control Binding.

I still don’t know what you want to achieve, please read the relevant sections in the docs:

openHAB Skill For Amazon Alexa

Amazon Echo Control - Bindings

[tophee (Chris)]

@sihui

For that you would need to install the Amazon Echo Control Binding.

I don’t have that binding installed but I can add alexa metadata.

@sihui

I still don’t know what you want to achieve

I want to send commands from Alexa to my openHAB instance .

@sihui

please read the relevant sections in the docs

I have read the page about the Alexa skill and am planning to submit some suggestions for improving that documentation, but before I can do that, I first need to understand things myself. From what I can tell now, the main reason why that documentation page is not helping me is that it doesn’t start with instructions and the headings are somewhat misleading:

The heading Setup suggests that what follows are instructions for how to set things up. But the first thing that follows is a lost of what has been improved in version 3 of the API. - Fair enough. I’m experienced enough to realize that this is irrelevant for me so I jump to the next paragraph: “Requirements”. Very good. It tells me what I need, so I make sure I have that. Check

And now I’m missing the most important section on the page: instructions explaining the overall setup. Before I can understand the recommendations, there is a lot I need to know.

I’ll blame myself for not immediately understanding that the only thing I need to install is the skill on my amazon device and the openHAB Cloud connector on my OH instance. But I’d suggest to clarify that. Also what exactly needs to be configured in the Cloud Connector addon (and where in OH3 I can find it once it’s installed). The documentation is very short. (I’m not complaining, just explaining why I’m asking questions.)

Anyway, that’s where I am now. Trying to figure out what else I need to know before I can make use of those “Recommendations”. I think one think that should be mentioned is about exposing Items in the cloud connector addon.

I don’t quite get it. My intuition tells me that whatever I select to expose here will be exposed to myopenhab.org (and hence Alexa) and everything else will not be exposed. But this is not what I’m seeing. I have not yet exposed anything (and the list of Items on myopenHAB.org is empty) but my Alexa device found one of my openHAB devices today. I know it’s an openHAB device because it has a strange label (“Control”), which is the default label it was assigned in my semantic model.

The reason why Alexa discovered the item seems to be that I added Alexa Metadata to it:

So I would imagine that the next step in the instructions would be to add such metadata to relevant items (and to create those items if they don’t exist yet).

I’ll stop here, but I hope the above might help to clarify the troubles of a new user, which, I know, are often difficult to anticipate for experienced users (who tend to be the ones writing the documentation…).

@sihui

please read the relevant sections in the docs:

I have read enough about the Echo Control binding to understand that I don’t need it as I don’t want to control the Alexa devices via openHAB but the other way around.

[sihui]

@tophee

But I’d suggest to clarify that. Also what exactly needs to be configured in the Cloud Connector addon (and where in OH3 I can find it once it’s installed).

Docs in openHAB3 are not ready yet, one reason is it is not released (still a milestone).

My intuition tells me that whatever I select to expose here will be exposed to myopenhab.org (and hence Alexa) and everything else will not be exposed.

You don’t need to expose any items to the cloud for Alexa to work. Due to server abuse this function is disabled anyway.

@tophee

The reason why Alexa discovered the item seems to be that I added Alexa Metadata to it

Correct.

@tophee

So I would imagine that the next step in the instructions would be to add such metadata to relevant items (and to create those items if they don’t exist yet).

Correct. But you won’t find those instructions in each and every binding section as this would be repeated then a couple of hundred times. You should find that in the general doc section.

@tophee

troubles of a new user

There are only a few users yet on openHAB3. I suggest to start reading the wiki posts:

Getting Started with OH3: rewriting the tutorial - 1. Introduction

This Wiki topic’s goal is to serve as a working document, in order to provide an up-to-date tutorial for OH3 aimed at new users and novices. Everyone is welcome and encouraged to edit it, when we’re satisfied it will make its way to the official docs. You may reply for the specific purpose of improving the article are allowed, but please, this is NOT a support thread: if you’re stuck while reading this and are simply seeking support please open another thread. Thanks! This tutorial has transit…

[tophee (Chris)]

I was trying to provide feedback on how the documentation can be improved. Neither the problems I’m encountering nor the solutions I suggested are specific to OH3.

@sihui

you won’t find those instructions in each and every binding section as this would be repeated then a couple of hundred times.

I believe that’s what hyperlinks are for.

[sihui]

@tophee

I believe that’s what hyperlinks are for.

Go ahead an fill in 424 hyperlinks :-)))