That would be a question for @hilbrand.
Look for MDNS and UPNP scanner apps on your phone app store. On Android those which I use are ‘Upnp Explorer’, ‘mDNS Discovery’, ‘Service Browser’, ‘Bonjour Browser’, ‘Network Service Discovery’ etc.
I 100% agree with this, and had a similar thought about auto-discovery in general. We don’t want it to be become overwhelming.
I wish we could have an anonymous survey of systems to see what add-ons are most often installed by openHAB users, but I know we can’t collect data. Short of that, I think we need to keep it to “things that many new users would want right from the start”. Hence my suggestions of sun/moon, weather, and persistence.
1 Like
Here’s a question: what about HomeKit?
I don’t use it, so I don’t know what’s involved in setting it up. However, I imagine that a lot of Apple users already have HomeKit.
Is that a binding in OH? We have already got discovery for HomeConnect and HomeMatic …
It’s an integration, like openHAB Cloud.
Perhaps that’s one for the “suggested” list.
For HomeKit you might want to suggest it if iPhones/iPads/HomePods/Apple TV’s are discovered on the network. Possibly limiting it to iPhones/iPads as the other devices may also be in use by Android users.
It is a really good binding, works without delays has great documentation. For those in the Apple ecosystem it’s a must have IMHO.
So two questions
- How does one discover devices that host it?
- How does one add the integration to OH?
Astro should be built in
I suggested this years ago. Knowing if it is daylight or night time is such basic home automation function, it should not require a binding be installed
6 Likes
Is there currently any Thing that can be created without a binding add-on?
HomeKit doesn’t require a hub to function but is limited if you do not have one; a hub is required if you want to control things via HomeKit when away from home. Given that some users may have HomePods, HomePod Minis or Apple TV’s but not iPhones I would only suggest the binding for those with iPhones on the network.
I believe that Apple invented the zeroconfig (mDNS) system (they called it ‘Bonjour’), so device discovery should be pretty straightforward.
In terms of the second question the documents for the binding are pretty clear to read through, it’s just a standard binding installation through addons - apologies if I’m misreading the question.
We kind of already had this in OH 3 with rrd4j. It definitely caused some problems and it was decided to move towards a “you should install these” in the first run wizard instead. I can’t tell you how many times people on the forum don’t even know they are using rrd4j. This way the user gets to decide at best, and at a minimum are informed what’s getting installed.
The add-on suggestion feature is an addition to that overall concept.
The Item picker dialog shows the Item Labels.
The first icon on the bottom right toggles between showing the Item Name or Label in the blocks:
In the generated code it will refer to only the Item name though.
This is much requested and much rejected. The Item name is it’s UUID. You can’t just change the UUID. You have to remove and recreate it.
I think this would not be a great user experience either. I’m not sure I’d be for that unless there were a way to fix the pages, sitemaps, and rules (maybe not 100% but at least where an Item is actually referenced directly by name). Persistence is a major problem too.
If changing the name of an Item has the potential to break so much including potentially losing all the history associated with that Item, it needs to be something that is is relatively rarely done and not necessarily easy to accomplish. I don’t like the idea of setting new users up for needing to work through this.
With “delete links and Items” and “add equipment to model” deleting and recreating a bunch of Items all at once is not that much work. I just don’t want to have to tell the users “sorry, all that history you built up over the past year is gone now.”
Because you aren’t really renaming them. Every time the file is unloaded all those Items/Things get fully removed from OH. On a file load all those Items/Things are created anew. You aren’t renaming them, you are deleting them and recreating them, which, btw, is exactly what you’d have to do to rename an Item or change a Thing’s ID.
It’s not always quite so easy. And the Items might have a ton of stuff done to them (e.g. custom default widgets, GA/Alexa metadata, etc), tags, Group memberships, etc. We need the ability to delete a Thing and preserve the Items. The Links are a little less of a concern but it is a pain from the perspective that you have to relink the Items individually instead of in a batch.
The default strategy for MapDB is every Item, every change, restore on startup. However, that’s the same default for most of the persistence engines and strange things can happen when you have more than one doing restoreOnStartup so there is need for some caution.
But all you need to do is install MapDB to get a pre-set up persistence.
In most of the rules languages it is. You don’t need the add-on to use a REGEX in a rule. The only other places to use it (right now) would be as a transform. But I’m not sure that REGEX is used any more than say JSONPATH is.
But let’s not mix up the audiences too much here. We are looking for a magical first time experience, right? How magical is it to throw REGEX at a new user?
I definitely like the idea of making the Item triggers more flexible. It doesn’t have to be REGEX and frankly if the easier cases could be done without REGEX that might be easier for most users to adopt. However, I’d be cautious though that we don’t try to make them too comprehensive such that they overlap too much with conditions.
I think it was removed. The packages used to be:
- minimal: no UIs (except PaperUI), no add-ons
- simple: Only what was necessary to use OH solely through PaperUI in simple mode
- standard: I don’t remember but I think BasicUI was installed but don’t remember what else
- expert: I don’t think there really was a practical difference between expert and standard
- demo: included ClassicUI and i think maybe HABPanel, Astro, Network, and a couple of other bindings that don’t require extra hardware to use
I never used anything other than expert personally and I’m going from very old memory and the history in my git repo of my OH 2 configs.
I had no idea it was so many! Congratulations!
No. That doesn’t necessarily mean that basic sunrise/sunset rule triggers couldn’t be built in. There would be a little bit of overlap but the Astro binding could be reserved for those who want “Nautical Dawn start + 30 minutes but no latter than 07:00”.
On-the-other-hand, unlike some of the other super simple to set up add-ons like NTP and Network, Astro is super simple and it helps show how Things can drive automation in a more direct way. It’s instructive. I bet Astro was one of the first add-ons installed by all of us and I bet that almost all of us are still using that original configuration. And setting that original configuration up is a great way to dip one’s toe into the openHAB pool.
3 Likes
I just think MapDB should be included as well. If OH persists some states by default, it’s reasonable to assume that OH persists all states by default. So when their non-numeric items don’t come back after a reboot, new users think something is wrong and waste time trying to figure out why.
If we persist/restore everything by default, they won’t need to worry about what databases they’re using unless they want to get into InfluxDB or something else more complex.
5 Likes
Is this not the exact dichotomy that all these recent discussions have been about? Replicating the “magical first time user experience” of HA is about catering to those who do not wish to be informed but simply wish to have a home automation system that works. This is where OH, in the opinion of many, falls behind.
Everyone here knows that in reality there’s no such thing as a home automation system that works without being informed. So, maybe the question is: is it better to try and attract that audience in the hopes that some will have a good enough experience to decide that maybe becoming informed isn’t so terrible or does supporting that user segment represent too much of a burden to the developers and community?
There are certainly features that can move OH in a positive direction without running into this question directly. In the last several months we’ve done a pretty good job discussing and/or implementing many such features. But sooner or later, the OH devs and community are going to have to reckon with where they stand regarding the line between supporting the zero-config users and insisting on at least some minimum level of engagement/understanding.
5 Likes
I agree
Maybe where we need to draw the line is having something usable when installation is finished. Things like REGEX, mqtt and persistence are big boy topics.
How about, I install openHAB, it finds my Hue lights, creates some kind of interface I can use to turn the light on and off then guides me thru creating a little rule to turn the porch light on a sunset
4 Likes
My point though is right now no add-on is included by default. However, a number of add-ons are now recommended as part of the first run wizard. And I think that’s a good thing because it helps teach the users about OH in that first run.
I don’t think we are doing them any favors if we just have “tada! Here’s a working OH!” without guiding them and informing them on how it got to that state, and giving them a chance to inform and adjust that first OH config.
Until something doesn’t work right. Then these users have absolutely no tools to even know what they have let alone how to ask a meaningful question to get help.
We don’t have anything that can really make a suitable default for most users to make a good first impression. Everything’s a compromise. Just look at persistence. What persistence do we have that:
- doesn’t require setting up an external service
- doesn’t need to be maintained so it doesn’t grow beyond the available disk space
- supports all OH Items
None.
So now we are talking about going back to including rrd4j by default and adding mapdb because rrd4j fails 3 above. Oh, but both do restoreOnStartup so we’ll also need to deploy a custom persistence strategy with this default. Compromise on top of compromise.
We can get to “magic” this way.
I misunderstood and didn’t realize that RRD4j is no longer a default. Based on what you’ve described, I think the compromise of compromises 
would be to have a dedicated screen in the wizard to ask the user what they want:
- Remember and restore all values, with 24-hour graphing (uses RRD4j and MapDB)
- Remember and restore only numeric data, with 24-hour graphing (uses RRD4j)
- Remember and restore all data, with no graphing (uses MapDB)
- Don’t remember anything, I’ll set this up myself
I agree with you about socializing new users to the terminology and concepts. But in the specific case of persistence, I think a large subset of users will be perfectly happy to never think about it. OH would just remember stuff, and they wouldn’t worry about how OH does it.
3 Likes
I don’t disagree. Everything’s a compromise, but every compromise is a continuum. Where’s OH’s red-line on that continuum? I know, OH as a monolithic entity doesn’t exist so that’s not the most meaningful way to phrase the question, but I think the question gets hinted at often enough that it should be more explicitly discussed.
I suspect, in fact, that I fall much further away from the “magic experience” side of the continuum than many here. Few things boil my blood faster than software telling me what I want instead of listening to what I want. It’s one of the reasons I chose OH over HA in the first place many years ago. I was very impressed when HA found my cameras and placed them right on a dashboad and 45 minutes later I was howling mad at how nearly impossible it was to do anything with the cameras that I wanted to do.
I don’t really have a horse in the race for the persistence question. I agree with @rpwong that it is entirely reasonable for a new user to expect that all data is treated the same in terms of restoring the previous state. But then, I agree that it’s not really onerous to expect a new user to be able to install a persistence binding early on in their experience especially now that they can be configured through the UI.
100% correct. But what does that compromise get us? It’s not a compromise if OH doesn’t benefit in some way, then it’s just a loss. If it’s truly a compromise then there’s something in it for the OH side. Is that sequence of compromises worth an influx of new users? Does it even result in an influx of new users? Does it really inconvenience anyone other than whoever has to donate a little time to implement it in the first place?
Yep, that is certainly a legitimate concern when it comes to “Does it really inconvenience anyone?”. You certainly have more right to bring this point up than anyone else on these forums. On the other hand, is that scenario really all that different than what we have now where those same users don’t even know how to ask a meaningful questions about why their weather summary item is blank when they restart OH? The confusion and lack of knowledge is in a different place. Is one easier for the community to address than the other? I don’t know, and would tend to defer to your larger body of experience in this regard.
2 Likes
I’m definitely somewhere in the middle. I’ve been annoyed by getting-started wizards that try to lead me by the nose, and I’ve felt completely lost when presented with blank-slate software where I can do anything I want–if I already know how to do it.
In the OH world, we expose a lot of stuff that’s often “under the hood” in consumer software. Keeping with the theme, we’re speaking more to mechanics than drivers, and persistence is like a car battery. Most drivers don’t need (or want) to know how the battery works. They just need it to be there and work.
If we want to reach “magical”, per this thought experiment, then we need to speak more to drivers. But that is somewhat at odds with the OH mentality. And if so, that’s fine too. I’m on the record for not being too concerned about marketing and user share relative to Home Assistant. That would only matter if this were a race.
Yes, I tortured that metaphor purely for my own amusement (and hopefully for yours).
I’ll show myself out.
2 Likes