The last post seems to have been replied to the wrong post. It was supposed to be in reply to pacive
I’m not sure I understand…you quoted the OP and not once does it state that you must program in Java to use OH.
Why you are incessantly arguing with users of said software (when you are not a user of this software yourself) is mind boggling.
To use openHAB you DO NOT need to program anything in Java. In fact, your entire argument has been a detracrment from the initial post, which I disagree with fundamentally anyway.
Your continued replies are starting to scream of trolling rather than constructive criticism of the software since you continue to willfully disregard users of this software telling you otherwise and continue your diatribe of misunderstanding the documentation.
5 Likes
This can be done in different ways, either by writing textual rules, or by just point and click through paperui.
And what @gnuarm did not understand, is that some people call this programming (others don’t)
For most of the rules we don’t need really muhc java skills, yet for some more complex rules, it’s handy to have even more then basis understanding of java programming (I’m thinking of the lambda’s)
Yet these things are not needed when starting out.
The fact that when a new user gets a lot of info on java and not paperui, gives it a very complex idea.
It should mention you need java. so new user can figure out why it’s not launching. yet all the info to install java, is not needed when just reading to understand.
Which shows the duality how user manuals are used.
Both for understanding the basics and for debugging the installation.
1 Like
Trying to resolve the Java confusion a little bit. I was also confused in the beginning and most of this confusion was caused by mixing the different meanings of the term “Java”.
I think it is important to understand the difference between
To use openHAB you …
… don’t have to do Java programming
- openHAB is written in Java programming language, but unless you want to become a developer there is no Java programming needed to use openHAB
- when talking about “programming” to use openHAB this comes from the “old” openHAB 1.x days (and many users including myself do it this way until today) where automation rules (do x if y happens but just in the case of z …) had to be written in *.rules files. To write this rules a DSL (domain specific language) is used. This DSL is not Java programming language but has a syntax that is similar to it.
- If starting from scratch with openHAB 2.x there are different possibilities available to set up these automation rules. One of them is the so called NGRE (Next Generation Rule Engine) where no programming at all is needed and the rules can be clicked together via PaperUI. Unfortunately this NGRE is still in experimental state and lacking some documentation but the community is heavily working in this.
… have to install the Java software platform to run openHAB
- openHAB as any other software written in Java programming language needs the Java software platform to run
- so you have to know how to install this “platform”, basically this is installing a piece of software like you do with any other software you want to use.
- The Java software platform is available from different “vendors” (that’s what listed in this table in the docs). If you don’t have any special requirements or issues just go with the Zulu platform.
Greetings
Sebastian
4 Likes
I don’t think that is the case. This is a project that understands that bridging the gaps between 360+ walled gardens is going to be complex. The only way to be successful at eliminating the complexity is to eliminate the options. This is why commercial offerings, which are much simpler compared to OH, only support half a dozen technologies and standards.
You can’t have it both ways. OH has chosen to support more technologies even if that does cost more complexity rather than limit the end user’s options. If that trade is not a good one for you then a commercial offering is going to be a better choice.
One thing that a lot of users new to home automation do not realize is that building a smart home (or whatever you want to call it) is development effort. You the user are and will be responsible for coding the behaviors of your home automation. You the user are and will be responsible for configuring the system to inter-operate with what ever technologies your bespoke home automation system uses. You the user are and will be responsible for constructing and creating the end user interfaces and experience.
OH is a platform whose goal is to make this easier. But it can only go so far. You WILL have to deal with the complexities of development.
OH 2 has and continues address these complexities in many ways (automatic discovery and creation of Things for instance) and it is by no means done addressing ways to make it simpler. But OH is NEVER going to provide the end user a Firefox like end user experience. It can’t, because OH isn’t the end product. The bespoke home automation system YOU build is the end product. And I can say with authority, almost all of our end user experiences DO approach something like the Firefox experience. But we, as our individual system builders had to put in the work to make it so. OH can and does help (I can’t imagine trying to build a system like I have without some sort of HUB) but it can’t do it all.
I cannot stress how important this will be in anyone’s use of any free and open source home automation hub.
My understanding this is the goal. It is taking an extended amount of time to get there though. And do not underestimate the fury of the old timers if you take away a feature like being able to define Things in a .things file.
But I believe we will get to a point where there will be one official recommended way to doing things. Though support for some of the old ways will persist. I don’t think we will be able to drop them until a 3.0 release where we can say 1.x bindings are no longer supported (for example).
There is a Chocolatey package for installing OH which I believe will also install Java if it isn’t installed already.
See my comments above. Home Automation IS a development effort. You can’t get away from that. Even working with the commercial options requires a bit of programming (more at the Scratch level perhaps). What is Home Automation but defining behaviors of your devices under certain circumstances? And what is defining behaviors but another way to say programming them?
Comments like this, IMHO, show a lack of understanding of the Home Automation problem space and OH’s role in address parts of that problem space,
A home automation system that doesn’t let you define your own behaviors is no home automation system at all. At best it’s home remote control.
Quite a lot actually, but OH does a decent and always getting better job of hiding that fact from you. Much of what you are doing when you create Items and link Items to Channels and create Groups and most especially create Rules are all exercises in programming, whether you realize it or not. The fact that you missed it points to how successful the OH developers have been so far in reducing that complexity.
Possible but I wouldn’t recommend them yet. They are still experimental.
There is no requirement to program in Java to run OH. The only requirement is to install Java as a prerequisite as OH runs on the Java Runtime Environment.
Just like installing Python is a requirement to running Home Assistant.
Java is needed. Programming in Java is not.
There IS programming required to develop automation Rules but those are written in other languages. The default is to use the Rules DSL which is a simplified programming environment a little friendlier to users of OH who are not already programmers. Those who are already programmers are usually happier with one of the other options like JSR223 scripting or using an external rules engine like NodeRed.
An administration UI for OH. See
- https://www.openhab.org/docs/tutorial/uis.html // Page 3 of the Beginner’s Tutorial
- https://www.openhab.org/docs/configuration/paperui.html
Perhaps this is unreasonable on our part, but I do know that when I personally send someone to “read the Beginner’s Tutorial” I expect them to read through the tutorial, not try to perform all the steps (the first time) and then stop when they run into trouble, especially when your main goal is to figure out whether or not OH is something you want to pursue.
Building docs is hard. Building beginner level docs is REALLY hard for experienced users and developers to write because it has been far too long since we’ve been beginners. So we are stuck in a catch-22. Beginners are usually unwilling to contribute and experienced users are no longer qualified to write them.
I don’t think most of us think there is no problem. But is there a problem here we can actually solve? Maybe. Do we actually have any concrete solutions or recommendations of solutions to solve the problem? No, we do not.
You are most certainly right. It isn’t intended to control a few devices. It is intended to mix and match the behaviors of dozens+ devices from any number of different walled gardens of technologies and services in a unified way.
If you want a virtual remote with buttons to control a few lights, OH is way overkill for you. If you want the lights to just know when to turn on based on external stimuli from sensors from three or four different technologies which don’t normally work together then OH is a good place to start.
And now you know why there is no list of devices. OH literally supports tens of thousands of different devices and the number grows every day. The amount of effort required to build let alone maintain such a database is not feasible.
Instead, what one can and should do to determine if a device is compatible is determine what technology/API it uses (Zwave, TP-Link, Xiaomi, etc) and look for whether there is a binding for that technology. If there is only limited support for that technology the read me for that technology will list that. For example, there are only a few Zigbee coordinator chipsets the Zigbee binding will work with. They are listed in the binding readme which you can find under the Add-Ons link at the top of this page.
At the end of this long thread, I think that indeed, OH may not be the right system for you. Your problem may be smaller than OH was built to solve and so the complexity is really beyond what is worth it for you.
4 Likes
I guess this shall never be the case. If an old timer shall want the option, he/she will get it in previous versions, or shall start coding based on the foundations. If someone who is so in to this project and wants updates, should accept the dictatorship of the majority that decides how this project is going to evolve, regardless the fury.
I have only two thumbs. Both are up! For your concise explanation.
I must ask rhetorically: how are we ever going to end the lack of common sense? Reading docs is easy, and even though scarce sometimes, using logic gets you much faster and farther than waiting for an answer on the community forum.
You are battling with cohorts of people asking sometimes stupid questions, and this is definitely appreciated. I have to thank you sincerely for speaking out and advising people when I really could not, because of the lack of understanding people. Thank you, again!
Yes, openHAB needs to define what the target is. I see it as a framework inside a framework inside a framework, etc., but some of the community members (you and many others) are struggling with people asking for an end user solution, and I see this as being a lack of proper positioning of openHAB amongst the users that come to this forum. Of course, I might be wrong.
Pfff, what a lot of crap.
If OH is not for you, leave! Don’t blame.
If you feel insulted: react inline, not in another thread.
I, for instance, felt insulted by @rlkoshak one time, and reacted on that in a clear but respectful way. He told me he didn’t mean it that way, I misunderstood. Hey, it happenes. He is still helping me, I am still learning from him. What is the problem with that? I think I even respect him more now!
If docs are no good, figure out what you miss in the forum, and help making better docs.
Just be helpful and respectful, even if someone hurts your feelings some time.
Oh, one last thing: How to ask a good question / Help Us Help You
9 Likes
OH is a platform whose goal is to make this easier. But it can only go so far. You WILL have to deal with the complexities of development.
I slightly disagree.
yet in words.
I would call what you call development, integration.
Users of OH don’t have to develop.
they do what integrators do. configure and create integration rules.
I prefer not to call it development.
And yes that can be complex too.
1 Like
The community and developers should decide on one single way and improve that to a state, that a second way would not be required.
My understanding this is the goal.
I hope not.
Designer have long time ago already pointed out that most systems (software or not) have typically 3 kind of interaces to do the same thing.
-
an interface for beginners:
this is for first time users or thing you don’t do very often.
(The later might be the closing of a year accountancy. In a personal accountancy you do this once a year, so you need a lot of guidance to not make mistakes, especially if the mistakes are costly, like with a wrong accountancy ending of the book year that you should not tough afterwords.
Giving in an invoice using a wizard might be another one in such system for first time users. -
A system that is for people who are mostly experts and do the task multiple times a day.
An accountant does not want a wizard, she want a kind of spreadsheet behaving page where she can freely swap between fields in fill in everything in the order she wants. -
A third system where third parties can use a kind of API.
In the same example if you sell stuff on a website, that all the sales get automatically in your accountancy system. (And invoices are generated and printed automatically)
Where the this one might not be needed, in general it is considered a good practise to have the first two interfaces as they serve a different audience. They are also less confusing for beginners, as they don’t have to bother with the more advance stuff that advanced users can use.
Having two different interfaces for something similar looks hard to do and maintain, in practise it’s the opposite, as they both have a very distinct audience.
3 Likes
You’re absolutely correct about certain kinds of software UX. Enterprise software is a real nightmare in that regard – during sales processes, you want software to look as simple as possible, but post-sale, the people using it every day need it to be fast, not simple.
I think its a bit of an aside relative to OH, however. IMO, the issue with the splintering of ways of doing things in OH is a problem not because you can hand write rules, items, etc and do it through PaperUI, its that the “simple” way (PaperUI) doesn’t do it in a compatible way as doing it by hand. You’re not using a “wizard” and "advanced’ ways of editing your system, you’re editing two completely separate systems, so you can’t use PaperUI and transition once you get more skilled.
That’s the real issue with the complexity of OH – not that there are advanced and basic users with different needs, its that the admission process for pulling contributions into OH has resulted in multiple fundamental implementations of functionality sitting on top of ESH. There’s more than one way to do rules, all non-compatible with each other. There’s more than one way to define items/bindings/etc, all not compatible with each other. There’s multiple administrative interfaces, with only a small amount of overlaping functionality (PaperUI vs Habmin). There’s very “beginner-hostile” behaviors in parts of the system, like the complete lack of confirmations for permanent actions in Habmin (you can be irrecoverably out days of work if you accidentally hard reset your Z-wave controller, which is right below the option to exclude devices, for example – and no backups will help!). You have a relatively solid UI for some limited use cases (dedicated tablets, mostly) in HabPanel, and a very limited/primitive UI in the form of Sitemaps. The latter was strangely used by the mobile apps, as well, which means you’re stuck with a mobile experience that is sub-standard to even the simplest HA systems had a half decade ago. Because those two systems were implemented completely separately, things like push notifications behave differently between the two. There’s more examples of conflicting mechanisms for doing things in OH than there are examples of consistent ways of doing things.
I suspect, as a result, there’s a lot of people using OH (like myself) who are using it because we needed integrations that weren’t possible with the common commercial systems, or miserable to build with things like Homeseer. Its like choosing to run Linux back in 1998. There were a few distributions that meant you could install a system without piece-mailing it like we had to do in 1993, but there were six different window managers, two or three different common X-windows UI frameworks, a half dozen different startup management systems, and it was miserable to use but you slogged through it because you needed (or wanted) that kind of control.
Unfortunately HA is too small of a market for a “RedHat” or “Canonical” equivalent to come along and reign it in (and the split between ESH and OH makes that really unlikely anyway), but there probably needs to be a bigger laid-out (ie, written down so everyone – users, developers, etc – can see and understand it) architectural vision and roadmap for OH that contributions can be measured against when choosing to accept them or not.
2 Likes
Hello Mark
I support 100% what you are saying. I myself have been suffering of an extremely bad supported (actually you can call it abandoned in my book) binding (digitalstrom). With the lightest breeze it stopped working and you had to work around the breakdown for days until there was a workaround again. Even an offer for bounty did not cure the problem. Just that nobody comes with the payment argument…
OpenHAB is very nice and if I had not the issues with digitalstrom binding, it would quite cover my needs. But now I have to find a working solution, even if that means to pay. I rather pay than wasting my time.
kind regards
Marc.
A paid support isn´t always the best solution, or even the fastest solution. You may still end up spendning more time and money.
Did you put the card in laptop while backing up? The same thing happened to me, I backed up using laptop SD reader, then Thing settings got cleared when put back to RaspPi. You can look for backup under userdata/jsondb/backup folder. Core files:
org.eclipse.smarthome.core.items.Item.json
org.eclipse.smarthome.core.items.Metadata.json
org.eclipse.smarthome.core.thing.link.ItemChannelLink.json
org.eclipse.smarthome.core.thing.Thing.json
Move good backup files from backup folder to its parent folder, remove time stamps from file names. Do this when OH service is stopped.
This might have something to do with file access times being modified by laptop’s OS, then later jsondb in OH finds them inconsistent with its last known house kept values, and decides to reinitialize those core json files. But backup will definitely be there.
The issue is valid though, need a ticket on GH. OH SD card when put in laptop, file systems mounted, copying done, put back in RaspPi, Things and their settings are gone.
That would be least painful route. But imagine a system which can combine events across sub-systems, and allows you to write some interesting rules or solutions. That is a vision of this project. In future there might be AI based apps to detect certain threats, like earth quake, terror attack on public buildings etc.
There is always a value in a Home Automation Bus.
Regarding your support concern, let us hope there are RedHats and Canonicals for OH in the future.
Fedora community is like OH community RedHat picks stable things from Fedora and releases them under RHEL offering, which is commercially supported.
Future is good, let us not troll each other for things that are not working.
Dude… Are you for real ?
I could start by telling you that everyone knows backups are SUPER important as in for ever…
And bla bla bla…
But please show some respect for all the amount of work that has been put into this system. FOR FREE!
And sir you are very disrespectful!! Now be gone 
2 Likes
Welcome to the openHAB Forum.
You just revived a thread that was 9 month and almost forgotten😒
3 Likes
Thanks for the welcome,
Sorry but these kind of folks piss me off big time… Maybe i shouldn’t have had to wake this one up. So I apologize that i couldn’t resist
Per the recent comments, please just let this go without posting further. Doing so boosts it back to the top of the “latest posts” and alerts people who were involved and didn’t mute the topic. No harm done, but best to let the memory fade.
@rlkoshak, can we close this one since the OP departed long ago?
Thanks!