Next generation design : Ideas & Discussions

Development Misc
81

nothing said in this conversation should be construed to mean that progress on PaperUI will slow down or stop. It will progress at the current rate or perhaps an accelerated rate.

This conversation is about how to not abandon those users for whom paperui and other GUI based configs are unsuitable for their needs.

Since you are a developer, have you considered contributing to PaperUI development as well?

Ah, but the loss of advanced users can have a far higher impact then just the loss of a user. we also lose contributers to the code, the docs, and the forum. And those beginner users are on their own when they out grow the UIs.

I’ll say it again. nothing in this thread should be construed to have any impact what-so-ever on continued development and improvements to PaperUI.

Home Automation enthusiasts are control freaks. :joy: Is what we do and a major motivation for why we do it.

except we don’t have a library to write out in that format. One could be written I suppose but I think it would be wiser for long term maintainability to use a file format backed up by a standard with library support.

I’ve not had time and don’t have enough Things to make it personally worth while, but I suspect a script or subversive could be written to push the contents of a .things file to the REST API. The biggest problem is each binding will need its own script. But would we really need this for bindings that autodiscover? It might be a smallish list.

I have no problem with the batch import but do have a problem with using openhab-cli. Users running in Docker or jails on Qnap or Synology and the like will not have openhab-cli.

@David_Graeff, perhaps a REST call in addition to openhab-cli would suffice.

:+1 This is a very good point.

Items wouldn’t be too hard. But every existing 2.x bidding would have to implement their own export for Things, if I understand it correctly. It would indeed be quite a lot of work and we are still stuck with a proprietary file format and all the problems that brings.

82

Gosh I liked Martin’s post but had to quote this paragraph for truth
Focus people
Define the problem first
then design an architecture to suit task at hand

1 Like
83
  • Have Things/Item files sitting in a directory, probably the same like now

just to be sure that is /etc/openhab2/ + subfolders right?

No file watches but a dedicated “openhab-cli import” command.

I assume this can be called from a button?

For me, one of the things that I need is this:

I update the text file on my computer from anywhere in the world.
I commit it to a source control system
A person at home presses a button on openhab:
it downloads the text files to the openhab folder
where openhab reads it.

