But in the other thread there were also considerations if the OH1-core which runs inside OH2 isn’t loaded it might have not much impact. And that OH3 and and a newer powerful pi might be ready at the same time.
I think this should be mentioned, too. The thread mentioned is this one.
If this is tested on a Pi and confirmed, fine… Up to now, this is unclear!
Thanks 
No no no. This is not how it would work. I want to make sure it is really clear how this would work. It’s important to understand this to properly understand what is proposed.
All your Rules, Persistence, Things, UIs, and everything else will live on the OH 3 instance. The ONLY thing that will live on the OH 2 instance are the OH 1.x bindings and the Items bound to them. Those Items will also be represented in the OH 3 instance somehow through the federation.
There is one place to develop Rules. There is one place to develop your UIs/sitemaps. The only thing that will exist in the OH 2 instance is the OH 1.x bindings, the compatibility layer and the federation of the event bus. That federation means that any updates/commands that come from OH 2 get reflected in the same Items in OH 3, and back.
The work/energy used by OH 2 is not duplicated. It is work that your current system has to do already anyway. There is just more RAM required because there will be some overhead in running two separate instances of OH. But it isn’t double the RAM either, because OH 3 will no longer be hosting almost a complete copy of OH 1.x inside it. We won’t know until OH 3 is built how well the two will live side be side on the same RPi. It may work great or it may not. It will largely depend on your specific configuration I suspect. But some users will have to prepare to have to run to RPis to retain support for OH 1.x bindings under OH 3 I suspect. Would you rather not have the ability to run OH 1.x bindings at all?
The work you have to do is only slightly increased as well. You will need to set up the federation and you will have to places to go to to configure bindings. But that is far from doubling your manual work.
With the MQTT 1.x binding, this sort of set is already possible. The MQTT 2 binding doesn’t have direct support for a setup like this, but it is possible to set it up this way. What is being proposed is to make this sort of federated OH configuration part of the core instead of part of the MQTT 1 binding or accomplished through the MQTT 2 binding and Rules.
6 Likes
@rlkoshak Thanks for the explanation. Maybe I was a bit unclear, but that concern you cited referred to the idea of employing two Raspberries for the two OH instances…
Doubling the maintenance - no. Maintenance overhead - yes. But ok, valid point, sort of.
But double energy cost? Come on! Throw your smarthomethings out of the windows very fast and don’t buy any of this stuff if you argue about 8 Euro energycost per year.
Agreed. Still ugly 
2 Likes
The picture is already very close to what I have in my mind. But to be honest: I had a real OH1 instance in mind, not OH2, for OH1 bindings. Mainly to not have all the adapters running and also no discovery and all the other OH2 goodies.
The easiest way is indeed with separate OH1 item files. The item file format for OH3 might change and then we would need to backport that to OH1.
2 Likes
I would actually prefer that approach. I just assumed that you wouldn’t want to make the necessary changes to the 1.x core to support the federation bus. It’s your proposal so I assumed you’d be leading the implementation effort. 
Hm. Actually I planned to make it as easy as possible and just use MQTT. OH1.x already has the MQTT eventbus binding. For OH2/3 there is only an equivalent required.
OH1.x binding users would then be required to setup MQTT, but that’s better than not having those bindings, I guess.
1 Like
Well, if the event bus federation was going to be MQTT anyway then that was always going to be the case, right?
The only reason I can think of for not using the eventbus configuration on the MQTT 1.x binding is you may not like the topic structure or something like that. Unless I’m mistaken, this federation could also be used to federate OH 3 instances too and the existing topic structure might not work as well as, for example Homie, in that use case.
But it is true, I see no reason it couldn’t work with just the MQTT 1.x binding and it’s event bus config as long as you are OK being constrained by how that currently works.
sounds like a valid solution and helps people to use older bindings until they are moved.
I do wonder if this is not harder to maintain then the current compatibility bus.
I find it strange to stick to 1.x openhab and not use 2.x that has evolved more.
(I doubt any work has been done on 1.x in the last 2 years)
Well, OH 1.x is still a solid platform. OH 2 came about because the architecture of OH 1 prevented some new desired features like automatic discovery. Rather than grafting it on to the existing architecture Kai et al opted to start anew. (IIRC from those blog posts years ago).
Since all 2.x bindings will automatically be compatible with OH 3 (I’ve read nothing to say otherwise) it makes sense to run the more light weight OH 1.x core instead of OH 2.x with the OH 1.x compat layer because OH 2.x comes with a whole bunch of stuff that wouldn’t be used if all you had were OH 1.x bindings. OH 1.x would be lighter weight over all in terms of RAM resources I suspect because of that.
OH 2.x has indeed evolved over the years, but only 2.x version bindings can take advantage of any of that evolution. It’s wasted on OH 1.x bindings which have not evolved in the same way.
The only reason I didn’t put OH 1 in the drawing above is because I figured David would be making the changes and David is allergic to OH 1 [said in jest]. I also assumed that since this mechanism would be used to federate OH 3.0 instances too, that modifications to how the MQTT 1 evenbus implementation would be desirable (e.g. Homie).
1 Like
How many people understand it enough to do so? Is it more than 1?
I’m not throwing stones, here. But the compat layer seems a lot like the xtend component: few if any people at all have enough knowledge to even touch let alone fix them.
Will there still be a sitemap in OH3 ?
If yes a visual designer with drag &drop elements (which could be provided by the Bindings itself e.g. for a huge lamp there would be an drag & drop element which contains an on of switch, a slider for dimming and a option to change color.) for it would be an easy solution for all non tech savvy people.
If we think more about it there also could be a repository of user made elements which where created for a special use case or which just didn’t got covered by elements provided from the Binding
Sorry if there is already a discussion about it then I must have completely missed it…(there are quite a lot of threads open about OH3 right now and it seems everyone is talking about every issue in everyone of those threads.)
I hope what I just wrote makes sense somehow. It is really late here already…
1 Like
That’s exactly my point why I think that we should get rid of both in the long run - to avoid having bus factor 1 with me being the only one dealing with those parts.
Check out Proposal for a new Sitemap concept · Issue #5337 · eclipse-archived/smarthome · GitHub, I’d wish that this makes it into the code base.
1 Like
What is the actual status? Is the original developer still working on it? Should we transfer the issue to openHAB-core. Does it also support habpanel? I think 1 concept for sitemap and habpanel is the most optimal?
As far as I understood, it really only replaces the sitemap functionality which is allowing to layout items declaratively. habPanel works on html widgets, including js and css directly, which naturally can not be used for native apps for example. habPanel will always stay on its own grounds, but the widget distribution should be improved and unified.
Hi Guys.
I’m new to OH2 and have spent the last 6 weeks reading and trying to figure out how to setup OH2. Via several of the great guys on here, I have managed to finally get a light switch setup and working through the Basic UI. I am retired and if I had the coding knowledge of all this stuff I would gladly jump in and help. I have read a lot of the help files and watched videos on YouTube but it seems there are just one or two pieces of information missing to get you to the end result. I know there are a lot of sensors and modules that can be connected to OH2 but the fine details of getting them connected are missing.
I was wondering if there could be a help section where a sensor was taken from the “box” to all the steps getting it connected to OH2. When first I started using OH, the program would scan my local network and find all the devices on my network including my ESP8266 modules computers, TV and more. Now with version 2.4, the only thing it found was my network printer.
I have tried to set up hass.io and found it way too complex for me to understand all the hoops you have to jump through just to get it up and running. With OH2 almost everything I needed was loaded on the SD card and set up within an hour or two.
I may be out of my league posting this but I just thought it might be good to hear ideas from the other end of the user group (noobs) to help your design decisions for the future. So far I am happy with just using the Basic UI screens for viewing what I have set up so far, one switch (haha) but I think you guys have/are creating a great home interface. From reading the posts above, I can say that I have no idea of the coding you have to go through to keep this program working. I just know what I have seen so far it works!
Thank you
John Frankforther
5 Likes
Nope.
I think that’s a great idea. I always hope to make a YouTube demonstration of setting up a basic home automation setup, taken from installing openHAB on a RPi all the way to making a ZWave sensor work with a rule etc. Having the time to do so on the otherhand is a problem.
Releasing openHAB 3 with a set of premade tutorials? Now that’s something that’ll get new member’s attention.
2 Likes