Ideas for new openHAB installation experience

JimT · February 20, 2024, 4:11pm

As an exercise, I tried going through the process of setting up a brand new openhab installation. I haven’t done this, probably ever.

Here’s what I found so far (I’ll update this as I go)

I got recommended 9 addons
- Android debug binding (not sure why this was suggested)
- MQTT (I have mosquitto on the network)
- Network UPS tools (I don’t nave NUT running, but I do have apcupsd)
- HP Printer (I do have one)
- IPP Binding (redundant?)
The binding installation process took quite long. Too long in my opinion.
- Is there anything we can do to speed it up?
- At the same time, would it be better to let it install in the background? I’m sure this has been discussed in depth before.

Then I was brought to the overview screen

When I clicked the button, the quickstart sidebar appears, but step1 suggests me to install a binding. Haven’t I just done that in the initial step?

Step 2, gives me a link to Thing Inbox.

As a result of having both HP Printer and IPP binding, I ended up with two entries in the inbox, related to my printer.

We should perhaps have some sort of mechanism for binding priority, e.g. if HP and IPP are both detected, give priority to HP and do not suggest IPP binding. @AndrewFG (from memory the addon suggestion was your baby, so you would know more about this)

It also detected one chromecast device. I have 4 in total. I wonder why the other 3 weren’t found automatically at this point

Then I clicked + and selected Chromecast Binding and clicked Scan.
Now it finds all my chromecast devices. This should’ve been found from the beginning.

Then the Add All link / button is not clickable. This is a bug?

Idea

At the very beginning of the steps, maybe right after the initial binding installation, offer two choices:

Automatically Discover and Add Things / Items
or Don’t

When the first was selected, instead of things going into inbox, automatically add them. This makes the experience a bit more similar to Home Assistant.

Later on, this can be disabled in the settings.
As long as this setting is enabled, openHAB will continually detect new things and automatically add them + create relevant items + add them to the sitemap.

The automatically installed things and items can be tagged with something that makes them easily identified and removed if needed.

*** more about auto item creation here

Then we should also auto create a basic ui sitemap and mainui page.

The end goal is if they selected Automatically discover and add things option, they’ll end up with:

Addons installed
Things created (not just inbox, but actually created)
Items created
sitemap created
a Mainui page created

So they’ll end up with something they can see and play with immediately.

The next step that a brand new user should face right after installation:

Link to the created basic ui sitemap
Link to the created mainui page
link/button to “Create a Rule” / Rule Wizard.

Note

To clarify, I’m not saying that I’m going to (or even able to) develop any of this. This post is just a preliminary findings and commentary.

AndrewFG · February 20, 2024, 4:17pm

That looks interesting. Probably there should be a series of wizard pages with check boxes where you can select which addons, things, items, forms etc. should be installed or created. By default with all boxes checked…

JimT · February 20, 2024, 4:20pm

That’s a good idea at first, and I can see how it would appeal to a more technical audience. But adding such a thing represents an extra hurdle for the brand new experience. Simply blindily adding everything would make for a more seamless and “magical” experience. I believe that’s what HA does (this is from my memory of trying it out some 6 years ago)

JimT · February 20, 2024, 4:52pm

We need to add more stuff that will get autodetected. I have a few other things that didn’t get autodetected, plus other stuff I think should be high on the list

