When I wrote the Getting Started Tutorial that was the intent. It presents the common step-by-step for how to do everything from installing an add-on, working with Things, Semantic model, UI, and finally rules. It links to the relevant docs where necessary and it’s intended to teach users how to use the docs to figure out everything else. The advanced rules page repeats the phrase (or something like it) “look at the docs and find…”.
I’m not going to say it’s perfect but that is the intent of Getting Started. And again, it’s the old OH 1.x/2.x users who tell themselves “I don’t need to read something called Getting Started” who have the most problems adopting to what’s new in OH 3+.
The rest of the docs are referenve docs. They don’t really provide end-to-end instructions and instead provide documentation of the APIs. But only Getting Started shows you end-to-end how to use those APIs.
To be perfectly honest, I’m burned out on the OH docs. I personally have probable spent several hundred hours contribting to them over the years and right now I can’t even look at them and it’s been this way for a good bit of time.
No one reads them! And then they complain that OH is too hard to use. And then when you point them to the docs where their question is and they get mad because of the RTFM answer. And then they complain that the docs are too complicated.
This thread alone I’ve had to be very careful in my replies because of how much stuff on everyone’s wish list have been available since OH 3. But they never looked.
I look forward to contributions to the docs to make them better but for the foreseeable future I’m out (it’s no secret it’s been some time since I’ve submitted a PR so those who pay attention probably already know this). I’m not done with OH but I just can’t do the docs right now.
It looks like you are composing a home automation!
I’m not sure the help system made it into the Getting Started Tutorial. I need to check on that.
In addition, MainUI presents a pretty significantly different way to interact with OH and it’s a way where not as much experience from OH 2 translates easily. You almost needed to approach OH 3 as if it were a new platform to learn rather than a minor upgrade to an existing platform.
I don’t think that anyone here on this threads expects this of most users. But one of the challenges is the kind of user who wants to use an open source home automation system is the same type of person who wants everything to be exactly how they want it to be. And since everyone’s desires are unique that’s going to mean some customization. The degree of customization required is going to vary. But even for those users who want to tweak everything, there are lots and lots of levels of customization possible.
I tend to just stick to the properties offered through the oh-* widgets only. I don’t mess with JS and CSS and messing with F7 widgets diretly or anything like that. You can do a lot with just that.
A lot of effort has been spent so far and will continue to be spent to make a basic out-of-the-box experience possible. It’s not like everyone has to jump into tweaking CSS on some UI widget from day one. If one uses the semantic model, one doesn’t need to do anything to get the start of a resonable UI.
Then you have too many widgets on the row at that resolution. On a wider screen each widget may take up 25% of the row. On a mid sized screen each widget would take up 50%. On a small screen each widget would take up 100% of the row. For example, I have three colums in my one Page. Each widget takes up 33% of the row on large screens and for all other sized screens each widget takes up 100%. On the smaller screens the widgets flow down to a new row instead of overlapping.
The widgets themselves will resize to some extent but at some point they won’t be able to resize and be useable so they need their own row as the screen gets smaller. If you get below a certain width, the menu on the left collapses too.
That’s got little to nothing to do with OH.
It’s more than complex in itself and so is no matter what home automation system you use.
RICH!!! Don’t you ever shock me again like that, please. That dark age is over!
(BTW did that original thing have a name? In German it was (shuddering) “Karl Klammer”.)
IMHO, such comments aren’t really helpful. Making people feel stupid rarely achieves anything except getting them to shut up. It might feel good for those making them at the moment, but it just contributes to people giving up.
I generally think there’s a lot of “misunderstandings”, and that a significant amount of time and effort goes into getting to what the question/assertion really is about. I sometimes wonder if these misunderstandings are intentional, because I, when reading topics later, often understand perfectly what people mean from the get-go. But, whatever the reason is, it’s tiring for “both parties” (both those that know and those that don’t know). I think that things would work smoother for everybody if more emphasis was put on clarifying whatever points might be ambiguous or unclear, than to jump to some “conclusion” and then spend the next x amount of posts talking about completely different things.
I’m not criticizing the existing documentation, I’m recognizing that it can be hard to figure things out, especially when it comes to the UI, and I’m trying to suggest changes that might make it easier to handle. Documentation is usually the “most difficult” part of any open source project, because writing them is so boring, and often only a few people have the knowledge needed to write a specific part. Those that have the knowledge often feel that their time is better spend writing code than documentation - again because it’s so boring. In that sense, OH is miles ahead of many other projects when it comes to documentation. That doesn’t change the fact that things can be really hard/labor-intensive to figure out.
When it comes to the name “Getting Started”, it kind of implies that it’s about the very basic concepts and somewhat experienced users won’t expect there to be anything useful there. Maybe the same text with small modifications could function as a “Migration Guide” instead, which would probably get the attention of many more existing users.
What I was suggesting was something slightly different. It was that the documentation was multi-tiered throughout, so that you could read through the “overview”, get to the part you’re interested in, “increase the level” (I’m thinking something like a hierarchical tree with “pluses and minuses” that can expand/collapse the more advanced parts) and then study in more depth just what you’re interested in at that time. This shouldn’t just be two levels, it should be as many levels as necessary to fit the subject. The idea with this is that people of different “knowledge levels” could make use of the same documentation without giving up. If you expand some topic to a level where you just don’t understand anything, you could collapse it again and continue studying the information on a level that wasn’t intimidating to you.
This is just a vague idea, not something I’ve thoroughly thought, and might not be easy to actually implement. I’m just saying that I think the need is for people to find information that matches the level they aren’t currently on.
Looking at myself and how I do this, I think I’ve read most of the documentation by now. But, that doesn’t mean that I know all this information, far from it. The thing is that most of the time when I’m reading documentation, I’m looking for information about something specific. Searching often isn’t helpful, because I have no idea what whatever I’m after is called in the documentation. So, I have to try to find the parts that are “close in nature” and then read that. But, I’m still in a kind of “scanning mode”, so the things I read that isn’t relevant to the issue I’m having, don’t really “stick”. Some of it might “accidentally” stick regardless, giving me some vague idea about something that might turn out to be useful later, but in general, I’m looking for just the information I’m after. This is a protection against “information overload”, and I think everybody must have some sort of strategy for how to protect themselves against it.
I often look through both the parts of the documentation that I think might be relevant and search the forum for terms I hope will give me some relevant hits, but it’s still challenging. On quite a few occasions, I’ve given up and started to look at the source code instead. Often, this has gotten me the information I seek quicker and with less effort than using the documentation and forum. But, most people don’t have that option, and the size of the codebase is somewhat overwhelming, so it can still be difficult to find “the right sections” to study.
I think this whole process is “problematic”, whatever the cause(s) might be, which is why I’m trying to point out that I think the “biggest challenge” is to actually find the information - not that it’s not there.
This is sad, but understandable. Writing documentation is an ungrateful job, you never really hear anything when it’s working - all you will ever hear is the complaints. In addition to be boring, it can be challenging. You must master both the language in which you are writing well enough to phrase it somewhat “pedagogical” while being sure that you have enough knowledge about the subject you’re documenting that what you write is 100% correct. Personally, I don’t feel comfortable enough with English for the first part, and being something of a hopeless perfectionist, will never be confident enough about the second part before I’ve read all the code behind it.
But, I don’t think it’s true that nobody reads them. My guess is rather that they don’t find the information they’re after in the amount of time they are willing to invest, or if they find it they don’t understand it because there are other terms and concepts involved that aren’t familiar with. Some poeple behave like “spoiled brats” of course and will always just demand to have everything served on a silver platter, but I really think those are a small minority when it comes to OH. The matter is complex enough that most of the “spoiled brat types” will never get here.
This is why I’m trying to point the finger at trying to optimize/improve how people find the information, and that the information is at a level they can handle at that time. What level of information you can take has nothing to do with being stupid, it has to do with what knowledge you currently possess on the subject. When you get overwhelmed, nothing makes sense - even the parts that you would otherwise understand, because the brain goes into a kind of “I’m overloaded I reject all information” mode. At the same time, the lack of more advanced information will lead to frustration that it can’t get you where you want, which is why I’m suggesting that there need to be some way for the advanced stuff to exist without it overwhelming those that haven’t gotten “deep enough” in the matter to be receptive for it yet.
I guess what I’m trying to say is that I fell that it quickly leads down the road to writing custom widgets, CSS etc. Maybe the “basic building blocks” should be a bit more flexible, so that the threshold where you need to go “hardcore customization” was a bit higher?
Many people will probably never do “hardcore customization”, so if they can’t get where they want/need without it, they won’t get to a place they feel is workable.
I have to disagree there. First of all, the semantic model really hasn’t been fitting my needs very well. I’ve now discovered that I can extend it, which is a big improvement and I’m now in the process of trying to build a “meaningful structure”. But, back when you couldn’t extend it and just had to stick with what was there, I really couldn’t see how I could make it useful for me.
In additon to that, I still haven’t really grasped the concept of a “Point”. Just recently I fought the UI quite a lot beause it refused to display a list of options for a typical “numeric enum type” Item. I was through StateDescription, CommandDescription and all that multiple times to no avail. In the end, out of desperation, I started to change the semantic tags. It turns out that I had tagged it as a Control and that was somehow unacceptable to the UI. When I changed it to Point instead, everything worked fine. To me, this just doesn’t make sense, which is why I’m saying that I still haven’t “understood the concept”. I’m still surprised by the implications of changing this property, and I’m not sure I know exactly what role it serves.
Also, given that you get the semantic model to “fit” your system, I still don’t think it gives me a good representation. Some information is more important than others, it’s hard to get the “overview” when you have to keep expanding everything, and where the stuff you need to know is mixed with the stuff you rarely need, in alphabetical order. I guess that’s what the Overview page is for, but then you need to start with layouts, widgets and all that. I just can’t seem to get the “autogenerated pages” based on the semantic model to give me the information I need in a way that I find efficient. Also, the lack of customication of for example the “Location cards” is frustrating - they use a significant amount of screen real-estate, and yet most of the information they display is wrong or irrelevant (like temperatures being averages, alarms being picked up nomatter how “insignificant” etc). All you can do is hide the badges to remove the incorrect information, making them just a huge waste of space that you have to click to get any real information.
I’m sure the semantic model will work just fine for some homes, if you’re “lucky” and your layout matches the ideas of those that designed the model. But, it’s too inflexible to work in many situations out of the box - and I’m still trying to “tame it” enough to make it usable for me.
There must be something I don’t remember, although I did use Office 97 quite a bit. But, back then I was probably more often in Turbo Pascal than in Word
That said, my comment was more general, the post I replied to was just “an example”.
Once you get it like you want you can copy the code to the Developer Tools → Widgets to save it as a reusable widget.
This process is covered in Getting Started IIRC.
OH provides:
do nothing with the UI OH builds for you
customize the autogenerated Pages
slightly customize widgets individual widgets for Items
save and resuse these slightly customized widgets for Items
completely customised widgets
Only 4 requires anything approaching code (see Widget Expressions & Variables | openHAB) and only 5 requires anything like CSS. The majority of users can should not need to go any farther than 3, but Getting Started coveres up to 4 with examples. And I didn’t even list install and use custom widgets from the marketplace.
Sure, if you want to jump straight to an animated dial widget with several points of interaction yes, if there isn’t something on the marketplace, you’ll have to jump straight to 5. But if you just want to change the icon and colors used by a slider widget, you just need to fill out a form.
Adding custom tags to the model has been available for over a year I think. It’s relatively new but not super new.
Point is the “generic” point tag to be used when no other Point tag works and you can’t create a tag you want (“Location”, “Indoor”, and “Equipment” serve the same purpose).
When you choose “Setpoint” that tells MainUI you probably want a slider or setpoint element as the widget to control it. When you choose Control it’s probably a toggle element. If it’s a Measurement it’s probably a label element with a chart when you click on it. And so on. All of these are handled based on a set of rules (I can’t tell you exactly what they are, I never looked that hard into them). But those rules take the Item type, semantic tag (particularly the Point tag), and the State Description information to choose the UI widget.
Sometimes it will get the UI element wrong (e.g. Control with a Number Item). It would be good to make this smarter. I actually would have expected Control to work for your case and I would file an issue on that. Perhaps the rules can be smarter on this front.
But IMO you are better off changing the Default List Item Widget on the Item that MainUI gets wrong based on the Item type and tags than to bend the semantic model too far from what you want it to be.
You can control the order elements are shown in the overview cards with the Default Widget Order Index metadata. Visibility and custom widgets that combine multiple Items in one widget can be useful. I think there is some way to control the information used to populate the badges on the Location cards but don’t have that info handy at the moment.
Beyond that we are back to “the autogenerated stuff doesn’t mat exactly what I want”. That’s always going to be the case. But there are lots of degrees of customization possible before you have to get to coding raw CSS in the Developer Tools → Widgets page.
But that doesn’t change the fact that with the model you get a basicly usable UI out-of-the-box.
And maybe the autogenerated UI doesn’t work for you. But no autogenerated anything is going to work for everyone. Does that mean because it doesn’t work for you it works for noone? Or that it doesn’t exist at all?
But again, you have customization availalble to you with a gradation of knowledge required to implement. It’s not required though and you don’t have to jump straight to messing with frameworks, editing YAML and CSS if you do need customizations.
Exactly, so maybe a slightly modified/adjusted versions of basically the same document would be the best approach - one for new users that explains things from scratch, and one where the most basic concepts are omitted, but all that has changed is covered…?
Just so that it’s clear what we’re doing here. I’m not out to criticize. I’m just saying that I personally find getting the UI “to behave” very challenging at times, and I know that I’m more persistent than the average user, and I also have somewhat relevant knowledge of many of the topics. So, I assume that it’s even harder for many others than it is for me. I get the impression that I’m not the only one that find it challenging. From this, I’m trying to shed light of exactly what makes it “challenging”, despite all the possibilities OH has.
I think this area probably is where OH has “most to gain from improving”. Which is why I’m discussing it here. What capabilities there are, is only one part of the equation. If people either don’t find the capabilities or don’t understand how to use them, they aren’t of much help for those people.
I can’t answer for everybody else, I am just me, so I can only refer to how I experience things. I’m not saying that my experience is the only truth, it’s just that it is what I have to “contribute” to this.
I’ll try to address the different options you describe, and what I personally have found “lacking” or problematic with them:
As already stated, that isn’t what I consider usable in my case. It’s just too unorganized, lots of misleading or wrong information, and very hard to find what you’re after. I don’t think that’s strange, it’s a tall order to automate this and get a “turnkey solution”. But, since this is repeatedly mentioned as an option to just use what you get from this - which might work for some, but certainly not for me. I would be able to navigate it even though it would be inefficient, but learning other household members how to use it… no way.
The customization on this level is too limited to address most of the things I find problematic. It’s not sufficient to just reorder and hide stuff. I’m most interested in the “Locations” tab, it’s the way that makes most sense for me to get the overview I need, so I’ll primarily talk about that. You can choose between “Nested pages for sub-equipment” and “Equipment items grouped as accordion cards”. The former results in information overload and isn’t a good solution for me. The latter is more interesting, but ideally I would want a combination of the two. You can “promote” certain Items, which is on the right path, but you have to do it for all “equipment” or none - and you can only “promote” one from each. This is too limited for me, for some I’d like to “promote” several, for others none. It all depends on the equipment and what is used often and not. The same goes for enabling/disabling the badges - it’s simply not enough. To make them meaningful, I’d had to be able to decide what Items to be considered for a certain badge. Since I can’t, all I can do is disable them so that they aren’t misleading.
I’m not sure if I follow you now - have we left the semantic model and are at the manually designed pages now, or are you referring to tweaking widgets and “assign” them through metadata so that they are used in the autogenerated pages? If it’s the former, I find it too labor-intensive to manually place widgets/do layout for everything. It’s fine to do this only for the stuff you use the most, but not as a replacement for using the semantic model generated pages that covers “everything”. If it’s the latter, yes, that’s possible and one of the things I currently do to try to “tame it”, but I suspect that this might go over the head of some. You must do it in a completely different place, in my case I must do it in the .items files. I must first figure out how I want the widget configured, what widget to use (only “list widgets” work for this AFAICR), then the syntax for linking it. This must then be done on a per-Item basis, referring to widget names and configuration options. It’s absolutely doable, but it starts to get slightly complicated to put all this together.
This makes me believe that I misunderstood 3., or this is something I’m not aware of. Regardless, I know that you can “assign” customized/tweaked widgets through metadata, but again it quickly gets complicated. You have to do one thing here and one thing there, and you must keep the overview of what needs to be done where. I often find myself having 4 tabs of the OH administration interface open when I UI, since it’s just too much back and forth between “page design”, “model design”, “widget design” and looking up Things and Items for information about metadata, channel/Item types, options etc. I frankly think this is too hard to figure out for a lot of people - but I could be wrong of course.
That’s a good option if you just can’t get the standard widgets to do what you need, but I think I end up there a bit sooner than I would wish at times. Some of the stuff you need to customize to do I think ideally should be doable by configuring the standard widgets instead. Doing this also has a pretty steep learning curve, because there are so many things you need to understand to be able to make things do what you want to. Only having the work with YAML itself is a huge pain IMO, trying to figure out what level something that is several pages further up is on by “counting” the “indent indicators” is just too painful for me at times. I think JSON is a million times more “human friendly” since whitespace should never be part of the syntax. But, rant aside, there are a lot of limitations in the F7 framework and in OH’s derived versions, and figuring out what you can and cannot do isn’t trivial. The same goes for some of the syntax, like JavaScript callbacks, that must be done in a way that is “acceptable” to YAML. I spend the majority of my time when doing this on trying to figure out how I can do something or if it’s at all possible, and just a small part of the time on actually “making the widget”. I never know when I start trying to make something if I will end up just having wasted a lot of time because some details that’s needed down the road isn’t possible for this or that reason. It’s very hard to get sufficient overview to determine if this is the case before you start.
But, this is going slightly astray, it’s fine that you have to design custom widgets if you want a different look or some fancy stuff. But, I feel that it also applies to more fundamental “functionality” stuff at times - like putting together a group of “radio buttons” for example. This shouldn’t require a custom widget IMO.
A year is “recently” in my perspective. It wasn’t an option the last time I tried to “tame” this. It was also quite coincidental that I discovered that it was possible now. I remember having had some discussion on this forum regarding this in the past, and basically being told “forget it” (from my memory, I haven’t searched to find this conversation). As a result, I was under the impression that this wasn’t something that was going to be implemented, so I didn’t expect to find it and thus didn’t look for it. Instead, I dug into the core code to see if there were some way I could tweak this to make it work. When doing this, I came across the YAML parser for the semantic model, and that’s what led me to look for information and figuring out that it’s now possible. So, the overall likelihood is that I would still believe that this wasn’t possible, and that it wasn’t even desirable.
I appreciate that you try to help me understand this better, but my motivation for mentioning it in this context wasn’t actually to find the answer, it was to shed light on the fact that I still find this unclear and unpredictable. I doubt I’m the only one. For me it’s still not clear if the semantic model only impacts MainUI, or if there are, or will be in the future, other implications. The uncertainty of the consequences of the choices you make, makes it hard to know how to deal with. I have started to remove semantic tags from many Items because I can’t find a way to “hide them away” enough to not make a clutter in the automatically generated pages.
It would be much easier to make the decision to do this if I was absolutely sure that this will only ever impact the autogenerated pages. But, the way it is described and named, where it is placed, makes it feel like this is something more “fundamental”, it’s a way to describe how your Items relate that could be used for other purposes. And as a result, I’ve been hesitant to remove the tags “just to clean up the UI”. This is again meant as an example of the type of things I find “difficult”, I’m not seeking the answer to this question in this thread. I’m simply trying to explain that I suspect that these “uncertainties” probably hinders others as well, and that there would be “less resistance” to using it if it were clearer to people exactly what they were making decisions about.
I’m pretty sure that Control used to work - because I had a lot of Items with this issue now, and I think I remember them “working” in the past. But that in itself wasn’t really my point, my point is that it sometimes feel like this works in “mysterious ways”, enough so that I’m not even sure if this is a bug/regression or “by design”.
If so, except for hiding badges, it has elluded me this far. Or, I might have some vague memory of something, but that it didn’t apply to the things I needed to change, like the temperature averages because that is hardcoded. Regardless, my conslusion was that I just have to hide it.
This has largely been addressed further up. I’d just like to add that I’m not talking about that everything must be what I consider “ideal”. As long as I feel that it reaches the threshold of “functional, usable” I can live with it and then try to tweak it when I have the time. But, it can’t be a complete mess of information that is wrong and/or irrelevant that you must scroll through and expand/click to find the few the things you need. As long as the ancient Sitemap (with all its limitations) is functionally superior to what I manage to get out of MainUI, I consider my attempts to switch to MainUI a failure - and keep using the Sitemap. That’s not the same as “if I can’t get everything exactly like I want to, it isn’t good enough for me”.
Again, this topic isn’t about “my needs”. I’m just using myself as an example, because that’s what I know. I’ve never said that the autogenerated pages don’t work for anybody or that they don’t exist, I’ve said that my impression is that adoption is somewhat slow and that a lot of people seem to struggle with somewhat similar challenges as I am. And my focus is on the fact that I think everything that can be done to “improve this situation” would be very beneficial for OH.
The closest I can get to summing up what I think is the problem is that the “standard stuff” isn’t flexible enough and that it can be hard to find the right information.
we don’t have enough volunteers to keep to with one version. I doubt we could keep up with two.
The latter. Define default list item widget metadata on the item and that is what gets used in the location cards for that item instead of the default.
It’s much easier in the UI . And it is possible to second the items in .items files and define the item metadata in the UI.
But I frankly look on these sorts of issues with file based configs with needing to look up the syntax and such the opportunity cost to using files. You don’t have to look up syntax in the UI for this.
Why don’t you use the developer sidebar?
And there really shouldn’t be anything relevant from Things that drives the UI widgets, just items
But you can pin everything you need to the student and navigate around as needed.
Or, as I described above, configure your custom widget from the “default list item widget” metadata menu which is just filling it a form and copy the result to the widget page and add the properties you need.
Beyond that, I think I’ve said all I’m going to on this subject. I’ve clearly layed out what is currently possible to the best of my ability.
In my experience helping people in the forum, most of the people who struggle with MainUI, widgets, and the sensation model are old timers. New commers don’t seen to struggle with it as much. I’ve blamed lack of reading getting started but maybe it’s something else.
I leave it to all of you to decide what to do about it. PRs and actionable issues to the docs and MainUI are always welcome, particularly PRs as there’s no guarantee any given issue will be addressed in a timely manner. This goes for any part of OH.
I just want to close by saying the developers, despite what some may think, really do care about this stuff and have spent countless hours trying to improve all of this over the years.
@Nadahar It’s much less complicated than you apparently think it is.
The semantic model is essentially just additional groups and tags, and strictly speaking doesn’t even impact MainUI. If you use it, it tags your items and adds them to groups.
The default MainUI entry page called “overview” then uses this information to present users a default view on their home.
From there on, however, you can change or even replace the overview page, and of course you can add your own pages and use those instead of the autogenerated view.
There you’ll be having all the display flexibility you might want. You can even keep your items tagged, that shouldn’t do harm as no OH component except the semantic modeller should be relying on them.
(Well, parts like voice assistants eventually can make use of them, but they do not rely on it.)
That’s it, essentially.
(@rlkoshak I tried boiling it to the point and might have overlooked things in doing so, so please correct me where needed)
I think this might be far more easily achieved through the Sitemap / Basic UI route. We just need some different “Templates” / “Skins” to choose from.
I tried to restructure and simplify some docs, starting with blockly, but faced a lot of challenges from the existing doc maintainers that made me give up. My impression is that:
The status quo is sacred and the current documentation cannot be changed. Heaven forbid we removed a paragraph from the current doc. In other words, there’s a high resistance to change.
Only new additions are welcomed
As a result, things just keep getting more and more complex, longer and wordier.
Which makes the doc an onerous chore to read by (new) users, especially those who don’t enjoy reading super long novels.
We basically need a TL;DR version but I understand that it’s not easy
This is the part that really needs a major restructure of the docs, a MAJOR demolition and rebuild. But who would take on such a task if it would just get rejected anyway? This will take hours and hours of work and the risk of rejection is high based on my experience.
It might be easier if you only use the UI, but you still have to basically control the same combination of information, minus the syntax. I’m not convinced that everybody find this as “easy” as you do. Personally, I’ll gladly trade having to manage the syntax for the immutability of the configuration though.
I didn’t know that you can pin other things than Items. That said, it won’t quite do what I need, as it will link to some object, but it won’t preserve the “state” of that page (where I’ve scrolled, what I’ve expanded etc.), so it’s still more efficient to keep separate tabs. And, it’s the way I’m used to work from other tools, like Eclipse or Visual Studio Code. But, that wasn’t really my point, my point was the different sources of information I need to put together - not how I choose to solve the information gathering.
You absolutely have, however, by constantly focusing on what is currently possible I feel that you kind of “steer the focus” away from what I’m trying to address: potential improvements.
I have a slightly different theory: “Old timers” have invested considerable time and effort in OH already, so they have incentive to try to figure things out. Thus, when they face problems, they try to solve them, to some degree at least. Newcomers on the other hand, have invested little, so it’s much easier for them to just move on to something different. A few newcomers are “lucky” and their needs line up perfectly with what is easily achievable, and they are happy. The rest you never hear from.
Personally, I don’t doubt that at all. I think there’s a defensiveness here that often gets in the way of discussing what could be done better. There is no contradiction between saying that this or that could be solved better, and that somebody has put a lot of time and effort into making it what it is. What OH is trying to do is large and complicated in nature, it’s not to be expected that any one person (or a few) will have the full overview over all the different needs and “perfectly design” everything. It should be possible to discuss how to make things better without that being seen as criticism of what has already been done. Not all suggestions will actually be improvements, of course, but that’s why we call it a “discussion”.
I wasn’t aware, and frankly a “blog” doesn’t really fit well with how I operate. The reason is that I have so many different “projects” that I can’t remember “deviations”.
What typically happens is that I visit OH from time to time, when it fits my “schedule”, and most likely I’ll discover a new version when I run apt update. Most likely, it’s a jump of more than one minor version. I then search the net and openhab.org for a changelog, and don’t find anything. And, that’s the end of that - I never know what as changed, and probably will hold off the upgrade until I have a specific reason to, since I don’t know what will break.
I think a changelog would be very helpful, even though I don’t know how large portion of users are accustomed to this “convention”, it’s what I pretty much completely depend on.
I know, and I do, I was just trying to explain that I don’t consider the whole process as that “simple”, and I suspect that it is too much to keep track of for some.
That cuts both ways. Once they understood how things work and how they should best handle this, old-timers (like me, too) are pretty reluctant to again question that and re-learn something new. The more they invested the more reluctant becuase it means their investment is at a loss.
Also, they tend to see the new stuff as some ‘organic’ extension to old stuff and try to link and make sense of details where old and new stuff obviously don’t match or integrate because they inherently make the mistake to think that the new stuff was designed with full awareness of the old stuff, reusing everything, doubling nothing etc. Which it wasn’t.
That’s great, and my point is that I’m not sure if this comes clearly across. If I knew from the start that this is all it’s used for, it would have been much easier to estimate the implications of what I do there, and thus easier to handle.
I do store my OH config using Git - and although there are a few “annoyances” (like changing timestamps that trigger diffs that really isn’t a change), it works well all in all. I would never put it on GitHub though, I store it in a private repository that I host myself - and which is backed up to tape.
@ErikDB Yes, that’s fine, but it don’t find that when searching for “changelog”, and I don’t remember that I must use “special rules” to find that changes for OH.
Absolutely, I wasn’t saying that what I described was the only reason for this “dynamics”, and resistance to change when it means loss of time and effort already invested is a human trait which we all probably share to a large extent. But, I still think it’s probable that there is a “filtering effect” on new users, where you never hear anything from those that try and give up realtivly quickly.
Looking in the most obvious category (which is also the first category you see), doesn’t seem that ‘special’? And if at your first search term you don’t succeed…
I’m not saying that it’s very difficult to find - but the fact is that I just discovered that these announcements sort of function like a changelog very recently, and I’m not sure if I’ll remember that in the future. So, for me at least, this makes me miss changes.
If you don’t remember, this was Office '97, some of us have awkward feeling about that…
