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.
TL;DR: OH is too much for me, I understand Javascript better.
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.
I’ve enjoyed my time here. And I haven’t left yet, mostly because I haven’t had time to do the reprogram switch lately. I’m headed for a setup based mostly in Node-RED. That’s an environment where I’ve learned to thrive. JavaScript caught on really quickly for me, I like the flow setup, and there’s not much overhead in the system…
I know there are arguments against all of the things I just said. I very well COULD learn to write a new Insteon binding but I’m not about to learn Java programming just to stick around here. I’m planning to move to Insteon-MQTT which could be integrated into OH but again, JavaScript and flow-based design of node red is what’s clicked. I don’t have any desire to build JSON parsing into my OH setup for 35 Insteon switches, mostly because I understand how to do it in JavaScript but have no idea how I would get that into OH.
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?
To 2) A system only seems complicated as long as you don’t know too many answers yet… As I said, maybe the freedom to use JavaScript already helps you?
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.
Bingo!
Just to be clear for future readers, you can write rules in OH in JavaScript right now. And in the future, it will be one of the “default” languages instead of Rules DSL.
Write JSR223 Rules using JavaScript would be a good option. Though the JSONPATH Transform and MQTT2 binding should be adequate in most cases. But if you are comfortable in JavaScript, I is (and always has been) an option.
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 …
@rlkoshak very good points as always. I need to point out that when I got started with OH I didn’t know that JavaScript would be my favorite. My previous programming experience at that point was HTML in junior high and MatLAB in college. I had found shortcommings in HA and was moving to OH so I used the xtend rules as they are well documented in the forums and that’s where I was learning things.
From there I started “branching out” into the openhabian optional installs, found Node red, and got hooked. JavaScript didn’t “click” for me until after having a full setup in OH.
Obviously if someone is a JavaScript pro they should use JSR223 rules.
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…
Future readers:
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.
You are fully right and we are on it. I have started a discussion thread to improve this for the future.
Improve the jsr223 doc and show users that there is more than rules dsl in the docs directly.
It’s always been there but until some recent pushes it’s always been nitch. In the past few months Scott, Lewie, David, and others have made great efforts to improve the usability and capability of JSR223. And the Next Generation Rules Engine, which will let us create Rules through the REST API (e.g. PaperUI) uses the JSR223 languages for custom code AND it both sets run on the same Rules engine. But in answer to your question, yes. JSR223 allows you to write rules using JavaScript, Jython, or Groovy. There are other external tools that aren’t part of the OH project that some users use as well, including NodeRed.
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).
So yes, for a time and even now, the documentation and usability of the JSR223 Rules are not as high as Rules DSL. But we are working to change that. And for OH 3, these will replace Rules DSL in those sections of docs. Like I said, none of this is really directed at you because given your path you are heading in the direction that makes sense for you. But a new user on this forum will not have the history or decisions to deal with and choosing JavaScript might be a good choice for them.
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.
So the goal of Hass.io is to create a software appliance. I’d like to see OH move in that direction at some point but there are clearly more important things to do first, and it’s a huge effort.
I think the main point everyone forgets that iot is in its infancy, jeez I can’t even get a Zwave double plug socket for the uk market. I feel it’s just starting to really boom, pushed along by the likes of Apple HomeKit, amazon Alexa and google home.
From a ‘normal’ (and by this I mean no offence, non developer type of person), they go and buy a hue bulb and an Alexa, then they get the bug… just like me, before long they are adding all sorts. Then it dawns… I’ve got an app for this and an app for that I just want it all together.
Ok, HomeKit does this to a degree, but then you have to have Apple TV/iPads to do very basic automations, the same goes with google/amazon. It’s not customisable enough and only really works for mainline big brand retail companies. So they go looking…
I started out with an rf light switch which led to a harmony hub to control my entertainment… now it’s pretty much everything in my house, even my tumble drier and coffee machine.
When I first started out I wasn’t bothered about overly complex rule engines and lovely gui’s for control panels, I just wanted something that could combine ALL my devices.
What I’m trying to get at is I chose openhab for 3 reasons only:
1: it supported out of the box 80% of my gear
2: it was easy to setup and get the basics working
3: it was stable
In my opinion if openhab is to continue to grow these are the 3 most important things to draw new run of the mill gadget guys in. Yes more advanced users may want new rule engines and more JavaScript, but the foundation and building block shouldn’t be ignored as this is what I feel stands it out from the crowd in the first place and the quality and selection of bindings is by far the most important as we all have different gear in the first place.
I feel like I’m moaning, but I’m not, I think openhab is a great platform, and I therefore want it to survive and grow. I will input as much as I can, which will probably be in spits and spats due to work, but I get a lot out of it and it’s free so will put back in where I can. If anyone’s watched the box set ‘Scorpion’ I feel it’s much the same, it just needs a bit more EQ rather than IQ.
Great news as the way it was worded from memory was that future features would be delivered (plural, more than 1) and did not name the feature/s perhaps the scope had not been defined at that stage. Of course written posts can convey confusion, so thank you for clearing it up. I have no idea if in the long run the move to a $5 a month cost is a smart or dumb move, it could go either way and I suspect it could take 1-2 years to know. My concerns would be the same if Openhab took this route. Push requests from entry level coders (I count myself as one of these so I mean no offence) that constantly change code are not the same as quality coders written by a limited number of users that fully test and refine code before it is pushed. I really do hope it works out as I like the fact that there is another package besides Openhab in case my goals do not line up with the direction that Openhab takes in the future. I am more than happy that my choice with Openhab is the better one just as I am sure you feel the same with your choice.
BTW congrats on getting into the list of fastest growing opensource projects on Github. If there is ever a way that both projects can work together please feel free to suggest it.
Yes true and also the fact that as home automation becomes more mainstream and popular the number of ‘noobs’ increases that do not know how to safely secure remote access. Only 6-8 months ago there were a number of HA users that had people hacking in and leaving notes to them that they were open to the world. The statement that the clouds for both HA and OH are “optional” is for some people I feel is wrong as they lack the skills or time to learn how to do it. My personal goal is to remove the need for a cloud which is why I love and hope to check out Habot soon.
I have never seen a single call for donations and that makes me feel comfortable that OH is not Dying and also the cloud has a number of times needed upgrading as it has been growing in use. All good signs.
Maybe you and others should check this first video out and consider subscribing to the channels and like the vids to say thanks for making the videos.
yoyoTech (Spoiler alert he likes Openhab and mentions HA in multiple other videos)
As I said, maybe the freedom to use JavaScript already helps you?