Continuing the discussion from Is OpenHab Dying?:
Say it ain’t so. One of the reasons I and others chose OH over HA is that it is NOT a software appliance and that you can get under the hood when needed.
2 Likes
In openHAB it is almost never an all-or-nothing. Just because OH offered a software appliance deployment doesn’t mean it would stop offering openHABian (assuming openHABian didn’t become the appliance), apt/yum, Docker, and manual installation options. But for some users, even the conveniences offered by openHABian are two low level fiddling than they would like. A software appliance would be to address those users. Note however that absolutely no one is working on this and the maintainer of openHABian is hostile to the idea so I doubt we’ll ever see this happen unless someone not currently involved in openHAB volunteers to do it.
1 Like
Ha! Well…
It’s because it’s very tricky in the details and a HUGE workload to seamlessly merge UNIX, Java and application level code into what looks like a monolith to users.
And basically you’re right it’s still my conviction that trying to shrink-wrap all of openHAB’s flexibility into some point-and-click adventure is impossible so not worth attempting in the first place.
But to be frank, openHABian has already silently been moving somewhat in that direction with a refactoring that allows for unattended install, uninstall and configuration of every component in addition to its interactive mode and I wouldn’t mind anyone to contribute more of such stuff to openHABian to make it become more of a toolkit. It’s just that I don’t want to have to implement all of that myself.
So not outright hostile, just too busy and left alone with that biggie.
Feel free to call me lazy but after that watch your back and smart home’s activity 
.
If you’re a user however that doesn’t need or want all of that flexibility you might be willing to sacrifice/limit insight, options and applicability for the sake of an all-GUI UX.
Fasten seat belts Rich you’ll never guess what I’m busy with these days:
building a software appliance based on openHAB.
It’s a commercial Home Energy Management System appliance and even on sale now.
All-German only but if you’re interested, here’s a free demo (runs on Raspberries).
It’s still openHABian and not exactly the same as an OH appliance but technically, it’s an increasingly blurry line. You can still creep under the hood if you like to but you shouldn’t really
(any user in a commercial context would of course be losing support, there’s no business model to cover that - this actually being the prime reason for my development move …
… and Rich you would probably die in agony dissecting the inner builds, but we still need you 
).
PS: openHAB is on FOSDEM’23 and so am I tomorrow with this short presentation.
6 Likes
I may have used too strong a word with “hostile” but you do push back pretty hard when ever someone says “let’s make it an appliance!” I’m going mostly on that.
I’ve somewhat followed that work a little, at least here in the forum (I don’t read German so can’t really follow too closely on the main site.
HestiaPi does something similar I think, only less well developed. It’s all rules and executeCommandLine/Exec binding for configuration and maintenance stuff (e.g. upgrades) but overall it’s kind of the same; using OH to build the appliance as opposed to making OH and the stuff around it the appliance.
Good luck on your presentation!
1 Like
A docker appliance is more or less a complete appliance. Itis even more locked down/more difficult to get under the hood for “normal” users than an old school software apppliance. So I will argue this is already available.
I myself has installed it in a LXC and attached the LAN NIC bridging it so the LXC container has a LAN IP (for discovery) and just following the simple installation guide. It is not as fiddle free as Docker, but I can move it around in my LXD servers, copy it, spawn a new AND I have full under the hood flexible access.
Much of the problem is that the definition of ‘software appliance’ is blurry and different people understand slightly and sometimes significantly different things about what that means.
The main reason for my and others’ ‘hostility’ is that OH by its fundamental design is the opposite of an appliance how I understand it: an all-GUI software that you just flash to some hardware that then lets you do everything it is capable of by simple point’n’clicking.
But any user to ask for this at the same time is implicitly also telling others - devs - to build it for them, and devs know it cannot be done to the complex existing building that openHAB is. Not even with a lot of effort and never will it become as good and consistent as a system that is designed from the ground up to work for a specific task like say OSMC is for media playout.
Let alone in comparison with another home automation system and let alone while attempting to keep its flexibility. A good home automation system has to be flexible, but a flexible home automation system can never be an appliance. Look at the market and count those gone that believed so.
Even if we wanted to and managed to build such an appliance, right the first questions - usually from the same people - would be “how do I do XXX now, where’s the checkbox for that ?”.
Long story short, don’t ask for openHAB to become an appliance.
To me, that’s really like the mother of all XY problems.
[ yes I notice the irony of being anti-topic in fact now as the OP asked for the opposite ]
Ask for specific functionality instead, describe it well and explain your intention and use case behind, and we’ll check and see what we can do for you.
1 Like
Do not get me wrong here, because I agrees. However even as you say, people has vastly different oppinions about what a software appliance is. Software appliance is also a stupid wording, because basically this is one-click installer to vastly different operating systems, whereas removing the software and just call it an appliance, is basically what the docker image is. However some will likely disagree with me regarding what an appliance is, so enough about that.
The docker image provides a way for anyone to start using OH regardless of their skill level, so the essence of the question is basically already covered. 
Well, it requires any user to know to handle a base OS to provide the basis for Docker in the first place.
openHABian is a software appliance in that sense, too, easier to handle AND it still allows for creeping under the hood very much.
Now that is why I’d agree that “the essence of the question is basically already covered”.
1 Like
Based on my experience on this forum, I disagree with this statement. I’ve helped so many people with a low skill level on containers and low understanding on what running software in containers even means understand why they can’t do something (e.g. Why can’t I reboot my machine? Why isn’t Python installed?), why they can’t find their files (What do mean, what’s a volume?), weird networking issues, etc.
Docker is great if you know and understand how it works. If not I’ve seen no end to problems from users, all stemming from the fact that they don’t really understand what containers are for and how they work.
If that is the experience level people expect to be able to dabble with home automation, so that a docker container is to complex, it does not matter which eventual appliance you make. Then there is no appliance in existence that will do.
I agree with Rich. I understand the concept of containers, but since I’ve never used Docker it might as well be a foreign language. I’m sure I could figure it out, but right now I don’t know what to do with a Docker image or how to troubleshoot it.
Of course, that’s not specific to Docker–it’s any complex task or system. Riding a bicycle is only easy after you figure out how to ride the bicycle.
I don’t know what this means, but it feels condescending. I don’t think that was your intention, but “knows how to use Docker” cannot possibly be a prerequisite for “dabbles with home automation”.
If having a high degree of technical expertise and knowledge is a prerequisite, then home automation is doomed as a consumer technology.
I think this sentence captures things nicely. It’s very difficult to make anything that serves beginners and advanced users equally well. A flexible/adaptable system is typically complex by necessity, which makes it hard for new users to wrap their heads around it (openHAB, Home Assistant). A rigid system quickly becomes limiting and dissatisfying for intermediate/advanced users (Google Assistant, SmartThings).
Personally, I’d like openHAB to have a “Beginner” mode that limits what you can do, with an option for users to unlock Intermediate and Advanced settings/features at any time. I would expect most users to only be in Beginner mode for a few days or weeks before changing to Intermediate. The point is for users to recognize and understand that some tasks require more expertise/skill/experience, and to decide for themselves when they want to take the next step. It’s the difference between “I can ride a bicycle on flat pavement” and “I can ride a bicycle down a mountain trail at high speeds”.
(Rich, I don’t mean this as a replacement for the Getting Started tutorial, but as a complementary experience.)
1 Like
I’m not wedded to the tutorial. If something better comes along, please replace it! It’s already out of date in little ways that needs to be addressed and I don’t have time to update it right now. If something like user modes came along that is well implemented (don’t forget this was tried before, we had such a mode in OH 2.x where Items were automatically created and hidden from the end user; it was a disaster) I’m all for it. If we can eliminate docs that means we’ve improved the end user’s experience tremendously!
1 Like
You are correct. It sounded worse than intended. What I meant is that there is no appliance out there which is plug and play or just power on. How can any project make a solution which is? There is pre requisites to account for, always.
No user chooses OH over home assistant if they are not ready to get their hands just a tat dirty. This is integrations after all. However I disagree that the future of open source Home automation looks dim.
What I meant was simply put, that Openhab does not work if the machine that runs it, has no network config, or if the user has choosen unsupported hardware architecture. In order to use it as a new user who ahs never seen it before, you has to read the docs. Appliance or not. There are enough tutorials that covers easy to follow, not-much-need-to-understand, guides of installing the docker engine, imprting the OH image, and spin it up. However as with everything, then there is no appliance that will solve the need for learning the eco system and components. So helping new users with docker, or virtualbox, or how a Raspberry PI works, is just part of the game. However I stand by my comment, that to start doing home automation, you has to have basic understanding of protocols, networking and interactions between devices.
Actually wouldn’t it better to have a “Beginner Mode” that limits what a “Beginner” is requited to do. Like automating the process of adding devices to openHAB. For example why require a “Beginner” to setup channels manually for a Insteon or Kasa switch they just added to openHAB. The bindings know what channels the device has so check boxes and a button should be sufficient to enable the ones they want to use or better yet just enable them all.
You could extend this idea further with the ability to create MQTT Things for devices with a click of a button with simple Q&A to associate it to cmd and states, broker and bridge. But that terminology would be absent from the “Beginner” mode point of view.
A “Beginner” will not have hundreds of devices they will start with two or three. The frustration they likely experience will either turn them off of home automation or send them to another platform.
Those other platforms are unfortunately most likely propriety off-the-shelf solutions. The more the propriety solution user base grows the less likely open hardware will continue to be developed that can be used with platforms like openHAB which in turn result in their demise.
Iris by Lowes was a great product that was plug & play unfortunately it was run into the ground by its poor management and lack of promotion.
Consumers only buy what they are told they need to buy. Even though people can download openHAB free of charge you got to ask yourself what is openHAB trying to to get people to “buy”.
I think it’s important to stress that you’re talking about “software appliances”, and not appliances in general. That may be obvious to you, but from what I understand of software appliances, it’s an important distinction. Honestly, I kind of hate the term. It’s more confusing than helpful, because it doesn’t really line up with the general notion of appliances (e.g., kitchen appliances, laundry appliances).
Note that in your previous post you didn’t say “open source”, so I thought you were referring to home automation in general. I don’t think that home automation (open-source or in general) looks dim.
I assume you’re again referring to “open source home automation”. Otherwise, I don’t know how to explain the vast number of people using Alexa, Google Assistant, Homekit, and SmartThings without having ever used the word “protocol”.
That’s kind of what the Simple Mode in OH2’s PaperUI was trying to do, but as Rich noted it dumbed things down way too much. More than that, I think it prevented new users from learning the relationship between things and items, rather than coaching them so that they could progress to more challenging tasks (which would be my preference). Again, that’s not easy to do, and I commend the PaperUI designers for trying.
Note that there’s a difference between a beginner in home automation and a beginner with openHAB. The latter group tends to show up with a bunch of devices that they were using with another system. They are the trickiest to help, because they often want to jump right into things that are quite challenging (due to having the equipment already). They are also the ones who would be most likely to skip the Beginner mode and attempt to use MQTT right off the bat.
I actually think it’s the other way around. openHAB depends on the proprietary systems to exist, because that’s how most people get started with home automation. The concept of home automation is decades-old, but the average consumer didn’t care until Alexa, Apple, and Google made it really, really easy to turn things on and off with voice commands. openHAB doesn’t offer that convenience.
We’re the next step you take after feeling limited by those other systems. And since we’re open-source, we’ll only meet our demise if developers decide they have better things to do with their time. I don’t see that happening any time soon.
If they could be “just added to openHAB” they would be. The nature of those technologies (I’ll throw MQTT, HTTP, Exec, and Serial into the mix as well) make it impossible for OH to just add them.
So in your “Beginner” setup, none of these technologies would be supported at all. Is that a better overall experience? I’m not so sure. Users come to OH with the technologies they have and saying “sorry, that’s an advanced technology, you’ll have to prove to the system you know what you are doing before you’ll be allowed to integrate those” is not going to be well received.
We don’t force manual config because we are mean. It’s just not technically feasible.
And in the end, you’d just have a wizard that does the exact same thing as the form. And MQTT does support several MQTT topic standards that it can just detect and add the Things for you, no configuration necessary. But the topic structures and messages have to follow a standard. If you need to use an unsupported standard or to create your own standard, that’s fine too but you’ll have to understand what you are doing to make it work.
That’s up to you. We have at least two places in the docs that states exactly this. But if you want to jump in the deep end you are welcome to try. I doubt any of us even so called experts got started that way though. We all started with a couple devices with a relatively simple to integrate technologies. It was a couple years into my home automation journey before I felt confident enough to even start to mess with MQTT. It’s used as the Advanced example in the Getting Started Tutorial for a reason. It’s an advanced technology. And as the first few sentences of that page read:
Some bindings and technologies simply do not support automatic discovery. These technologies tend to be the most complicated to understand, configure, and use. You the user will need to have at least a working understanding of the underlying technology in order to be successful.
It’s an integration platform. Bring what you have or what you will. We’re not going to tell you what’s best for you.
And it broke things when moving from simple mode to “real” mode. I despised simple mode because of the huge mess it made.
But everyone’s two or three initial technologies are different, and so are devices within those and once more their configs, let alone use cases.
OH devs cannot create preset configs for any such combination even if we restricted ourselves to the most common ones - there’s simply too many options.
Where this can be done it already is done to the extent it is beneficial to users, like in the semantic model.
Plus it’s mostly impossible for any developer to create such an universally applicable, working config as he would need to have the devices available for testing. This is hardly possible only when you restrict yourself to a harshly limited set of devices and a minimum of use cases (if at all).
Iris was a purpose-built appliance with a single use case hence very limited scope, my energy management appliance is similar in terms of scope (see link above).
These appliances you must not compare to a universal HA system like OH but even with those it’s really tough to get plug’n’play to work reliably on devices customers bring in with upfront-wise unknown hw,sw and configuration details. There’s just so many settings you need to provide to match the details, and the more of those the more potential for failure.
Nope. This is possible to some extent for some of the simpler technologies that allow for full automatic discovery and autoconfiguration eventually, but there’s many subsystems where this does not work.
And MQTT is right the counter example where this will never be solved to satisfaction. Likewise Modbus which many HVAC+energy devices use (and I in my appliance a lot). Rich just mentioned more of those more universal technologies.
For all of these and use cases when customers are unable or unwilling to dig into the details of the application but nonetheless expect the appliance to “just work” with a default config on initial boot that will not work. That’s like the holy grail of auto configuration management, it just does not exist and any dev will die trying to build it.
But those are perfect examples of what this thread is all about. If you wants the “plug and play” edition, it ONLY runs on a specific platform (is that not comparable to OH which as a “plug and play” only runs as a docker?). And if you wanna do more than just the simple things, you needs the hardware appliances (The google nest hub, the Amazon equivalent or the Apple devices). For anything where you can set it up on something existing (some hardware you just happens to have in spare), then there is only custom things like Home Assistant or OpenHAB. However you are correct though that the big Cloud solution does covers the non tekkies. I buy that argument. I would argue that you will only rarely then consider anything but “what can just be solved with an app”, such as OH anyway.
All this debate just proves your very first post: That everyone thinks “appliance” differently.
I think we have come a long way towards fast and easy start with the Docker, OpenHABIan and the officiel and unofficial SNAPS. Call them appliances or not, but the easiest for a non tec savy, is the SNAP or OpenHABIan.
This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.