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.
2 Likes
my view:
- 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.
3 Likes
No, impossible, as not all local devices and no cloud services can be discovered.
3 Likes
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.
2 Likes
or no rule language
The ācreate ruleā page with āwhenā āthenā ābut only ifā is capable of some automation with no scripting language at all
4 Likes
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.
This problem would then be solved.
3 Likes
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.
1 Like
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.
There is always a choice. Nothing would be installed without the user approving their installation.
Sure. That was not the key point of my post.
As I already wrote: I am not going to remove things from existing documents as they are great work and very useful for everybody who is willing to spend more time on details after a first positive experience with OH.
I wrote that my idea of a/some showcases would include some common rooms as a minimal semantic model. A place to start with and to elaborate with the user needs.
OK, if this all was already proposed, rejected, and has no chance to get online then we do not need to talk about it again and I am out as I do not want to waste time to produce something for the bin.
If there is a chance to get a/some well definded showcases, as @Pedro_Liberal describes it, too, online to enable new users to realize something within one afternoon that has a payoff and makes appetite for more OH, I am open minded to discuss every little detail of such a setup and write the tutorial with the help of others who might be better in drawing some graphics, writing the rules, ā¦
And auto discovery is a ānice to haveā that can be showcased in one showcase that uses a binding supporting it. But if there is a decision for a showcase based on a binding without auto discovery for a good reason, e.g. that such bindings offer more possible devices, than there will be a note in the tutorial, that there will be no auto discovery available for such binding and an explaination on how to find things in this case. So what?
OH will never be the solution for the total dumb users of out of the box solutions. It will always be a solution for people with at least some technical/IT background. Talking about making the start easier has a lot of potential to lower the hurdles, that we could/should use. But there are boundaries we have to accept., like a technology that is worth to use and to describe, that has no auto discovery.
1 Like
I donāt know if it will be rejected again. People change their minds.
But my original plan with Getting Started was to do exactly what youāve described using exactly the same bindings. And the maintainers decided showing something ārealā was important so users could see something concrete instead of āsend me an email at dawnā.
I also wanted to tie the Demo to Getting Started. I canāt remember why that didnāt happen, but it wasnāt rejected by anyone.
What about the creation of a ādemoā binding? Something akin to the magic binding by @wborn (but pared down). It could have one associated simple switch thing, one simple sensor thing, one bridge thing, one switch thing and sensor thing that rely on the bridge to work.
That way tutorials could work off of the demo binding but also list equivalencies. āThese steps will use the demo simple items, but if you have Kasa, Hue ā¦ etc. then you can install that binding and follow along with your own device.ā
3 Likes
OK, but how can we make sure that investing brain in the definition of a/some showcases will not be wasted time? Even to develop the story for an interesting use case, that shows the advantages of OH without being to complicated, the definition of a necessary small set of bindings and a small semantic model of a house/appartement in which this all will be implemented, the needed devices, things, channels, items, rules (not already written, just their purpose) and minimal GUI, without one line of real tutorial, ā¦ is an effort not to underestimate.
Wait, noā¦ maybe I misunderstood but this:
This is great and i will fight tooth and nail to keep it. If you take the intermediate from there, for a new user looking to use binding without auto discovery, where the heck would you point him to? When I started I was an āadvancedā user with sonoff devices flashed with tasmota and no auto discovery. Where would a user like this fit? Has no knowledge openHAB knowledge, no programming skills, but is using textual configs because thatās what she/he has.
No, removing that does not fit in my view to simplify the getting started.
What determines whether the user goes to the āsimpleā āintermediateā or āadvancedā pages is not the user knowledge, but the devices the user already has. We cannot account for that so all three options have equal weight.
The most iād suggest would be to make all three pages child or a father page called āadding thingsā, where the topic could be presented in conceptual and lightweight fashion. Then each child page already details their concepts anyway so they are fine.
Hey Jƶrg, looks like you and I are starting to work on something similar, but for different purposes and maybe for different target people. Once you have made up your mind, letās go in contact with each other, before we end up with too many getting started, showcases, guides, etc.