I mean to auto create all the items and automatically link them to the appropriate channels? No?
You don’t need Simple Mode turned ON to autodiscover Things.
You need Simple Mode turned ON to automatically create Items.
Yes that is what I meant. Because it happens when the Thing is discovered/added.
1 Like
Except the Item names are not intuitive and the system has more Items than you wish to control.
I have several plugin outlets. I just want to control the binary switch and am not interested in monitoring the power usage or voltage of the connection. I do not need Items for that and the system does not need to process the reports.
I did not recommend to use Simple Mode 
You were just stating its functional purpose then. The meaning was not clear to me in that posting.
1 Like
I meant that it is self-explanatory that we cannot test all HW/OS combinations.
Simply applying common sense leads to the inevitable insight that there are just too many of them to test all of them.
That now changes the often-made user assumption “they provide it to run on any Linux so it is supposed to work on my specific HW/OS combo” into “it is supposed to work on listed HW/OS combos it was tested against and if mine is not listed then noone knows and I can hope but not expect it to work.”
If I was to ask 10 people “what does the standard smoke test contain” then I would get 20 different sets as an answer. So while there would be a lot of overlap, there is no such thing as a definitive “standard smoke test set”. And if there was, it would be clearly written down what’s contained.
I don’t get the point. You don’t want to use openHABian and now it did not work when you installed on your box. That does not mean it’s a bug or needs fixing, problem can as well be on your side, located in the OS (config) and the java and OH install method you chose.
Then it’s getting completely confusing. You don’t state the environment. The OP stated he used a Pi4. You don’t mention your HW but talk about Ubuntu LTS and later about using a VM (?) which together makes me believe you talk about x86. So that’s a different platform than the original platform thus it is different issues (if any at all) and you should not have cross-posted to this thread.
You claim “install did not work” but don’t provide logs and even fail to state what the problem is at all. It is totally unclear what it is that does not work.
Then you go on to explain you chose to install Azul Java using the repo install method on x86 ?
I don’t know about x86 but at least for ARM, Azul does not maintain the repo any longer so you probably installed something ancient that you cannot expect to work.
Note these were plain choices of yours, not recommended nor bundled from openHAB side.
If you believe some documentation told you otherwise please refer to it so we can correct it.
PS: openhabian is not blackbox, it’s just a set of scripts so it’s as translucent as can be
1 Like
@mstormi
I installed Zulu (Azul) java because this page of the Linux documentation openHAB on Linux | openHAB recommended it:
As a first step, please verify, that your system meets the [prerequisites. You may want to install Zulu, a fully certified Java build [as a package] or [manually].
I would never have chosen it otherwise. If this is no longer valid, it stands to reason there should be a big disclamer on this manual Linux install page or it should be changed.
I chose zulu-8 because the same documentation page states:
Make sure to download Zulu or Java 8 , as openHAB is not yet compatible with Java 9
Indeed because I did not open this thread and was simply concurring with the original poster @k3mist . I stated that I have the exact same problem and I did not provide logs because mine were exactly the same as those of the original post.
@k3mist incidentally did not seem to have used Zulu JDK according to his post and he ran into the same trouble regardless
@mstormi’s point is you do NOT have the exact same problem. Ideally, to avoid confusion, you should have started a new thread.
You are running a different CPU hardware architecture and a different OS (Ubuntu vs Raspbian). You are apparently running an OS in a VM. The original poster was running a native OS.
If you keep criticizing the volunteers trying to help, we will just leave.
Ypu are right. I missed the fact that the original post was not on a Linux machine. I overlooked that based on the title of the post which had (Linux) in it.
My mistake. I’ll open a new post next time.
I’m not trying to criticise. Just want to help out avoiding others falling into the same pitfall as I apparently did with the zulu install and everything. Just pointing out that the documentation might be misleading. I leave it up to the wiki maintainers to judge whether it should be adapted or not.
Appreciating all the help.
Thanks
It’s ok to go Zulu. But if purging the package helps, the cause possibly is related to the installed package and that depends on the install method. You insisted on using the repo install method which was not mentioned to be the preferred option, it’s rather the opposite (read your own quote).
Let alone that we cannot take resposibility for or keep up with what Azul provides or changes in their repo or website.
I still fail to understand what you believe to be misleading there.
But ok. Every docs page ends with the discreet hint below.
Use this to submit a docs PR to contain your improvement proposal, it’ll be passed to the responsible maintainer who then will decide to merge it or not.
1 Like
zulu is just a commercialized version of openjdk. personally if i was going to go that route (commercialized) i would use amazon’s corretto as its used on thousands of production machines in amazons cloud.
all 3 (openjdk, corretto, zulu) should not have any runtime difference. the only difference with the latter 2 is they are vetted builds and are run though a series of tests by commercial organizations.
at work we consume ~80-110 million records every 5 minutes on software written in Scala with Corretto runtime and there are other processes down stream we run that are running on openjdk (easier to create init scripts with openjdk rather than with corretto)
you’d be hard pressed to find runtime difference between any of them IMO
And since development here is focused on Zulu (and a majority of the volunteers here use it) you would be stuck figuring out any Java issues yourself.
well i wouldn’t recommend anything but openjdk in general
depending on commercial organizations for anything you aren’t paying real money for has a long standing history of not panning out well
You better not use a compiled Linux system then. Many commercial organizations have contributed code and other resources to it. Perhaps you need to inspect the source (and the compiler) and build it yourself.
FYI, in testing on a Pi I verified 2.5 Milestone 2 and later fresh installations are broken when installing openhab2-addons. This should be a major embarrassment to the developers, in my opinion.
Comparing the linux kernel to the current state of Java is not remotely the same.
The kernel receives/merges downstream code that only the kernel maintainers feel that they can support and there is a long history of Linus and other maintainers not accepting commercially supplied code if they felt it can not be supported long term or at all. And its all decided and controlled very openly allowing anyone to participate.
Java is simply a hot mess with different commercial organizations doing different things with the runtime based on their own agenda’s which are discussed in private.
There is a single owner.
Oracle owns and controls the Java standard. They solely determine what is included in Java.
So what now? Should we open a ticket? Is there one?
looking here; https://github.com/openhab/openhab-addons/issues
there appears to be a lot of open issues related to 2.5 release
Milestone 1 was built January 29, 2019 and Milestone 2 was built August 9, 2019.
In between there the build system was redesigned in addition to a myriad of changes. I am researching now whether it makes sense to try and narrow things down further using snapshot builds.