Many add-ons support devices from dozens or more vendors. Many vendors support devices that require different add-ons to work with. I don’t think it’s as simple as that. But again, if you think you have a solution, great! Lets get some PRs going!
Having just read through this thread/discussion and as someone who has evaluated HA (and continues to periodically evaluate it), but has settled on OH I would like to share a few thoughts.
Taking a high level view of a Smarthome, it is generally agreed that there 3 main functions; 1) Monitor, 2) Control, 3) Automate. To this end I believe most new users are focused on Monitor and Control. They wish to consolidate any number of standalone apps into a single app or system that is easy to setup and use. This is where HA excels in getting a user connected with their devices through automatic discovery and populating a rudimentary dashboard with almost no involvement from the user being required. Unfortunately OH falls flat in this regard and for a new user, as others have stated and I have recently experienced, this is the primary appeal of HA. Technical issues aside for the moment, this a major hurdle for OH that must be flattened in some way, be it a wizard or whatever, to keep a new users interest and begin to show the power of OH.
As an OH user from early days of 2.x, IMO and the reason I stick with OH is the ability to add complex automation using text files/scripts and perhaps now with UI (although I haven’t tried any truly complex automations with UI rules). In this regard HA falls flat IMO requiring a YAML implementation that has thus far escaped my ability to master sufficiently to replicate what I can do in OH. This is a key differentiator for OH vis-à-vis HA and something that should be highlighted. To illustrate my point, I am in my late 60’s and recently was having a conversation about IoT and the Smarthome with a few of my technically savvy nephews who are in their late 20’s. They proceeded to show me their HA smarthome implementations which was basically just consolidation of apps for single point monitor and control. When they were finished “showing-off”, I showed them my OH UI/Dashboard eye candy in all its splendor, then I told them that I rarely ever use the UI because my home is mostly automated. As I went into detail about the complexities of some of my automations it was a total eye opener for them, but the sad truth is they had never heard of OH.
This raises the next question in my mind as we begin to think about marketing OH. Namely, who is the target market? What type of user and level of technical sophistication forms the target audience that will help build and grow OH going forward? Is it the total newbie or maybe someone who has a system on another platform, but has hit limitations in the platform or their own ability to master the platform and take their installation to the next level (ie automation)? As someone made a point that we should not be competing with other platforms as the total Smarthome market is expanding and is still relatively young, with plenty of users for everyone. If that is the case, then what are OH key points of differentiation that should be highlighted to the potential user through this marketing that will make a prospective user choose OH over HA or any other platform? As another person wrote, marketing something that OH can’t deliver is not going to be helpful in the long run and at the moment there can be little debate that HA has the advantage for ease of installation and getting up and running with little knowledge or skill needed by the user. It is a “perfect newbie system” in this regard.
So while OH developers and maintainers take on the task of implementing some sort of auto-discovery/wizard for a future OH release, should OH not try market what it does well? As a starting point I have listed what I see as some key differentiators that keep me using OH, but I’m sure there are plenty more.
-
- Choice of multiple UI/dashboards (eye candy)
-
- Ability to “easily” create a very polished, pro-like UI/Dashboard with Main UI (more eye candy)
-
- Ability to create complex automation rules/schemes with UI/scripts in choice of multiple scripting languages
-
- Rigorous/standardized process in creating updates and adding new features
-
- Semi annual releases with monthly milestones
-
- Stability and security
-
- Optional but Free OH Cloud Connector
-
- …more
So what is the best way to get this message out? I’m not a social medial person, I have no accounts on social media, but all of my nephews and nieces use multiple social media platforms so if OH doesn’t have a social media presence is that something that should be considered as well as other avenues?
6 Likes
You can write parts of rules in the UI using any of the supported rules languages so there is no limit to the complexity supported.
Does HA have something akin to our Rule Templates? If not that could be a differentiator too. Not only does OH support complex automations more easily, in some cases you don’t even need to code them yourself.
There is a Subreddit. The Facebook page is German only. I think there’s a Discord Channel but I’ve never used Discord so never tried to look. Instagram doesn’t really feel like a good fit. OH is on X but not super active (and I wouldn’t get an account over there before Musk took it over let alone now).
1 Like
To the best of my knowledge they do not have templates in the way that OH does. They do have a UI rule builder, but in my experience it is very, very limited.
Of course it’s a business. They probably didn’t mean to be one initially but now they have a successful product backed by an incorporated company and several core developers on the payroll.
That’s what you ultimately choose, in fact - an open-source product backed by a for-profit company or a free software whose features which cost money are handled by a non-profit.
2 Likes
It is already here. please have a look (scroll down to USPs):
Based on your post I have updated the list.
I am thinking more of (a) complete start to finish tutorial(s) to realise a concrete use case, (each) devided into three chapters, instead of a “general” getting started guide. Therefore I need concrete bindings and add ons to be installed necessary for the individual use case. But nonetheless I would also support you in a general getting started guide. And I already have one here for openHABian as part of a tutorial for an openHAB appliance I am currently working on.
Something like (just an example, to find good use cases showing the advantages of OH will need some brain):
The story (use case):
Susan loves watching a good movie with her friends in her home cinema. She spend a lot of money for equipment. But with more and more devices to control she got frustrated. She bought a Logitech Harmony Hub to control the soures, the projector and sound system already and some HUE lights she controls via the HUE App until now. But she would love to have everything connected in a way that she just needs one button to switch between scenes like receiving her guests at bright light, starting up the equipment as the light gets down a litte bit, fading the room light completely while the HUE play behind the sofa turn to a dark red as a background light for the movie, dimm the room light up and down if a pause is necessary and having a sunrise effect while everything is switched off.
One of her frieds offered her a little old Windows PC, she could use for more automation.
What you need
Home cinema equipment already connected to a Logitech Harmony Hub
At least one HUE light for the room and one for the background light connected to a HUE HUB already
PC (Windows based)
Chapter 1: Installing OH on a Windows PC
…
Chapter 2: Install bindings for Logitech Harmony and HUE, create things for the devices to be controlled and connect items to the channels for each function they offer
…
Chapter 3: Create rules for the scenes and a simple GUI to activate them
…
By deviding the showcases in these chapters the advantage of a concept of several platforms, bindings for different technologies offering most identical items for similar functions of different devices can be shown and with each new showcase we could add a new platform, a new technology/binding, … to a “menu” the user could choose from like in a restaurant. You can order a complete meal by following the tutorial of one use case completely, but can also decide for a starter (platform), choose a main course and some side dishes (binding and add ons) and as a desert implement your desired use case in form of rules and GUI form different tutorials.
1 Like
The best would be a little set of fake devices placed on a webpage allowing some sort of interaction. So you could trigger your motion sensor by clicking it, having a “HUE light” that shows how it is dimmed up and down and changes colors, … Then you could open it in a parallel browser window to interact.
I use frontail in a webframe on a page in Main UI to have it available on every terminal in the house in case something does not work as expected.
1 Like
Why would Chapter 1 differ from one show case to another? Currently this sounds like 80% what I am working on.
Which is not a bad thing,… Gives us the option to save work if it makes sense.
I think its wrong focusing on windows based openHAB.
Two reasons:
-
People are moving away from PC´s and towards mobile devices, smartphones, tablets etc. Alot of “smart home” devices comes with smartphone app today.
-
Windows based PC´s are expencive to have running 24/7. They use quite alot of power. And sometimes they´re even noisy.
The dilemma is, most people know Windows alot better than Rpi/NAS devices or simular. So it may take a huge job to convince them to use another platform. Lots of them will give up long before you even would succeed. They´re scary of an Rpi… Its a green plate with “something” soldered to it! This is where to convince them to buy a cover/case as well. But they will wonder… Where the heck is the cover… Their window PC came with a cover/case just fine. Now I just want to run a smarthome, and I´m about to build my own computer…
For none techinal people, this is an absolute no-go. Now matter how well the smart system (platform) is.
Now try and convince the same people to buy an expecive NAS 
1 Like
As there are different platforms to run OH, different showcases should use different platforms just to cover the whole bandwidth. With the matrix of defined content per chapter i proposed, a user can then combine from several showcases his or her personal system. And with every additional showcase following this approach more well described varieties can be used.
First there may be (should be) a showcase based on openHABian and z-wave, e.g. With the next showcase based on a pure Debian and zigbee you can already follow different ways to score the goal of the described use cases, like taking openHABian from the first showcase and combine it with zigbee to get to the necessary items you need to implement the use case described in the first showcase by writing rules and designing a GUI for it.
I do not focus on windows at all! Please read carefully. This was just one example of a showcase to demonstrate how they would look like, following the approach of chapters with a defined content and “Interfaces”, so that a user can combine a platform described in one showcase with a technology used in another showcase to implement a use case from a third showcase.
So, here for you another example, you might like more:
The story (use case):
Peter built his PCs by himself since he was 16. He does not mind plugging parts together although he always avoided to solder something. He bought a Raspberry Pi last year he installed in a nice case, now standing in his living room, used as a media server for his not so smart TV. He already has some rollershutters automated via Homematic. To save energy he loved to close the rollershutters as soon as it gets dark, but hates it to have them closed if he has a party with friends.
He thinks about buying a second Raspberry Pi do integrate entries from his Google calendar to the rules for the rollershutters.
What you need
Raspberry Pi, SD-card, case and power supply
Homematic CCU with already attached rollershutters
Google account
Chapter 1: Installing openHABian on a Raspberry Pi
…
Defining concrete showcases will need some time and effort, so please noone should take any example as “the most important and first to write showcase” to criticize because of the choosen platform, the used technology or the use case to realize. Therefore I will not answer any critics on Windows, Debian, openHABian or z-wave, zigbee, Homematic, …
1 Like
This is great! I can add:
- I love the old Sitemap / basicui. I have never been good with graphics / eyecandy stuff. I just want something simple, quick and easy for UI building and the old Sitemap is perfect for it. I can very quickly build my phone / web interface, and it’s also file-based
- I love the fact that I can use Visual Studio Code to fully manage all my my openhab settings, rules, items, things, persistence, etc. and not forced to use UI stuff to manage them. Using VS Code is just such a joy.
- No telemetry of any kind
@oliver2 not sure if these are already on the list.
I would suggest that more openhab folks join r/homeautomation - it’s a decently busy area but it’s practically all home assistant (well, just about every home automation groups / forums out there are all about home assistant).
1 Like
I know it was just an example. Im was trying to state, why windows can become a problem in a marketing campaign.
And its a dilemma, cause I have no good/better options to suggest, since they all require somekind of knowleged, which is beyond what most users knows.
Which goes back to: our target users aren’t the average people.
Our target users are geeks who love tinkering with technology.
The average person won’t obtain and setup a dedicated computer (be it Windows, rpi, linux) dedicated to running a home automation system 24/7.
Unless it’s a blingy / flashy “turnkey” black box solution like Google Home / Nest, Alexa, etc. where you’d plug it in and set it up with a guidance from a phone app and say “Discover my devices!”. This is “high tech” enough for the average person. In fact, someone who does this would already be thought of as a “geek” by the society
2 Likes
I think that used to be our target user in the past.
OpenHAB made so many progress that we can easily address less experienced users.
1 Like
We’re not quite there yet. As @John_Siemon said above, why not market OH to the more technical people who can comfortably use openHAB now. Right now these people may not have even looked at openHAB either because they haven’t heard of it, or comparison sites out there have made OH sound so unfairly inferior that they haven’t bothered checking us out.
Sorry, I disagree. This even reinforces our situation/problem that openHAB is perceived as a home automation solution for geeks and nerds and will make it even more difficult for us to get out of that niche in the (near) future.
One approach that has worked well for me in the past (and not so well for others so be forewarned) is to create a new thread in the Development: Docs section of the forum for the first rough draft of what ever you are working on. You can request and I or one of the other moderators can convert the first post into a wiki so more than one person can edit it, though in practice that rarely happens.
You can start with a post and an outline and fill it out as you go. You’ll almost certainly get feed back.
You don’t really need a Thing for that though. You can achieve that with just Items. The Thing’s purpose is just to show how to connect the Channels to Items.
A third reason is the overall experience on Windows is not as good as Linux when it comes to installation, upgrades, etc.