This last step is now automagically, yet I could live with something that we trigger (in the same function that gets the text files from the source control system.

A write-back mechanism (openHAB will touch your files, and replace all Things that it knows of) by issuing “openhab-cli export”. Things will have a “storage” association (aka filename). If they haven’t got one, they are stored in things.things.

What is not clear to me in this description, is this done automatically or does this happen automagically/unpredictable/ all the time?
I’m asking because if it update these files that are in the source controle, they should be pushed to the source control before they can be downloaded, and that might give merge issues that not everyone in my family knows how to solve.

The file format would change to yaml. (Otherwise we can’t have the write back)

I understood that, it feels better then json because the order to stays (if I got it right)
we might want to hear more people’s opinion to hear if there is nothing better, yet for me it feel better.

84

Before discussing how information is stored and what kind of textual formats should be used we should define the functional requirements more from an end user’s perspective.

When I asked for being able to work from a text file, that was an end-user requirement.

When I look at this discussion I see/hear a lot of expert users, who like to define their system from some kind of text files.

@juelicher gave a very detailed list of why he wants that.

yes some of these people are developers of OpenHab, yet what I see is that the request are mostly asked from a end-user point of view.

Yet I also agree we should not forget the first time users and what they need.
And I do think their needs are a higher priority now.

85

Absolutely right.
It does need to get easier to get a basic system running.
It has got much, much easier since the days of 1.7 (When I started)

The text configs must remain for in depth customisation. there is no other way.

Talking about new users, are there any stats about how many download and cloud users openhab gained in 2018 vs previous years?

2 Likes
86

Hm I don’t agree. You can do everything with the rest API and the openHAB internal state can be completely influenced by rest and the console. Files are not necessary not even for “advanced” users. What differentiates them from beginners is their knowledge in scripting not in how to write files with a strange syntax.

1 Like
87

As the order of items in a Json file is undefinied, I am not sure if this is just a coincidence and might change with a newer version or if it is really guaranteed by the backend.

In this case I probably would not have selected openHAB in the first place. I also own a Loxone Miniserver and I stopped using it for exactly this reason.

I agree with that and think, that this is a very important aspect.

2 Likes
88

But I don’t want to use rest or the console.
I want files that I can save, back-up do whatever
I want config files where I can copy and paste what I want

No you can’t, No API ever keep up with the development of features.

2 Likes
89

Yves,

just for the record the quote in your post was actually me quoting Marvin. here is original statement

Edit to add:
I believe you knew that, just wanted TL DR folks to know that wasn’t me making the statement

90

I know, yet you continued on that, I can’t answer to both so I quoted the last one

91

cool, no problem, I think we agree :wink:

92

Hm. And files keep up? Depends on developers don’t you think.

93

Exactly my point

94

Let me add a bit more to my yesterday’s post telling you from my own experience when I started with OH.

I started with OH2 mainly to use it as a better front-end for my HomeMatic devices with the option to remote access my installation. So I setup OH 2.1 on a Raspi and used PaperUI (like a new user would do). In order to get everything running I had to perform these steps (manually, one after the other):

  1. Install the HomeMatic add-on
  2. Add thing for the HomeMatic bridge (auto-discovery for the bride was not available at this time)
  3. Now auto-discovery started and found all my devices (great!)
  4. I had to click on every device in the inbox to to add it as thing
  5. Unter Configuration/Items I have selected a thing
  6. Clicked on the channel I needed and created an item
  7. Go back to step 7 until all items for this thing were created.
  8. Go back to step 5 until all items are created.
  9. Now open a text editor and create a sitemap (this is now something completely different because there is no no editor in PaperUI)
  10. Install the openHAB Cloud Connector
  11. Configure the connector
  12. Create an account on myopenhab

Quite a lot steps, especially the creation of items by “simply” clicking is not really funny, especially when you make an error and have to recreate an item.

Then I bought a Google Home and wanted to use my items with the assistant. But it is not possible to add the tags in PaperUI. No problem, I have created a small items file with only the items I wanted to use.

Therefore when I set-up my new OH 2.4 installation I have defined all items in text files.

PaperUI is really nice and I use it for the installation of add-ons and the creation of things, but there are some features that I would like to see:

  • Multi-Select: e.g. select all things in the inbox that you want to add and add them with a single click
  • Possibility to create items more automatically, e.g. create items for all channels named “temperature”
  • Copy/Paste (with some intelligence regarding unique names)

Another idea that could help new users to get started: if you start OH for the very first time you have to select an installation type. At this time we could display a list of supported products (= add-ons) and the user can select the add-ons that should be immediately installed. Maybe it make sense to ask the user whether he also wants to use the openHAB cloud or Alexa/Google Home and help him to get this things running as easy as possible.

4 Likes
95

The last point is something that others and me suggested pretty similar.
Ask the user some questions and help choosing the right package to start with.
The add-on installation would be an addition for this.

2 Likes
96

Meh…won’t be too long to wait :wink:

97

And the API is not useable as a frontend. Files are.

It’s always (new) function with a means to have input first and API last, and what will be chosen as the input means? Right, the existing one - files, that is. Even if you yourself were to proceed different and provide an input-via-API frontend first, other developers wouldn’t.

If you want to convince users then try thinking more like a user does.
We don’t mind if you change any internals. Replace Xtend or whatever you dislike with some Java code to provide the same functionality - i.e. parse the existing file format - we’d be fine with that.
But we do care if not to say get angry if you want to change a working, widely used interface for no convincing reason. As I already stated once that would be causing way more chaos than you believe it will.
Your proposals to date would mean that and therefore would be a worsening only.
I quite understand that there’s also a benefit that comes with that which I believe you as a developer see in reusing libs or dropping old/bad code. But note as well that these “benefits” are of no value to us users.

98

I’m a user too. You seem to forget that. And I hate the startup slowless of OH.

Because I’m also a developer I can fix that for my personal setup by throwing out the .thing and .item file parse bundles. But I have to maintain a personal fork of openHAB. And I’m just asking here if anybody would also be willing to use openHAB like I do:

  • With a graphical interface, but a text mode for copy/paste and easy cloning. The text mode speaks yaml though, I will not write a JavaScript parser for our current syntax.
  • Items are fully created graphically. I have over 100 items. But with an advanced GUI I can sort, filter and multiselect them so don’t need artificial file boundaries to create the illusion of “order”.
  • Rules are written in jython and JavaScript if complex, and easy ones are created graphically.
  • I absolutely don’t care where exactly (in which file) openHAB stores my data. As long as I can press the export button to copy the current openHAB state as yaml files to a git repository.

I guess newbies will also all use this way, but some users don’t want to change the current file situation. That’s alright I guess but personally I will stop any file support. There were so many people struggling with file syntax during the mqtt2 transition. So much support necessary because of that ancient interface.

Cheers, David

6 Likes
99

Well until now you didn’t offer any user benefits so for the time being you argumented like only a developer does.

I have been and keep hating that startup slowness, too. But there’s more than one reason to it (ESH#1896, ESH#6410, ESH#6805 and probably more) and to all of these a cure is possible WITHOUT dropping support for the current file format.

That argument goes both ways or even against your pov.
People to have trouble with MQTTv2 were not first-timers but had MQTT working in v1 and wouldn’t have had any trouble if they hadn’t migrated. Trouble started because the interface was different and v2 isn’t backwards compatible with v1.
And you didn’t remove MQTT1 support while here you want to abandon file input for the existing format.

100

A textual representation as an alternative to the graphical interface would IMHO be a good solution. But why not stick to the current syntax (for .items, .things)? The parsers already exist even with an LSP API.

YAML is a readable format but I don’t like editing it. Today I set-up an ejabber server which also uses YAML for configuration. YAML has got a very sensitive syntax. You have to take care of correct indentations, spaces (after colons), hyphens etc. If you want somebody to edit in YAML-format you would have to provide an editor that checks for correct syntax (and semantics) on-the-fly.