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. 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.