Exactly. That is possible with yaml because there are ready to use libraries.
And no there are no .thing file parsers out of OH. So they would have to be written.
Yes if technology evolves people should migrate in my opinion. a lot stick to old technology out of lazyness and at the same time wanting the newest features. Either stick to an older version which is always possible or get used to new ways.
And yes Mqtt1 was OH1 technology based. A different way of configuring it was excepted as the concepts have changed. Everyone still using OH1 technology can expect those breakages in upcoming releases. Don’t upgrade if you don’t need to. The few developers that are involved in the core can’t maintain two ways of doing things forever. Don’t only thing from the perspective of users but try to find a comprise with maintainability, too.
I will not touch this subject though, I will concentrate on the first time user experience and my way of using openHAB.
Cheers, David
See, that’s my problem in the last two weeks since 2.4.0 was released. Based on a guess, you reengineered a very important part of the core, and did not take time to look at how “some users” are using the system because you consider that way to be “ancient”, even though it is in widespread use.
The relaunch of the MQTT binding might have been much smoother if you had considered a migration path. Instead, we had broken examples in the README. You could even have asked people who are using the “ancient” way to help you with the documentation (for example @rlkoshak who usually does a stellar job with docu).
I held my peace for so long now, but I am getting slightly fed up by now with your attitude. The deeper in the core you are working, the bigger your responsibilities to the installed base becomes. My work experience of the last 20 years allows me this opinion, I guess.
5 Likes
I can find equally damning negatives with respect to the legacy .things/.items syntax. I think it is easier to find more editors that can be configured to parse and validate YAML syntax than it is to find editors that can do the same for .things/.items syntaxes. YAML has a uniform, easily parsed, easily understood syntax whereas the same cannot be said of the legacy syntax for textual configuration of Things and Items.
I haven’t tried gathering examples, but I know there are a good number of requests for help here on the OH forum that boil down to having gotten the Thing or Item definition syntax wrong. Yes, long-time users of OH are familiar with the basic syntaxes for Thing and Item definitions, but the syntax is not static, it continues to evolve, which is a continual source of trouble, even for old hands. YAML, on the other hand, has a very stable, comparatively static syntax in comparison.
Ah, but the crux of the matter is not where you put your tabs and spaces, and how you indent the “source”. You also have to interpret what you read from the yaml file, and here the questions about “which section do I put my semantic tags into” and “what is the syntax for a channel-to-item link” will come up again.
Killing xtext might be a good first step, but it will be in no way the full solution.
Yes, semantics definitely remains an issue, regardless what representation is chosen.
Just to clarify: I haven’t. I’m using a personal fork without xtend (no old rule files, things item files). Nothing has changed for users.
But I am working on a new paper UI design study and will present that to the public for everyone to participate.
I’m just trying to make openHAB as an entire solution more reliable and fast that’s all.
2 Likes
Yes if technology evolves people should migrate in my opinion. a lot stick to old technology out of lazyness and at the same time wanting the newest features. Either stick to an older version which is always possible or get used to new ways.
That is one way of looking at it.
It could also be seen as developers who where to lazy to create a (documented) migration path.
From one version to another.
I agree with you that people should upgrade. Yet I also think that developers should facilitate and help the users to make the upgrade.
2 Likes
I was talking / writing about the MQTT binding.
In the end, it doesn’t really matter what format is used. We need a frontend that is easy to use for new users but allows users with large installations and/or experienced users to manage their installation as comfortable as possible.
But we must not forget the existing installation. If we introduce e.g. new file formats we need to have an automatic conversion for existing files. Otherwise new formats won’t be accepted and instead of unifying the different configuration formats we would end up with just another configuration format.
BTW: we should not forget the sitemaps (see: https://github.com/eclipse/smarthome/issues/5337)
4 Likes
Currently sitemaps are OH1 only but yes if that pr goes through, they will be stored in a structured JSON and can be manipulated via the rest interface finally. I’d be happy to support those in a paper UI new gen.
1 Like
I agree. But reading through comments some people wouldn’t be happy with anything that is different to status quo. So nothings changes I guess.
Thanks much all, for this interesting and passionate debate.
Disclaimer: I am likely the least informed person here, but I am using OH since 1.8 or so.
It reads to me like we are going in circles and a few things stick out:
- no one likes change unless the person itself is initiating the change
- Examples in README files that are wrong are a killer for the non-experts: I am already making the efforts to read the docs…so I would want to believe that the info is correct (maybe not complete in all nuances, but at least correct)
- Current structures are the result of something that is organically grown for years…and hotchpotch of various UIs and syntaxes
- YAML can be a pain, but current files are too; for example: when do I need to add a space after the “[” and when not? (e.e.g, lambdas); curly vs straight vs. square brackets do not seem to follow a system, somethings are capitalized (e.g., “Item” in rules), but not always (use of the word “item” in sitemap)
- PaperUI is OK, but editing the JsonDB, just because a thing cannot be removed for whatever reason (at least for the perspective of the uninitiated) is a royal pain…after this happened to me once, I only use text files…so if push comes to shove…I can just start fresh
- PaperUI is NOT a good choice for mass changes…which happen as I am figuring out anming schemes for things and items
Personally, I like a lot of what I am hearing from @David_Graeff…the transition will be a royal pain, but the current state is far from pain free. I am writing this as a casual user…well maybe a little more, I am spending a few hours most weeks in following the forum, but I am not always working on my rules (and my dayjob has nothing to do with IT). For me achieving more consistency would trump the short-term pain for transitioning anytime. Maybe my memory is not as good as that of other, but the amount of time, I need to spent in the docs for looking up the issues mentioned above seems rather large.
And lastly, just because the new user or non-expert user has been invoked here: I cannot speak for all, of course. Just keep in mind, that we uninitiated typically have much less to use compared to the experts. Hence, re-learning is not so much of a big deal. It is not that I have the current state committed fully to memory anyway. But please, please: before releasing major rework, please, please provide some docs that are correct. Without them…we are lost (remember: any error code that is not super simple does not help the non-experts: the dumping of the JAVA stack in the error, certainly does absolutely nothing for me).
Reading this thread, I am a little surprised that we have only little agreement on the acceptability of the current state. My person take: it is workable but definitely not pretty and will only grow worse over time. Judging from the non-expert perspective: it looks like a new way forward is definitely needed…I am a little worried about devs adding more and more features with the current structure…for me it will definitely become too much inconsistency and too unwieldy pretty soon.
6 Likes
I currently have 1734 items. With this number a good editor and command line tools are, in my experience, much more productive than any GUI.
4 Likes
Many items are only existing because of rules and because you don’t use new ways like profiles maybe? But imagine this:
You can filter for items that have a specific tag or name pattern and click on the text mode and have all in a text file like view for editing. The editor would be the one from vscode. Would that be sufficient for your task?
Well, in an average user’s eyes you have replaced “the” (“one and only”) MQTT binding with an incompatible one without (enough) proper guidance that they needed to migrate und how to do that. For example, you made the README examples unapplicable. No wonder that results in support efforts (and remember with that statement you’re only counting those efforts on your part - ever gave a thought of what that meant to others to support on the forum ?).
I second @hakan in that that was a somewhat bad move. Note that statement is independent of the quality of the new binding. Albeit a major, widely used binding, it wasn’t all that severe for now because noone is forced to use the v2 binding as the v1 binding is still available as an alternative.
BUT here in this thread we’re now discussing to replace a part of the real (monolith) core (not just a binding) without your willingness to keep the existing input method or to create a backwards compatible(!) alternative because you feel that to be “ancient” which is in fact your personal opinion only and a questionable one - many people disagree with you there.
If these changes were to become part of any next OH release (hypothetically, you said yourself that’s your long term plan) then NO user would have the choice anymore to upgrade to that version and thus take advantage of any of its improvements beyond your works when he’s unwilling or unable to switch to your new, incompatible way of configuring the things he needs to configure.
That is by no means acceptable.
OH is about user choices. In devices and UIs.
File input format has it’s advantages over interactive GUI input, call it v1 but that does not mean it’s outdated technology or inferior to PaperUI. Modern is not necessarily better. It’s an alternative. The only one. Many feel it to be superior. It’s the one that most power users are using today, it’s the one most available documentation is about.
Noone demands keeping Xtend or whatever part you want to eliminate for good reason - we just insist on keeping the existing file input format and functionality (and I mean full backwards compatibility, not a new “equivalent” like YAML) to work.
That’s wrong perception. Adding options is fine. Improving on functionality, speed etc is, too. Noone opposes.
But dropping options people use and inflicting to instead use what you prefer is NOT ok. Like it or not but there’s not many GUI lovers here.
Maybe we just misunderstood on that part but I feel you made it clear that your development will not provide a compatible text alternative, so you want to take away what we use and are used to today (maybe in the beginning that would just apply to new functionality but already that is unwanted, and long term it would apply to all configuration). That’s the red line you crossed.
Better put your efforts into building an alternative that is so convincing that people like to migrate all by themselves. When you’re done and it IS convincing and they HAVE moved then you can start removing, but no sooner.
4 Likes
I need to repeat myself for the third time now, but ok: It is IMPOSSIBLE to maintain all alternatives.
As you have seen with my MQTT binding, I only really cared about “new” ways. Because it was developed in my free time and I don’t have the capacities to look for all old-school ways, too. So I naturally overlooked a bug that only happens on textual configuration.
By the way it was not my decision to uninstall mqtt1 automatically.
And with a new improved Paper UI, usage of text files will gradually die out. That’s simple a fact gathered by observation. Most new people are only using text files because of copy/paste, tag support. Not a problem in the future. It is really just the “stubborn” don’t-take-away-what-I-already-know OH1 folks, that don’t try to find a compromise here.
Please take it as a fact: The current .thing / .item files will go. They need a replacement that requires less maintenance. Software evolves. Look at Microsoft and Google. They start and shutdown projects in rapid cycles although they would have the money to support an older approach for longer. We have NO money for developers here in this community and still developers should support everything down to OH 1.0 or how do you imagine this?
No. It’s not what we know, it’s what’s easier and faster and better.
4 hours clicking to create all my doors and windows in mqtt with paperUI or 20 minutes with a text file. I know what I prefer and it’s not a fancy UI
2 Likes
Vincent, please. You have read the first post, haven’t you?
The GUI will include a text mode for all benefits that you get with a text editor. The text is just not exposed as “files”. But even that would be possible with WebDAV. OpenHAB can very easily present “virtual” files to all WebDAV supported software (including the Windows Explorer). It is just the problem that you may overwrite a change that was just made by openHAB, so I don’t see this as a real solution.
That’s why I’m promoting the “Import”/“Export” mechanism without file watches. The user has full control WHEN the data is imported and gets a detailed response like in “Line 12: Thing conflict … bla”.
Fully agree.
I am not jumping on the David against the world train
and will try to be constructive and bring back some objectivity here.
Configuration via text:
I love that and for me Paper UI is a place where i can install addons and sometimes add things.
Not more, not less.
Yep i’m a text guy too. (Sorry David^^)
Even worse: I have never seen OH 1.X in my environment.
I have started with 2.X and still love textual stuff.
But here’s one thing i don’t like:
Switching between Paper UI, Basic UI, Android App and my textual files.
So yes: If there would be an UI that can handle textual configuration well, i would appreciate that.
But to be very clear here: We are not talking about some textinput field that shows the lines.
I don’t know about that Microsoft project, but if it is based on electron like vscode and we ahve the ability to extend it like we do with the current extension, this would be a vild alternativ for me.
(More about current text file formats in the next post.)
3 Likes