I have looked up the code. The compat1x layer is basically a complete OH1 core plus some adapter classes that translate between OH2 and OH1. That is nothing someone want to maintain for long.
If anybody is starting to migrate the persistence Iād like to standyby, look, learn and take some part of the work.
Why not? Iām all for moving forward, but you still need to maintain backwards compatibility. The OH1 Insteon binding is widely used, was very difficult to reverse engineer and is now very stable. At this point, I donāt see anybody willing to take on the effort to rewrite for OH2/3. BTW, the Insteon binding is the reason I moved to OH in the first place.
2 Likes
Iām going to recommend the following.
-
Create an issue for migrating the Actions.
-
Create an issue for migrating the Persistence add-ons.
There is no controversy over this and I think everyone agrees it needs to be done.
Iām not sure where to go next for the bindings.
2 Likes
I think these may need to be separate, or single parent w/ children, so that each can be addressed individually. Here is one for JDBC that I opened a long while ago.
1 Like
Iām familiar with this code and how it enables compatibility of 1.x bindings under 2.x is actually pretty straightforward. To the extent that 2.x bindings use the event bus, and through the compat1x layer 1.x bindings also use the same event bus, itās clear that both binding types can use the event bus, since theyāre doing so right now.
No modifications to the 1.x bindings themselves would be needed to support different ways of modifying item binding configurations, because 1.x bindings are already completely ignorant of .items files, and have always been since Iāve used openHAB. How items that are bound to 1.x bindings are configured could be extended to use APIs in addition to .items files. I suspect this wasnāt done because openHAB was split into ESH and openHAB at the same time the 2.x binding model was introduced, so this code split probably made it just too difficult, lamentably, at the time to properly support 1.x bindings. But with the re-coalescing of ESH code back into OH, it seems like an opportunity to undo this chasm, and the happy continued existence of āitem bindingsā alongside the later āthing bindingsā could be easily documented, supported in APIs and UIs, and the whole product could be greatly simplified without losing any functionality. And the religion of killing off perfectly good and stable functionality could finally be put to rest.
And if all available developers want to have a āmy way or the highwayā or ānot invented hereā attitude about strengthening the totality of the openHAB product instead of lopping off old bits of perfectly good functionality, that is absolutely their right, just as it was my right to go do something else with my time back in 2017.
Iām just here trying to open some eyes to possibilities that people might like as a path forward, because I think openHAB still has great potential and is a massive warehouse of great integration and architecture.
7 Likes
I know of at least one other person who quit doing OH development because of this attitude.
Itās important that stakeholders know why developers are drawn to, or repelled from, a project. So if this person were to return with their opinions, it might be constructive for stakeholders to know them (if presented constructively of course!). Open and honest communication can only help a project.
7 Likes
The way I read it, @vossivossi means that even if you only use OH2 bindings then there is still the "schizophrenic configurationā. Some things can only be done in the GUI, others only via text config files. Dropping the 1.x bindings will not change that.
1 Like
Thatās another topic and is already in discussion so why do you mention it here? ^^ that will be solved in the end. The question is how to preserve / rescue the labour that went into the OH1 bindings. Maybe the OH1 maintainers can separate the logic as best as possible so that embedding it into an OH2 binding shell is not much work.
Ione thing that does come to mind on this topic. Maybe if we stick with the move forward approach people will come out of the wood work and update things.
I agree this topic is very challenging but sometimes you find out who is really serious when you take the hard road. The hard road being what @Kai suggests leaving 1.x behind.
Trust me I hate saying this but it can many times be what moves us as people forward. Certainly I want discussions like this one prior to making a decision. But I think we have discussed plenty may be time to start acting. Either way of course!
1 Like
What does the parallel operation of an OH2/3 and OH1 engine (as proposed by @David_Graeff) on the same computer mean in terms of performance? I am asking as an Raspberry Pi owner ā¦
Thanks!
You need more memory for those two OH instances.
Thatās a problem on a Pi, I assumeā¦
It depends, I think, especially if you are running other services on the pi or not (node-red, homegear, ā¦).
If your pi is on the limit, would it be a real problem to eventually put another pi in service for this scenario or use a more powerful system?
(For me itās really not, but I like servers, so I think I am to biased to give an opinion for this)
If we have to run multiple Pi to have a fully functional smart home server, many users would be disappointed. And yes, for me, a Pi is ātheā perfect hardware for a smart home server. Whatever direction OH takes, if it does not run on a single Pi, I assume many users will leaveā¦
1 Like
Not only for you but for many users.
There are not many alternatives with more RAM.
Maybe the Pine64 but iām not sure about the easy setup like itās possible with openhabian.
Back to topic.
@David_Graeff this question was meant serious.
I know the work depends on the binding and itās functionality but what do you think would be enough for a developer to do the work?
Letās take the CalDav binding as an example.
I thought this is very much on the topic: If the OH 1.x compatibility in the future is realized by an additonal OH 1.x server running (as proposed by @David_Graeff above) I am simply afraid that this will be a pain on a single Pi.
I mean it is your wish to run OH1 bindings. You donāt need to. And if you do, itās not many bindings is it? OH1 will not consume much RAM in that case. Maybe 50 to 100 MB.
Probably around 250 for a small binding.
Well, I only use the bindings I need. In my case, the CalDAV binding is the only 1.x binding (I think), but it is essential. Not having this one breaks everything. Call it a wish, but if you put it this way, using OH in general is also only a wish.
100MB is 10% of the RAM, and looking on the utilization, this would be relevant! Noteworty, my Pi only runs OH with few bindings and a handful of rules - so consider others who might have a more complex systemā¦