Daikin aircon
Tuya stuff (for this we may need smarthome/j’s tuya binding merged into openhab
Alexa echo devices (can they be auto detected?)
LG TVs
zigbee2mqtt (@ccutrer is working on mqtt homeassistant discovery)
esphome (there’s a new binding)
tasmota (a general binding doesn’t exist at the moment)
TP-link Tapo stuff

anyway I think everything that can be discovered should be discovered and presented to the user.

JustinG · February 20, 2024, 5:08pm

This is a great exercise, thanks for doing this.

The quick start guide was developed while the binding auto detection and install was still underway. So, yeah, these did get crossed a little bit. Now that the framework for the help system is there (and vastly improved through the tremendous efforts of @florian-h05) it’s probably possible to make some of those steps more context aware and not redundant.

rpwong · February 20, 2024, 5:12pm

It’s not merged due to how it’s coded, so I don’t think that will happen unless something changes in the binding or the approval process.

rlkoshak · February 20, 2024, 5:16pm

This can be a problem for some bindings. Do you really want every device that responds to a ping on your network added as a Thing automatically?

Maybe it can be done better now but OH 2 had automatic Item creation and it was a disaster.

Furthermore, because MainUI’s Overview is built based on the semantic model and as it is currently implemented moving Items around in the semantic model is really tedious, I recommend this problem needs to be addressed before automatically creating Items can be considered (e.g. ability to drag and drop Equipment to a new Location from the Model settings page).

It’s only going to be magic though if the next steps are similarly easy. If we do all this stuff automatically but then it’s even more work than it is now to adjust as needed or, as was the case with the automatic Item creation in 2.5 the need to undo the automatic stuff, we’ve done no one any favors.

JimT · February 20, 2024, 5:24pm

No, but that means the Network binding needs to be excluded from the binding suggestion

What was wrong? I have never done auto thing / item so I’m not familiar with the process.

Something we could improve!

Sounds wonderful!

Ahh… one minor thing I have been meaning to do is to add “Check all” in the multi selection (prior to deletion). Yes, it should allow check all from here to here as well, and also smarter “check all in this group” type of thing.

I have no idea whether this is the case right now but I guess deleting a thing should also give you the option to delete all the channels + linked items.

AndrewFG · February 20, 2024, 5:36pm

Two things:

As others have mentioned we can currently only detect bindings that are in the OH main distro. If the bindings have not yet been included in the distro they cannot yet be discovered. So one step would be to encourage the process whereby such bindings can be adopted.
If you are aware of bindings in the main distro that can in principle be discovered, (i.e. that have a known disco mechanism) but are not yet discovered, then please provide details (binding name and disco mechanism), and I am happy to write the respective code.
In reference to 2. above can you (and all other readers) please run a UPNP scan app, and an MDNS scan app on your LAN, and let me know what devices they show up. These would be really low hanging fruit to easily add to the OH disco process.

JimT · February 20, 2024, 5:47pm

These are just what I have right now that support autodiscovery:
lgwebos (a fairly popular brand of TV) - NOTE, it came up in the binding suggestion now. It didn’t show up in the initial setup though. Maybe all my TVs were turned off at that time.
daikin (probably not that many people use/have it)

I don’t own any Hue products, but that could also be a popular one if discovery is possible (I don’t know).

Also UPnP binding just showed up in the binding suggestion post installation.

JimT · February 20, 2024, 5:49pm

Could you please provide an easier instructions on how to do this? It would help me and other readers.

rlkoshak · February 20, 2024, 6:01pm

In 2.5 the name of the Item ended up being a combination of the Binding + Thing ID + Channel ID so you would end up with Item names along the lines of Zwave_ASDF345_Node12_Switch. That’s fair because that’s the only information that OH has at the time of discovery. But it’s absolutely unusable for the end users in rules or any other place they might need to use that Item. Furthermore, to hide complexity from the users, the Items configs were actually hidden. You couldn’t actually get to nor change the Items through PaperUI when “Simple Mode” was enabled.

In OH 3+ we now have “add equipment from thing” which lets you create a bunch of Items all in one go, but it’s not automatic and it depends on information (semantic model , meaningful Item labels) which do not exist at this first run of OH. So that means the Item names and labels are similarly going to be meaningless to the end users as they were before. They won’t be able to change the names, but they can at least change the labels and they will definitely need to move them into the semantic model since there is no model at this point.

Thankfully most places in MainUI emphasize the label, not the Item’s name. You can even access and reference Items by their labels in Blockly, so having unusable Item names isn’t as big a deal as it once was.

But in OH 2 users would start in Simple Mode and quickly out grow it and start creating sitemaps and rules only to discover their Items are basically completely unusable because of how they are named and they need to delete and recreate them all over again.

I think one of the reasons there is an Inbox is to give the end users the opportunity to supply the information that only they know (e.g. this Thing represents the living room lamp) before all this stuff gets created automatically with names that are unusable.

You have the option but it’s a two step process. First you have to delete the Links (and optionally the Items) and then you can delete the Thing.

The problem is you may not want to delete the Links and Items (e.g. upgrading or rediscovering a Thing to fix some problem) so it needs to be an option, not automatic.

Currently (4.1.1) doesn’t ask when you delete the Thing if you want to also delete the Links and Items too all in one go. But that surely could be added to the confirmation dialog.

rpwong · February 20, 2024, 6:12pm

I would add TP-Link Kasa to the list (different from TP-Link Tapo).

If the focus is on making setup a magical experience for new-to-home-automation users, then part of me thinks we should curate a tight set of “devices that new users often already have” for auto-discovery. The magic is when the auto-discovery picks up things you weren’t expecting, like the HP printer (user: “you mean my printer can be AUTOMATED???”).

I’m not saying that we shouldn’t auto-discover MQTT, but someone who is already using it isn’t the person who will be blown away by OH auto-discovering it. These are the people who are more likely to take the “don’t auto-discover, I’ll do it myself” option that @JimT suggested.

We’re also going to run into cases where a user has a device (e.g. a brand new lightswitch) that hasn’t been added to the binding yet. That could be confusing if OH finds other devices of that type, so we might need some “if your device isn’t auto-discovered” hand-holding for this scenario (if that’s not already the case).

Sticking with the magic, I also think that we should install some commonly used add-ons to help/impress new users:

Astro
MapDB
A weather service (e.g. OpenWeatherMap, which would require direction to make an account/API key)

I just think that a new user shouldn’t have to manually install bindings for openHAB to know if it’s night/day or persist non-numeric states. Building these in as defaults would make it work better out of the box.

JimT · February 20, 2024, 6:22pm

I wasn’t aware of this. AFAIK, you can only see the items as their labels, but this is merely for display purposes. You still have to actually use the item’s name when creating the blocks. Am I wrong?

Perhaps we should allow renaming items, and automatically update the item-channel-links and metadata? I know this would break Pages and rules that refer to them but if we made the user aware of this, at least they won’t have to recreate the items from scratch and still have to update the broken pages and rules.

I guess ability to rename later on would solve that issue?

In file-based system, one is free to rename thing id / channel id / item id. So provided that the related links are updated, why not let them do it via UI?

If it was easy to recreate the links and items, why not let them nuke it all?

I had you in mind when I mentioned that, but I didn’t know the actual name. So yes, in that case, Kasa, not Tapo. That was my mistake.

On the contrary, it’s not just about being blown away, but more about being “impressed, pleasantly surprised and thankful that it discovered them for me so I don’t have to worry about figuring out how to”. So it’s still an important feature to offer.

+1 great idea!

mapdb should we go one step further and pre-set up the persistence / auto state restore?
jsonpath, regex, especially if mqtt is installed.

I wonder why REGEX isn’t a part of core, and also allow it to be used in the core trigger/condition.

openhab used to have the concept of “package” - mentioned in addons.cfg back in 2.x. I don’t know what the state of this now.

AndrewFG · February 20, 2024, 6:23pm

@JimT in general we have the following discovery mechanisms; (others could be added if needed).

Upnp device network scan
Mdns device network scan
Generic Ip device ping scan
Process ‘devices’ running on the OH computer
Devices that are attached to USB (and remote) serial ports.

At time of writing, there are about 90 bindings which are auto discoverable by these mechanisms.

Network scan discovery methods obviously require the remote device to actually respond to the search requests. The list of discovered bindings grows as new devices send in their responses. Some devices are faster than others, but in my experience you need a good 30 seconds after start up to get a reasonable picture.

Since the OH initial setup asks you to create your user id, password, and enter your location, I find that if you linger (as a beginner would do) over those steps, that usually provides enough time for most devices to have responded.

Yeah. Devices do tend not to respond to network scans when they are turned off … we can’t (yet) do mind reading

Yes this is discovered; both by Upnp and Mdns…

If you can give me a link to a description of the manufacturers discovery process, then I will (try to) add it.

JimT · February 20, 2024, 6:26pm

The daikin binding supports autodiscovery, via mdns I think.

AndrewFG · February 20, 2024, 6:29pm

Yeah I had already thought about that. But we would need to carefully curate the list of such bindings (things like network time, http service, network service, system info, iCalendar binding etc.) could come to mind. But I am sure this would create huge discussions here on the forum and among OH maintainers – which was the reason why I had not already made the suggestion until you brought it up…

rpwong · February 20, 2024, 6:29pm

Yes, now that it can be configured in Main UI. Then, many users will never have to think about persistence at all.

I meant to add “any commonly required script/transformation services” as a separate bullet. There’s no harm to including more of them, even if they’re never used. It would just reduce the number of “why am I getting this error message in the log” questions.

AndrewFG · February 20, 2024, 6:32pm

If you can provide me with a link that describes the manufacturers discovery mechanism I can (try to) add it.

JimT · February 20, 2024, 6:35pm

I don’t use any of these bindings on my production system (not the blank test one). However, I can see the system info being somewhat “cool” to install and automatically pre-set up to produce cpu / memory graph, although not all that useful especially for non technical users who just want to control their lights.

But if you’re talking about simply “recommending” / suggesting them, perhaps not a bad idea as long as the list doesn’t grow too big to become overwhelming. I don’t know how icalendar works, but in general it would be a cool feature if it’s easy enough to use / configure.