I think my suggestion is being misconstrued.
I’m NOT suggesting that OH be MADE INTO JUST a Matter Controller.
I’m suggesting that OH incorporate a matter controller in the Core package.
Then a new user would not have to install and configure bindings for basic use cases for the time when Matter has established itself as the defacto standard for Home Automation. The OH Matter controller would interact with the rest of the OH platform just like the Zigbee, Zwave, and other bindings do.
OH would continue to offer first class support for the “much more beyond that”
Well, if (not when) Matter will some day be the “de facto standard” (I highly doubt that) there will be a matter binding, and that’s it.
There will be a matter binding sooner or later anyway, and sure enough it will have autodiscovery, but you will have to install it like other bindings too.
WHEN Matter becomes the defacto standard (reasonable people can disagree with this) and 90% of the market and use cases are covered, making a Matter controller part of core OH makes good sense.
OH would be easy for all of those basic use cases that non-technical users want WITHOUT sacraficing OH support of other platforms, devices, and advanced use cases
No.
IF Matter becomes defacto standard, write a matter controller but don’t try to force openHAB developers to do your will. It’s nonsense to set Matter as a core preference as openHAB itself has a bus, that’s the core, Matter won’t.
and when? 2 years, 3 years from now? Will it really become the de facto standard? Even if it will become the de facto standard, the market share in the beginning will be extremely low compared to all legacy products.
Just to respond to this specifically about wizards, and sorry for the delay:
Features like “Add Equipment to Model” and “Create Equipment from Thing” are wizards of sorts, because they deal with multiple entities at once (fill out a form, have items and links created for you).
There’s a first-time user wizard, but it’s deliberately kept to the bare bones because it might annoy if you stretch it too much.
What I very much had in mind, though, is a wizard that could bootstrap your initial skeleton of a semantic model (at least the hierarchy of locations and such).
This could be offered when you go to Settings > Model and there’s nothing to show - you would have a button to start the wizard.
As for wizards that could go from discovering a Thing to using it (items, rules and all), I had this in mind too - we could import “packages” from the Marketplace which could define things, items, rule templates, main UI widgets, block libraries, etc., and then have wizards so a single form would create instances of all of these at once.
But it’s kind of off-topic from the title of this thread IMO, the discussion has shifted from “OH needs more marketing” (like, bi-weekly blog posts?) to “OH is too complex to use”.
excellent, then this part should go in a “Configuration Guide”, not in a “Gestting Started Tutorial”
or another option would be to choose the simplest rule language as an example in the Getting Started Guide and then leave other languages ffor the complete Configuration Guide.
IMHO this is questionable: step-by-step guides are great but for very beginners and for limited parts of the documentation, never seen a software (perhapes just those with billions of users like WhatsApp or Gmail) with step-by-step guide that cover EVERYTHING.
agree, what is there is there, it can be just moved/renamed to a more comprehensive “Step by Step Guides” section.
Still most easy and immediate rewards parts could be moved to a short Getting Strarted Guide.
Well, if one sees an easy Getting Started Guide using a Hue device “from zero to hero”, most users should be able do do the same but with the binding/device they have at home…
if not well, probably theiy are not a OH target user, and they should go better to Alexa/Google Home ecosystems…
you do not need questions at all.
With binding auto discovery, you can directly present a list of technologies found in the house (eg. Sonos, Hue, Google, etc.) and then let the user select which one they want to be integrated by OH.
Then in the some onboaring wizard, one can tell the users he has many other binding that can be discovered by country or brand that he can always add them later even if a specific technology does not get auto discovered (maybe asking some quick question like you suggest here)
A first version of binding auto discovery is in fact fast to implement, and can be incrementally extended to other bindings/services in later releases.
Also consider the fact that one can always add new tehcnologies in their house: with auto-discovery you will discovery immediately a new hardware, while if you stick to questions in the onboarding wizard, you should have to re-run it manually to find new useful binding to integrate your new hw
It is not as easy as you think, otherwise it already would have been implemented. As with my example for the Wemo devices, some bindings have to tweak discovery services, otherwise devices would not be found. Given this, normal UPnP discovery does not detect Wemo devices.
This is just one example, there might be more.
Good news is, that there is action going on with that issue/feature request, so we can expect something in the near future.
to implement an auto-discovery mechanism that covers ALL bindings, addons, countries, cloud services → very difficult / impossible
to implement a very first version of auto-discovery mechanism that covers those bindings that are discoverable by mDNS/UPnP and add UI support (onboarding wizard) → decently easy
(UI support in particular has been defined a “low hanging fruit”!)
I’have found this dangerous approach few times in OH:
aim design for “the perfect solution” > get different opinions in the github discussion > the feature get stuck > developers go away
I suggest maintainers group adopts a more agile approach and prefer basic implementations and contributions to start with, and let more complicated use cases for later
I did not say it will not work nor implemented.
Being involved in the github discussion, i had highlighted that „problem“ already.
I mentioned it here too, as with the first implementation, we might see only a subset of devices that could be discovered, but that would be a start. Once such a mechnism has been implemented, we can try to add more to it.
I agree, as everything not using mDNS would be out of luck, including everything that is cloud based.
The danger that I can see in that approach is that it might lead to the impression of everything not found by the initial auto discovery as being unsupported. IOW, if the system already suggests a few bindings, will the user look for more bindings by themselves?
That’s why I suggested a searchable database mapping vendors and/or products to bindings. I remember one thing I struggled with when starting with OH was finding out which of my hardware it actually supported.
That is not true. I like it, as it is, as a good resource for people who want to understand and do more and who already are convinced that OH is something worth investing more time in, as they see the payoff they can take from it.
I am willing, and as I already explained, I see an advantage in not beeing such a technical expert who experienced how far you can get without knowing too much about more than the concept of bindings, things, channels and items:
“Use Pi imager to prepare an SD card, put it in a Pi and power it up. Define some basic rooms in the semantic model. Install a binding for the most used technology, recover the first most basic device, add it as a thing, add an Equipment that binds the channels of that thing to items, repeat for some other basic devices. Install Astro-, Mail- and Google calendar-binding with things and items. Put items on a dashboard and define some interesting rules using these items in a combination over the bindings.”
And always there is a note: If you do not have/want to use z-wave, zigbee, … you can also use the … binding to get your things and items. And I hope that we could get to more than one showcase, so that you can link between the showcases to show how to install and get things and item from some other technology. And as soon as the items are there, you can follow all showcases further.
This all can be explained without any word about REST-API, json, … and a new user could go through it (theoretically or practically) within one rainy afternoon. Therefore, if someone has the necessary equipment at hand he/she will be able to use it as showcased in the evening and impress family and friends.
As you can see from my little example from above I just ignored the question of “what someone might have already or wants to buy”. You have to make some assumptions on something very common and a good combination of things that can show the advantages of OH. I would just take a technology that allows “nearly everything” as there is a broad variety of devices on the market. like zigbee or z-wave. Then decide for a combination of some other bindings that do not need too much prerequisites to be able to write some interesting rules. I choose Astro binding, as it allows a lot of nice things in combination of daylight and night. I also choose the Mail binding as a simple solution to get notifications. The Google calendar binding might be a bit complex to start with, but has the advantage of some interaction between your personal plans and your home. Another binding you could include here clould be one ot the weather bindings.
And for those users who want to get started with KNX?
The simplest is just UI rules. But there’s almost nothing you can do with them short of “when X send command Y”. It can do less than even Google Home routines. Not a great way to show what OH can do.
Alternatives with PRs are welcome. The only thing I’ll push back on is if content is lost. I don’t care any more where it gets put. It’s clear that Getting Started is being cited as the major problem, so someone, please go and make a better one.
Only if their device is a “simple” technology like Hue that can be wholly autodiscovered. They can’t use Zigbee or Zwave because those require bridges. They can’t use anything that works through a cloud API because those too require bridges. They can’t use KNX, MQTT or modbus because those require not only bridges but you have to manually create the Channels.
That’s why all three are presented in the first place. We don’t know what kind of devices the user has at home. If we only show the “Hue” way, we leave out huge swaths of new users.
And I’ve had several users report that they saw “Hue” and skipped over that page because they don’t have Hue.
This has been proposed a number of times. The task is enormous if the database is to include each and every device (which is what was proposed) with a massive ongoing maintenance tail. If someone wants to take that on I’m sure it would be welcome. No one with this idea has yet been willing to give it a try.
A major reason I didn’t stop there in the first place is that many users outgrow this almost immediately.
Hurray! Tag me on the PR and I can review if you like. Unlike here, my GitHuib handle is rkoshak without the l.
Just be careful that any content that gets removed is captured somewhere else in the docs.
There really isn’t a “home” in your proposed set of bindings though. That was why my idea to do excatly what you described with Astro et al was rejected.
Now it’s me going off topic but…
Isn’t it internally accepted that “openhabian” is intended for raspeberry pis?
How about emulating what others do, and present a set of confirmed compatible hardware?
Such as:
“Assuming that you have a pi4, the oficial openhabian image, and one of the following (community vetted) usb sticks:
Sonoff x
Yada yada
Conbee something or other
You get zigbee/Zwave device compatibility, compatible with so and so… “
The getting started documentation, would then include a list of compatible hardware and the perks of going with them. Nothing exhaustive, just a short list of examples that as we all keep updating our setups would benefit the documentation by our collective feedback.
As documentation goes, I think that’s a fairly neutral change with big benefits: as I user I would immediately understand that going with certain hardware would get me certain capabilities. There’s the initial steps, I would simply add something like “things to consider before starting.”
Before the installation, before choosing a pi, or the image, or what brought me onto the world… let’s have a talk about “stuff”.
Which would then bring up the following conversation: can we openly discuss the “making the hardware compatible automatically for the new users”?
I can happily provide some documentation pages suggestions/PRs assuming people find this a good idea but depending on whether or not the hardware “it just works” the wording would have to be adjusted.
But that isn’t my point. My point is that the desire is to eliminate the Intermedia and Advanced Thing configuration tutorials from Getting Started to keep it simple and if you do that you eliminate a large population of users who don’t have devices that can be auto discovered without a bridge.
“I don’t have Hue, I have Zwave. I’ve installed the binding but nothing is being discovered when I scan for new devices! openHAB isn’t for me.”
Still not sure about the benefit of such a autodiscovery.
I assume this autodiscovery is aimed at lower skilled new users?
In that case we have to assume that the „entry“-user (the one with lowest skillset possible), is someone who has some knowledge anyway about wifi, IP ports, home autmation in general (he will know what brands are installed in his house, etc).
With this minimum set of knowledge it is not a problem at all to have a new users searching and installing his 1-2 initial bindings by his own.
If I look back, I started with zwave only, tried to get things done, then decided to stick with openhab and then moved on to add more bindings.
I reckon that very few user want to have all the bindings a discovery finds, auto-installed by a wizard.
