It depends on Holger‘s progress ind the following review. I think nobody is against having it shipped with openHAB 5.
You structured it well with expandable content, so I don‘t think it was to long.
Help is always welcome
specially for people with deeper knowledge about maven build processes.
2 Likes
I have in mind something even better I believe:
https://github.com/openhab/openhab-core/issues/4509
1 Like
Hi Florian,
Thank you for how hard you have worked to keep openHAB maintained - and contribute to this community.
I bring some controversial ideas - which I don’t mind if you shout down - but I want to help the long term health of the openHAB community.
I want to challenge the assumption that openHab should commit forever to the Raspberry Pi. I agree that the community has benefited from this, but during Covid times the machines were hard to get, and the resources available to running applications are limited compared to other platforms. Perhaps openHAB should consider for 5 or 6 starting to think about another platform with more resources. Second hand Thinkcentre boxes have been cheap, small and reliable - but the x86 platform has lots of options and resources.
Following on from that, and related, perhaps openHAB should be considering standards other than OSGI - which the rest of the Java world has moved on from. The idea here is about winning over Java developers - for whom raising “OSGI” in conversation is likely to raise eyebrows. I get that openHAB uses a well-documented standard, that works well for modular, low-resource Java environments with hot-reloading. I wonder if OSGI is the only way to achieve this goal.
Anyway - thanks for all your work, I know you do heaps around here. You inspire us all to contribute and help how we can.
Cheers
Julian
1 Like
Julian,
upfront, please stay on topic. As the title clearly says this is about future features. Not about how things are built internally i.e. OSGI nor about anything-hardware.
On the hardware part you are showing a lack of understanding what openHAB actually is and how it relates to hardware.
openHAB is only Java software.
As such it runs on ANY hardware and OS that Java runs on including x86 and Windoze.
There’s no need to use a Raspi, anybody is free to choose the HW they like to.
Raspis however have the invaluable advantage that there exists a well optimized OS image called openHABian - which is NOT openHAB - that makes it a lot easier for everybody and particularly so for any layman to install and get your openHAB installation going quickly.
The HW discussion kept and keeps popping up every half a year or so, but is actually mostly unrelated to openHAB itself in fact and does not belong in this thread.
There are several discussion threads on HW, just use the forum search function.
As a moderator, may I ask you to move over there. Thank you.
3 Likes
Is there another thread where this was discussed? I think it is not posssible to replace OSGi as this would mean redefining the OH architecture from scratch.
1 Like
AFAIK not. And you are right, this would be a complete redesign/refactoring of openHAB, which, if possible, would take years.
1 Like
There is a thread that touches this, with many related links: [WIP] Upgrade Karaf to 4.4.7, Xtext/Xtend 2.37.0 by holgerfriedrich · Pull Request #4406 · openhab/openhab-core · GitHub
2 Likes
Thanks, did not see this.
I must have misclicked something, my message came to wrong thread…
thanks for the kind words, BUT remember openHAB is a big team effort, so it’s not me it’s us 36 maintainers and many more contributors.
I think Markus said everything to say on this topic, openHAB itself has never focused on running on Raspberry Pi, but rather everywhere a JVM runs.
Raspberry Pis are „just“ a very common hardware to run openHAB, because they are cheap, energy-efficient, powerful enough in terms of Pi 4 and Pi5 and good at sitting in the corner just working fine.
But there are many people running openHAB on different HW, Mac Minis, NUCs, big x86 servers etc.
We adjust our HW recommendations over time, e.g. for openHAB 4.3 we recommend Pi 4/5 with at least 2 GB RAM to match the performance needs for those wanting to use a Pi.
I see no reason for leaving OSGi behind, which would be a huge effort.
OSGi is still used among the industry, and other big OSS like Eclipse IDE uses OSGi as well.
Frameworks like Quarkus (and I think Spring as well, not sure how comparable Spring is to Quarkus, I only know Quarkus) are no alternative, while Quarkus is absolute great (I’m working with it at university), it is not quite as powerful in terms of modularity as OSGi.
To be fair, for most add-on development and even large parts of the core development (at least in my experience), you don’t need to deal with OSGi or Karaf in detail.
I developed my first add-on without caring about OSGi, just followed the developer docs, and everything just worked when deploying my JAR to the addons folder.
4 Likes
I’m using Openhab since the 1.x version and it is reliably running my house since almost 10 yrs. While I’m using HABApp for most of the automation I use OpenHab for the UI and any interactions with the smart home and I really love the main UI introduced with 4.x.
If I had a wish for 5.x I would love to see improvements on the widget editor or the way the widet information is stored. I would like to have the widget and page definitions be simple files that I could edit with VS code and that I easily could version control.
3 Likes
100% agree that would be much better.
You went much further with this that I have even hoped for.
Your GET /things/{thingUID}/suggestedfilesyntax would do the trick (and then some). 
BTW, it would be cool (not sure if it’s easily retrievable, though) to distinguish if a certain thing property comes from explicit user input vs. binding’s default (otherwise the text configuration may become large and a little rigid).
1 Like
It’s a binding-topic (rrd4j) but maybe relevant for a major release:
Add rrd4j-persistence for switches and contacts by storing them as numbers (0/1).
Currently switches and contacts cannot be persisted in rrd4j as they are not numbers. But wouldn’t it be possible to just save them as 0 and 1? The benefit would be an easy way to track switches and contacts and to display them in graphs.
In rrd4j-documentation is a note about that:
NOTE: rrd4j is for storing numerical data only. It cannot store complex data types. The supported item types are therefore only
Switch(internally mapped to 0/1),Dimmer,Number,Contact(internally mapped to 0/1),RollershutterandColor(only brightness component stored).
I guess you didn’t read my post to the end.
The proposal is to store those bools as numbers.
Isn’t that what it currently does? At least that’s what the quoted doc says.
4 Likes
whoops, you’re right, thank you. I just tried and successfully restored old values.
Then I would like to change my wish/suggestion to enable the analyze-link in the item view so that it shows the graph with 0 and 1, maybe like this:
So for me it is displayed exactly as you would like it to be. As a surface, but I can live with that.
1 Like
whoops Nr.2.: I checked with the wrong item which was not persistent. With the right one it looks exactly as you say. Again learned something… thanks