Hello,
Is there a raccomended way (order?) to delete things via PaperUI?
For testing purpose one could create a lot of things/items (with a lot of channels), when it’s time to delete all this stuff which is the best order to proceed? because sometimes item deletion does not happen immediately and paperUI seems to act a little weird and I need to refresh the page to start over.
Should I first manually unlink all channels and then delete the thing and after all the items?
It’s just enough to delete the whole thing without unlinking the channels?
Any other specific procedural order?
but personally I would recommend to use files (yes still), as PaperUI is pain to set when you need to reinstall whole system, since files are backed/restored in matter of minutes.
PaperUI config missing backup/restore and some proper reliability. I have had a lot of issues with mqtt configured via paperui, which went away when I switched completely to files definitions.
I recommend deleting the Links first, then Item, then Things. I’ve seen cases where the Link remains and that leaves the Item in a kind of zombie state. I’ve only found that it can be removed by manually editing the JSONDB file.
All of your Things and Items and Links created through the REST API or PaperUI get stored in the JSONDB (e.g. /var/lib/openhab2/jsondb). On every change and periodically, those files are automatically backed up by openHAB (e.g. placed in /var/lib/openhab2/jsondb/backups).
When running openhab-cli, both /etc/openhab2 and the contents of various files in /var/lib/openhab2 to include the config and jsondb folders are included in the backups. These can be restored using openhab-cli restore.
When you use openhab-cli (or manually backup the userdata folder (i.e. /var/lib/openhab2) minus the tmp and cache subfolders) the restore is exactly what you would expect. All bindings get installed. All configurations, whether made in the conf folder or through the karaf console or the REST API get restored. All Things and Items and Rules and whatever, whether it was defined in conf or through the karaf console or the REST API get restored as well.
I believe (but would need to verify) that openhab-cli also backs up important files from individual bindings (e.g. zwave and MQTT 2.x both have folders in userdata) and embedded persistence files (e.g. mapdb and rrd4j files).
If you use openhab-cli backup/restore you can backup and restore your entire OH, not just it’s Rules, Things and Items, in a matter of minutes. When you use the REST API or karaf to create Items, Links and Things, those changes get backed up as you make them
That’s interesting as for the majority of people who post problems it’s the opposite. They have problems with the .things files which are solved when moving to configure through the REST API (e.g. PaperUI).
Thank you both for your answers, I will stick to paperui as I find the backup and restore process easy with the openhab-cli and then is my understanding that text file could be deprecated in medium/long term.
Rich suggestion seems compatible with the weird behavior I experienced…so I’ll follow your advice thank you!
Can I ask why you think this? I haven’t gotten that feeling at all from my readings. I think we need to be careful when speculating on what the future may hold for OH, as there are some very strong opinions that have been expressed in the community (particularly around rules).
There were several very long and contentious threads. There is a strong push by at least one maintainer to do away with text based configs. I don’t think text based configs will go away, but I would expect them to change syntax/format at some point.
There are some good reasons not to use text configs right now despite the awkwardness of using PaperUI. These mainly involve the amount of time it takes to load them at boot time and problems with loading order where Rules can start executing before all the .items files have been loaded. I believe JSONDB loads first and it loads super fast.
Okay, good to clarify. As @rlkoshak mentioned, there are very long and contentious threads that I don’t recommend reading. I just didn’t want your innocent comment to turn this thread into another debate that none of us would enjoy.
@rlkoshak, I wasn’t aware of those advantages in PaperUI for rules, though I was familiar with the issue of loading order on bootup. Thanks!
that’s the issue really, what’s the point of GUI admin when one needs to go to console anyways to find out some -cli and do backup/restore there?
I’m not really complaining, as I can deal with it in different way, but backing up whole conf folder mounted by samba is really no comparable with some ssh tricks.
I’ve seen some paperui design upgrades somewhere, which looked very promising, but again copy&paste and edit few variables when i want to add new sonoff is way easier than clicking in paperUI.
Which honestly is not really intuitive yet.
actually no not really.
I’ve done it 2days ago, and after instalation I’ve had whole OH up and running in 5minutes.
Yes you have to know which addons you need to install, but it is not bad thing sometimes, because restoring 2.5 snapshot to 2.4installation … dunno what that will do.
btw speaking of paperUI… there are still areas which you (to my understanding) cant really do in paperui, which are sitemap and rules.
If am not mistaken?
You should be using addons.cfg then. That will install the bindings.
As part of any restore you should always Clear the Cache. That will cause OH to reinstall the bindings for that version of OH. It works both directions. And openhab-cli restore does this step for you.
