It was fun while it lasted!


(Rick Collins) #60

To pacive

Amen! I know how to program in several languages. I know a bit about Java. But no, I have zero interest in programming in Java to use a wifi connected switch. I have one that came with software (although only on the phone) and another similar. One app is pretty good and the other is crap. But at least I can use them.

Everyone is free to do things as they wish. But it just seems so overkill to ask a user to do programming to use an open source project. I guess that is just me. Enjoy


(Adam Edwards) #61

What programming is required to run an OH installation? Aside from installing the prerequisites (on pretty much any OS of your choice), the only thing really required to be done outside of the GUI is a custom sitemap…and I think even that can be done through an automated script now.

To insinuate that OH requires “programming” knowledge to run an installation of it, in my opinion, is a slight on all these developers who have put these tools at our fingertips in about as understandable a way as I can possibly comprehend.

I missed out on a lot of the OH1 days, but if you think OH2 requires “programming”, then you would have REALLY had a difficult time in the OH1 version. It has come a really long way in a short amount of time. Paper UI is HUGE for this software. It’s not perfect, but I have done everything in the GUI aside from a sitemap and some automation rules (which also are now possible to implement from Paper UI).

If you don’t read the docs, I can understand how it can be considered complex. And even after reading the docs, it’s not a walk in the park, but home automation is a complex subject.

This community is incredibly helpful and I won’t even attempt to list all those that have just helped ME directly. This forum may not be a help desk but it is an excellent knowledge base. Searching Google for my question with “openHAB” attached to it yields a previous question (which has already been solved) 90% of the time. The other 10%, I typically piece together multiple posts or try and solve on my own.

But I don’t think any of that sounds unreasonable.


(Rick Collins) #62

I wouldn’t know. I was following the directions for the tutorial and responding to those who feel knowing how to program in Java to use this app is reasonable.

Are you saying Java is not needed? Maybe you should share that with the other posters?

Have you viewed the tutorial? Why is Java installed if it is not needed?

Paper UI??? Not sure what that is.

Did you read my posts? I gave specific details of what I found difficult about reading the docs.

I think this is a perfect example of why this project is the way it is. If you don’t think there is a problem, I guess no effort will be put into solving it.

I’m not trying to say OpenHAB is of no value. The only thing I’ve ever said is that it appears far too complex for me to make an investment in to control a few devices. I don’t know what OpenHAB has to offer much less what it has to offer that is better than other solutions. I likely never will because it isn’t presented in a way that provides that information. More importantly it requires serious effort to begin considering to use it. Not only was it hard to learn what is is about, it seems there is no reasonable way to find out what devices are supported. I even found an effort to create and maintain a spread sheet of that info and many discouraged the effort because it wouldn’t be perfect!


(Adam Edwards) #63

Umm…I think you are misunderstanding…you don’t program in Java. Paper UI is the point and click GUI which performs all the under the hood operations that interact with the rest API (and I’m sure I’m selling that short). No offense, but if you don’t know what Paper UI is, then you haven’t interacted with the software enough to have an educated opinion on this matter.

In fact, it’s described in the docs.

In my earlier post I wasn’t trying to insinuate that you hadn’t read anything. Just saying how overwhelming the software would seem to someone who didn’t. I apologize for that confusion. Anyway, user programming in Java is not required to run an installation of OH. The application USES Java. That’s why it’s required to be installed.


(Anders Alfredsson) #64

You need to install the Java runtime I order to run OpenHAB on your computer, just like any other application written in Java. That doesn’t mean you have to do any of the programming.


(Rick Collins) #65

Then why are people saying I should expect to do programming if I want to use OpenHAB???


(Anders Alfredsson) #66

The programming is just like in any other HA-system: “If this happens then do this”. There is no system that just automatically knows what you want it to do when, for example, it senses that you’re home because your phone connected to your WiFi. You need to tell the system that.

This can be done in different ways, either by writing textual rules, or by just point and click through paperui.


(Rick Collins) #67

Hmmm… I guess I really should just give up. The topic of conversation is needing to program in JAVA. Does anyone read further back than just the last post???


(Rick Collins) #68

The last post seems to have been replied to the wrong post. It was supposed to be in reply to pacive


(Adam Edwards) #69

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.


(YvesHanoulle) #70

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.


(Sebastian) #71

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


(Rich Koshak) #72

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

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.


(George Erhan) #73

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.


(Guido Van Haasteren) #74

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


(YvesHanoulle) #75

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.


(YvesHanoulle) #76

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.


(G H) #77

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.


(Vincent Regaud) split this topic #78

44 posts were split to a new topic: Next generation design : Idea’s & Discussions


(Marc Tanner) #79

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.