As CFO of the openHAB Foundation I would like to step in and give a bit more background why we cannot pay developers or run paid services.
A registered Foundation in Germany can collect money through membership fees and donations, fine so far and nothing special. Having a non-profit state, the Foundation gets tax exemptions, so we are not paying taxes for the money we receive. This also means that we have to spend the money for the purpose the Foundation was founded and received the non-profit state. This purpose is consumerism and consumer information. So the expenses of the Foundation have to be for informational purpose mainly, which is covered by running this forum or a demo server and other activities where we inform the public about openHAB and the „Intranet of Things“
What we definitely cannot do is pay any developer, as this would not be of an informational aspect.
I hope this makes the role the openHAB Foundation is playing actually and will play in future a bit clearer.
Because they´re already advanced users. They dont struggling trying to comprehend openhab. They have been there and move to the next step. They know how to deal with whatever lack there may be.
I wonder how come you cant see this is where the different is.
Probably… I adress the community because I´m naive thinking developers are a part of the community as well. Whats good is it to have developers without a community or vice versa…
I give up Rich… You simply wont understand that I´m not trying to censor anyone. I´m trying to change focus of what I believe matters most… I accept others are having a different opinion. But they´re not in the same situation, which I tried to explain, makes it a bit more difficult to agree upon.
Again, because they´re in a different situation. They´re advanced users, not struggling to comprehend openhab or how to deal with the lacks in UI´s.
I do NOT think its unimportant. I´m stating that, before anyone reach the stage of whatever rule engine beeing chosen, they have to understand how to setup openhab and deal with its lacks and difficulties first.
Last shot - Is it important for you to be able to run, before you can walk?
My saying is a simple as that!
What I find interesting to ponder is if the hiring of full time people is a good thing or not, it could go either way. HA have done it and time will tell but it may take years before the effects are seen by the end users. If Openhab chose to go that way it would mean some volunteers would no longer contribute with the attitude “Someone else gets paid, so they should do it”. Loss of some high end programmers would result or a reduction of the amount of work they do. Does the gain of a full time programmer out weigh the loss of volunteers?
Home Assistant has sold the $5 a month as a fee for “premium features” and not just access to their cloud. This means the plan is to add features that only paying people access, the longer the scheme is in place the further they will migrate from paying is optional to being that the software really needs the so called optional package. Openhab may see a lot of people migrate over here because of this decision and it may take some time for this to be seen.
I have tried multiple times to setup HA, And lost patience every single time. It’s just overly complex to do basic things I can do in openhab.
My only real contribution would be to say a ‘how to’ / ‘explanation’ creation of a very simple binding. Just so the likes of us that want to contribute can read a laymen’s term, these bits do this and these bits do that and get started. I find i.t languages pretty easy to pick up, albeit with a little help of google, but being referred to the xtend pages or the eclipse pages just boggles the mind, w3schools has this down to a T with html for instance, examples and clear English explanations. I don’t work in I.t, everything I know is self taught, and examples and tuts are by far the way to go. May help get more people on board.
I think I made a utterly wrong statement (so I triggered people) or topic got hot again by its own ways. When I checked answers there were just two comments. When I returned to write back I found many more comments to go through.
When I said “there is no cash in OH community” I meant that trying to convince OH users to pay for anything will be hard. After all, many of these ladies & guys are tough DIY folks who reverse engineered and published complicated protocols, made a lot of effort to get their home setups working properly and invested a lot of time to go through all aspects of making their home smart. Additionally even if myopenhab (seems) to be in maintenance mode, it does it job and most of users seems to be happy with it.
I don’t think there is a need to “argue” about that. I believe that such decision was made wisely and not by accident thus it has its rationale. I have no point to even start such topic, because I know nothing about german tax system beside it is super complicated.
I know this point and honestly, have no problem with that. Earlier point with “no cash” is coming from different angle. Most of OH users are not regular, or typical, consumers. They are driven by own thoughts so they decide to take vendor independent software for their houses.
I remember a post which I read at linkedin few weeks ago. Whole post was about Battle of England and planes which have been hit but found their way to land. Army commanders decided to employ engineers who would improve plane design to increase likelihood of return after hit. Tech guys quickly recorded places which been demaged by bullets. These places started to form patterns which been turned into hotspots. Engineers started to work on improvements on these “hotspots” - making shields there and offloading other places. One of guys who been involved in whole process opted to work on places which haven’t been hit, however his opinion was ignored. After a year when planes with new designs were flying it turned out that the one guy which voice been ignored was right.
The problem were not hotspots created from airplanes which have returned. Fatal hits were these which made whole machine crash and not come back in first place thus engineers should look after places which they haven’t found.
To reflect this story - maybe all topics which are turning to be so “hot” and controversial on forums, are not these which we should look for in first place? Above story shows also that even when there is plenty of data, it still might be interpreted in wrong way. I started a new topic to collect some data, so we will be able to talk about numbers and try to avoid mistakes made by other engineers long time ago:
Lol that’s exactly where I came unstuck. Installed homeassistant on my qnap… hold on where’s the add on store…
That’s when I learnt.
Then took 2 install attempts for hass.io after boot loops on a spare raspberry pi, just couldn’t get into it
100+ posts so far and all because of a post based on misperceptions. Let’s throw another log on the fire.
I’ve watched a lot of videos about Home Assistant and the one thing I recall them all saying about openHAB is … nothing.
Please post links to the videos where they demonstrate Home Assistant’s superiority and make compelling, irresistible reasons to switch from openHAB to Home Assistant. So compelling that one is overcome with the desire to convert.
Oh and at least three such videos please … and I’ll show you an easy dozen where they don’t even mention openHAB.
Over its 5+ year development period, Home Assistant has gained mind-share among home automation hobbyists. Like openHAB, it’s an open-source project so its growth (or decline) is based on the participation and contributions of volunteers. There are many ways to contribute:
Answer questions posted in the community forum.
Submit new integrations (i.e. new bindings).
Make videos explaining how to use it.
Write blog posts.
Share your configuration via GitHub.
Produce a podcast that interviews users and discusses the latest release.
Both the openHAB and Home assistant communities do some or all of the above (and more). Both are competent products backed by enthusiastic communities and choosing one over the other is a matter of personal taste and suitability for your specific needs.
A year ago, I needed a new frontend for my existing home automation software (that I’ve used for over a decade). I chose openHAB and worked with it for about 6 months. There were parts of openHAB that I liked very much and other parts, less so. Last fall I decided to investigate Home Assistant. It suited my, admittedly limited, needs better (it was easier to create a frontend). So I stayed with it and, over time, have become deeply involved with helping other Home Assistant users.
I’ve read most of the 100+ posts in this thread and there’s misinformation and speculation about Home Assistant. I’ve spent a lot of time participating in its community forum and I feel comfortable in saying most of its users rarely ever discuss openHAB. The few times it is mentioned, and I have been one to do so, is to suggest that some users switch to openHAB.
Why would I do that? Because Home Assistant’s whirlwind 2-week release cycle often involves breaking changes (and a few bugs). For users who don’t bother to read release notes (listing the breaking changes) and who blindly upgrade … it can have unpleasant consequences. If the user wants a more traditional release cycle, they’re encouraged to use other software, such as openHAB. No harm, no foul.
The 2-week release cycle means rapid evolution of the product. One peek at its GitHub repo shows almost 500 PRs in a month. It also shows hundreds of issues although only a fraction of them are critical and most probably belong as tech support questions in the community forum. Anyway, at this stage in its development (which would be fair to call ‘late beta’) it’s not for people who want to do just one or two upgrades per year with no surprises.
For almost a year, the founder was employed by Ubiquiti for the development of Home Assistant. Honestly, I don’t know what Ubiquiti was getting out of the deal (other than saying it sponsored an open-source project) but they recently parted company. The founder has now moved to the business he started called Nabu Casa.
Nabu Casa effectively offers a paid version of openHAB Cloud. For US$5 per month, you get remote access and an easy way to integrate Google Home and Amazon Echo devices. These features are already available for free but require more work to implement (via a reverse-proxy
and related services to secure the connection). Nabu Casa’s cloud solution simplifies the process, as does openHAB Cloud. The $5 fee is also considered to be a donation to the continued (rapid) development of the product.
Given that there has been no announcement that even comes close to what you just described, it’s safe to say it’s all wild speculation. The first thing Nabu Casa’s service offered was merely the ability to easily integrate Google Home and Amazon Echo. The extra feature they promised was recently delivered and that’s remote-access. So now, Nabu Casa users have the same functionality as openHAB Cloud users and are equally ‘locked in’ to the cloud … which is to say not locked in at all.
Quick question: openHAB and openHABian, what’s the difference?
While your thinking of the answer, I’ll explain the difference between Home Assistant, Hass.io, and Hassbian. They’re all Home Assistant but in different installation forms.
Hassbian is what you claimed you could not find, namely a ‘one click pi image like openhabian’. That’s precisely what it is.
Home Assistant is written in python so it can be installed on any platform that supports python 3. Personally, I have it installed this way in a ‘python virtual environment’ (venv). In a manner of speaking, that’s the way I installed openHAB the first time (after installing a suitable Java environment for it).
Hass.io is comprised of two Docker containers (one with Home Assistant and another with a hypervisor). It is available as ‘one-click Pi image’ (along with a minimal Linux-based OS) or just the Docker containers (so you can run it on any other platform that supports Docker). The advantage of Hass.io is that it shields the user from the system’s inner workings. Add-ons are just Docker containers providing additional functionality (and tuned to work best with other parts of Hass.io). Instead of trying to understand how to install nginx or caddy or zerotier, you just select the Add-on, fill in a form with a few details, and the new feature is operational.
Last but not least is Home Assistant as a pure Docker container. I have Home Assistant running this way on my test server. Being a Docker container, it makes it very easy to perform upgrades (or downgrades) as well as add other containers for Mosquitto, Influxdb, Grafana, etc.
For long-standing openHAB users, they’ll recognize that at least three of the four installation methods I’ve described are also available in openHAB.
There’s nothing adversarial about the two communities. It’s just two different approaches to home automation and everyone is free to choose whichever works best for them.
Just to make clear, from my point of view…
I do NOT care which is best, OH, HA or anythings else…
I have chosen OH, which means, all my sayings are my idea and suggestions in how to make openhab better. Ie finding problems which I believe could and should be better without paying any attention to any other system, cause I simply dont care!
All of you have had a lot to say and I’ve been following along for a few days here. The original question was basically about Home Assistant publicity… I started my home automation journey with HomeKit then tried HA for a couple of months (had a functioning system with plenty of errors and breaking changes) then moved to OH. There was some overlap when I ran both HA and OH…
My opinion: OpenHAB is dying FOR ME.
Allow me to explain the reasons:
1- My hardware investment is Insteon. There have been plenty of false-starts on a new binding there over the last few years. Nothing has come of it. I do know that the ISY binding was started but that, too, has been abandoned.
2- OpenHAB is far too complicated for me. I wrote my rules in xtend which was not easy and I still don’t fully understand the programming I have in my system. Lots of black boxes that will work until they don’t - at which point I’m out of luck.
3- The only user interfaces in my house are: light switches, apple tv remote, and Siri. That’s it. This goes back to OH being complicated - I just don’t need the massive amount of power and “stuff” it does to be able to run my automations.
Add on top of that the new direction things seem to be going - eventually I’ll have to rewrite all of my rules, eventually I’ll be without a great way to use 1.x bindings, eventually I’ll have to redo everything so why not redo it to a system I have had better luck with?
There are always arguments for or against it. But even with a change you will encounter limits, other limits, which you were not so aware that they exist. I mean, try to address the problems first and then solve them one by one. Go into the depth, we help with all problems.
Why should you have to rewrite your existing DSL rules? Absolutely not! DSL will be around for a long time to come. Even if it can be that they will be announced sometime, the time will be very long until DSL Rules will stop to run in openHAB.
New ones you can write e.g. with JS. And rules that have to be changed can be rewritten in JS.
Not really, no. It doesn’t take long to realize that isn’t actually a great binding. To quote a recent comment from the developer of that binding:
He does not provide a hopeful outlook. My problems with the binding have been patched up with messy rules, added xml files, and a setup that is not very stable in the long term. If I have a device that needs to be replaced I’ll be stuck with a few weeks of reprogramming. It took me over a month the first time and didn’t get easier over time. Example: the method available in that binding to build a group scene (so each light turns on together) involves running a python CLI program with a steep learning curve and very little documentation…
I said “complicated” I should have said “complex” … the amount of stuff it does and features it has gets me going down far too many rabbit holes for my own good. Like I said, I’ve got a functional system in OH and am enjoying and using the automations daily.
Essentially I’m scared of messing with my OH deployment in the same way I wouldn’t poke a bear in the forest. It’s fine how it is, I’ll almost certainly break it if I try anything.
I’ve considered running insteon-mqtt linked to OH. But the complexity of the MQTT binding and having to manually link things/items/channels to a non-standard (non homie protocol) is not worth the effort to me. Especially since I’ve been moving over to node red slowly with my first move being HomeKit…
The node red developing environment works better for me. As I said in my first comment, there are arguments and fixes to everything I have problems with but I personally would rather invest the time into node red.
Another thing that has turned me “off” about OH is using new-ish bindings. My understanding of the milestone builds is they’re generally development/beta versions, not really recommended for full deployments or non-advanced users. Full disclosure: I do not understand the OH development process. I have tried and failed several times to load a binding from github using maven. Some specific examples:
MQTT 2.4. This was released recently, generally works, but I ran into issues immediately. I tried to use the new built-in broker and was left with error logs. Then I tried to use the new MQTT discovery feature which was shipped with a breaking bug. No big issue here, each of these things are known and fixed in milestone 2.5.
The active-development bindings are generally milestone-only. The Unifi binding is currently under development and to use the new version that works with fewer errors than the 2.4 add on - guess what you need to go to milestone 2.5.
the apple tv binding is a new development. It has huge potential and is going to be very cool. Milestone 2.5.
the new work on HomeKit I believe is also milestone 2.5.
So new development is happening but to get involved I either have to wait months for a 2.5 release (then maybe 2.6 if there were bugs!) or I have to run the potentially unstable 2.5 milestone.
In the case of Apple TV, I’ve been running PYATV for months inside of node-red as a command line program with great success. No milestone build necessary.
In the case of HomeKit, there has been a little progress in OH finally but I’ve had a great system up and running inside of node-red… Based on my homekit/nodered tutorial thread I think a lot of others here have been moving their homekit setup over, too.
In the end, I know OH could work - if I stuck with it I could have a good system eventually once development has progressed more. I’ve found fixes for my openhab deficiencies in node red - once I move away from the Insteon binding the only thing left in OH for me is basically timers. It doesn’t seem worth the effort to keep OH running just for Astro and Expire bindings…
But you are trying to change the focus by shutting down and discouraging discussion on any topic that isn’t, in your opinion, what matters most.
I don’t disagree with your opinions or your ability to express them. I disagree with your insistence that in this case what the rules language is not relevant and should not be discussed in this thread.
Why is this topic focusing on the rule language?..
But I get concerned when I see a discussion about which language to use for rules, insted of focusing on creating a UI for drag and drop rules. Then the actual rule language doesnt really matter for the common user.
But I find it strange to discuss something which isn´t a main concern, when other things such as UI´s are in a desperate need of a makeup.
If the UI´s can take care of the rule process like a drag and drop, then it really doesn´t matter which language beeing used behind.
Discussion of which language to use for rules is, in my opinion, a high level discussion, which belong beside any other discussion of how to make opehab better for new/ordinary users, or discussion of whats wrong with openhab.
But question is, if this is a major concern above other things…
I´m concerned that high level discussions may drive even more potential new users away, rather than trying to welcome them at their level which, in my opinion, is highly needed.
trying to change the focus to where I believe would matter most for openhab in general.
I could be wrong
Its me trying to put the priorities into perspective.
But it can also become a signaling problem
Because they´re already advanced users. They dont struggling trying to comprehend openhab.
All of these outright state or imply that we shouldn’t be discussed in this thread. I vehemently disagree and fully expect that stuff like this would and should be a part of the “Is openHAB Dying?” discussion.
They might be making a bet that the cost of migration will be great enough that most users will just pay the money to avoid that hassle. Couple that with the fact that, as mentioned, openHAB isn’t even part of the conversation in home automation communities outside of this forum. I’ve seen a bunch of “Home Automation Comparisons” that all include HA and none of them even mention openHAB. In maybe one post out of 10 on the smarthome and homeautomation subreddits mentions openHAB as an option. This is what I mean by our community not being good at marketing. Those HA users may get fed up and want to leave but wouldn’t even know about the existence of OH because we are not part of the conversation.
I posted another thread already and will repeat it here. If you are at all active on reddit or follow the internet taste makers, please contribute and speak up in the comments. Let the wider community know that we are here, we are active, and we are a viable option.
I believe David already has one written and it’s awaiting approval for merge. One of the improvements that we should see from this big merge of ESH and change of the build system is a much easier getting started building bindings process.
w3schools is a much larger organization with far more people contributing to their tutorials. We do what we can with the people we have and that means not reproducing documentation that exists somewhere else. But don’t confuse bindings with Rules. They are totally different things.
My assumption was hass.io was akin to openHABian. Maybe I’m wrong.
Unfortunately, there are two places where this analogy fails in the OH context. First of all, there is no authority to say what the developers actually work on. So there are no army commanders to direct the engineers to start work on that. But, that also means there is no one in authority to tell that one guy working on other areas he can’t do that.
Honestly, I don’t believe they are. It takes a huge amount of time to monitor threads like these and I suspect most of the developers prefer to spend their time writing code instead. That’s why I get frustrated with “OH should do it this way or focus on this first or else I’ll quit/you won’t attract new users/the apocalypse.” By the time these sorts of comments get made in these threads, what few developers who were following the thread have long since abandoned the thread. It’s just users who are strongly expressing their opinions at each other.
Probably not. Deprecating Rules DSL doesn’t mean eliminating it. It just means that it won’t be the language recommended for use any more. IMHO we cannot afford to force all current user of OH to rewite all their Rules. The developers I know working on this agree and appear to be working towards continue support. It just might mean you have to install something separate rather than support coming with the base install in OH 3.
I’m not arguing that @crxporter is making a bad decision, just providing clarity about some alternatives and options for future readers.
I find a solid backup and restore process and/or running a separate development instance of OH is freeing in this regard.
Don’t necessarily take Lewie’s and my responses as arguing that you are making a mistake or a bad decision. But these posts persist forever and future readers may come to a different decision based on the additional information we provide.
All OH releases are essentially “At this point in time we are aware of no major breaking bugs.” The only difference between a release and a milestone is the release gets a little more testing immediately prior to release. Based on my experience, the milestone builds are no more or less likely to contain errors than the release. And the closer the milestone is to the release the less likely it is to have problems. I would say that 2.5 M1 is exactly as reliable and usable as 2.4 Release and do not hesitate to recommend it’s use, particularly if you use MQTT or Zwave as there were bugs discovered after the 2.4 release that got fixed.
All new development takes places on the next version. Since 2.4 is released, all new development, including bug fixes, takes place on 2.5. If a major bug is discovered, it might be back ported to prior versions of OH, but I’m not aware this has ever happened.
And for OH 3, this too is being addressed, or at least talked about. There are discussions about separating the bindings from the core in a way that would let us choose which version of the bindings we want to install rather than needing to manually install or wait for a new version.
Err…I think you got some fundamentals wrong and that mislead you in choosing which software to run.
As a user, you don’t neither need to mess with Github nor Maven nor wait for another release.
You can simply choose to install milestones or snapshots, just see the install docs how to do that.
We recommend to use stable releases but that does not mean we recommend against using milestones (or even snapshots) in your production.
Milestones are stable to run and freed of first/most obvious bugs.
There’s nothing wrong with using them if they work for you.
You just need to be aware that they’re betas of the new version so there might be compatibility issues you might hit when migrating there just like there can be breaking changes when upgrading between releases.
You can also choose to run snapshots or even combine a release or milestone with the snapshot or custom version of one or more bindings if you think you need the latest version of that.
Again, no Github or Maven involved.
Just like a number of people to complain about rules syntax I think you just should have asked sooner …
My reasoning for having to rewrite my rules is not completely to get away from the “old” rules. It’s also going to be caused by evolution of my house, abandonment of the OH 1.x insteon binding, and the desire to add more into my system.
Also if the DSL is depreciated there’s very likely going to be new features of whatever causes that depreciation… At that point I assume users will either run two sets of rules: old stuff in DSL that they are reluctant to change and the “new rules engine” (which is still experimental?) with new features.
Are there even more ways to program rules? The rules link on the “introduction to openhab” page goes right to a document on DSL rules in Xtend. There is no mention of any other language there. There is a link to JSR223 Scripting on the sidebar but honestly I didn’t know what that meant until the last couple of days reading this thread… “JSR223” looks to me like another layer of OH that I don’t fully understand and isn’t well enough used in the forums that I feel like there will be decent support. Everything seems so complex to someone like me who hasn’t used JSR223 and too often you have to know what you’re looking for to find what you’re looking for.
I did ask sooner here. It was my first day according to that comment. Two comments down I was trying to install his fork of the homekit binding (I tried this for about 2 weeks actually) with no success. At that point I didn’t know where to get help - now I know I should have come to these forums.
Even installing a beta binding is something I’ve never gotten to work. I’m sure I’m doing it wrong but reading the forums I decided I may be interested in the apple tv binding which has a link to a jar file and I’m only about 75% sure I know where in my system to put that jar file.
My experience updating from 2.3 to 2.4 was that it broke random of my insteon switches each time I restarted. I eventually got my .items files cleared up and cleared the catch which cleared up my issues after about 2 days of struggle. The risk of another upgrade issue does not (for me) outweigh the benefits of dropping a bug on mqtt or being able to use experimental bindings…
Don’t get me wrong, OpenHAB is a great program and can do many things. At this point in time (May 3, 2019) I am planning to move on in the next few months sometime. The main cause of concern for me are the downfalls of the Insteon binding and my own personal unwillingness (or lack of time) to commit to learning more about OpenHAB. Check with me in a couple more months, there’s a huge chance I’ll have changed nothing.
Jerome has started a thread to begin to address the documentation problem and over the next six months or so I expect that we will see many more postings showing those languages instead of Rules DSL. I’ve a task on my plate to add at least one JSR223 version of all of the Design Patterns (where applicable).
The new developer documentation has been merged. It will be amended once more when the migration is complete (which should be in a few days).
@Confectrician I’d say we rename Rules DSL to “Legacy Rules” and put all related documentation in a “Legacy support” section. I’d really not want any new person coming to openHAB to write Rule DSL rules. But yeah have to be decided on the corresponding thread.
openHABian’s counterpart, in Home Assistant, is Hassbian. It’s a ready-to-burn disk image for a Raspberry Pi, containing a tweaked version of Raspbian and a pre- partially-installed version of Home Assistant (in a python ‘venv’). The counterpart of openhabian-config is hassbian-config. All-in-all, very much like openHABian.
Hass.io is unlike anything I’m familiar with in openHAB. It is available as a disk-image for an RPi but, unlike Hassbian, employs two Docker containers (one is Home Assistant, the other is a hypervisor) and a bare-bones Linux OS.
The goal is to shield the user from the Linux command-line and make most everything GUI-based. One of its strengths is the ability to add a major functional piece, like Influxdb, Grafana, nginx, etc, by simply selecting it as an ‘Add-on’ from the ‘Add-on Store’. There are official Add-ons and user-built Add-ons available. Configuration is reduced to filling out a form and, presto, you have nginx running.
The hypervisor can do maintenance chores like create ‘snapshots’ (backups) and even perform automatic upgrades.
In a nutshell, Hass.io and its Add-ons are customized Docker containers. Naturally, anyone who knows their way around Docker, and a docker-compose.yaml file, can duplicate most of this functionality. However, Hass.io doesn’t require you to know anything about Docker.
Personally, I don’t run hass.io but, according to the last published statistics (many months ago) at least half of the community uses it. My own impression is that it’s a clever concept but can be quite taxing even for an RPi 3B. Users who love its convenience but not its lethargic performance, migrate to installing it on a micro PC (like an Intel NUC). In other words, Hass.io is also available as just the two Docker containers minus the bare-bones Linux OS.