I doubt there will be an exporter to .items and .things file formats. But I’ve seen some screenshots where you can get at a YAML version of rules. I would not be surprised if there is something similar for Items and Things. You can download and play with the 3.0 snapshot and explore the UI as it exists right now to see what is there and what appears to be planned for.
Personally, based on my experience with the HestiaPi, the stability and performance gains achieved by running everything out of the JSONDB text configs are worth even putting up with PaperUI and doing through through the REST API. There are no startup problems of any sort. No runtime errors. No Items unexpectedly going to NULL when changing a Rule. On the RPi 0W I took the boot time down from >30 minutes to almost exactly 10 minutes. In those rare cases where OH crashes while writing out to the JSONDB there is always a backup to restore to (unlike .items files which can be corrupted by a loss of power and there is no automatic backup there unless you set it up yourself). OH simply works soooo much better I just can’t see any advantage to using .things and .items files. When I move to OH 3, I’m going to be 100% in JSONDB. I’ll still have all my stuff checked into git and all the workflow stuff that everyone claims as advantages of text based configs and thus implying is not possible with JSONDB.
But I’m more willing to bend my personal workflow to match what best works for the tools I’m using rather than trying to impose my preferences on the tools. Many others are not willing to do so and I’ve no doubt that .items files and .things files will remain supported, or there will be a tool to translate them to a new text file format.
Thanks Rich,
Maybe you are right.
The first time I lost all my things I had to do everything from scratch and that’s extremely annoying.
For me (as a non programmer) it just feels better and seems to be more transparent if I have all my OH configs as text files on my PC, change them every now and then and then just copy the changed files over to my RPi with SCP.
Maybe I will learn myself that there are better ways - so let’s wait for OH 3
There are a whole lot of variables but in general this happens when openHAB stops/crashes when it is in the middle of a write. So the first thing to do is ensure your machine never just loses power. You might need to deploy and UPS. Always make sure OH closes down nicely, no matter how long it takes. Never just kill the service.
Okay I see… last time this happened OpenHab had a heap error…I then stopped the docker container and all things were gone…how can I shut down docker nicely when it hung up? I would also be for a CLI function for restoring
Well, if OH crashed with an error it’s already too late. OH isn’t going to be able to write out the files any more even if shut down nicely. In other cases use docker stop.
Okay I see… interesting is, that only the things database gets corrupted…how is it for the others? Did other databases also fail for you?
Thanks @rlkoshak for the explanation Another method of keeping things from that Event would be to define them manually over text…
Is there a way to export all things to Text? Or would I have to redefine them? The textual configuration is much more durable because it endours all kinds of shutdown…am I right here?
What are the best Methods to do that? Because recently I again lost the whole Database because of a Crash and I can’t find any hints in the Log, except the “Out of memory” issue…the Problem is I can’t locate the Binding causing it…also I have experienced that some bindings (Like Gardena) only thorws Errors wehen the Gardena API is offline → which leads to the memory exception
What would be such downsides? Because I’m getting really Desperate with that Database-loss …it was the fith time now, and now functions without Problems BUT I havent touched anything
I have never experienced any OH crash. As an author I have been using the Tahoma binding for years (with 15 devices) and no leaks neither crashes so far. But I need to mention that I have never used docker (only native install or lxc/lxd containers) and always run OH on an ubuntu LTS server with x86 arch and 4GB+ memory…
Well, that’s the cause. If it encounters an OutOfMemory issue while it’s trying to save out to the JSONDB files, those files will become corrupted.
There are several threads discussing OutOfMemory problems with OH 3 you can find with a search of the forum.
That sounds like at least on potential source for the error. You should file an issue on that binding.
As a temporary work around you can create a cron job to restart OH periodically. That should free up any leaked memory and prevent it from crashing, until such time that you can pinpoint the source of the error.
Especially for Things, the syntax is not well documented, is not well supported by the binding authors themselves, and people spend hours and hours of time fighting syntax errors.
For some bindings, there are certain things that simply cannot be done from .things files, such as setting parameters on Zwave devices
There are startup issues which have gotten better but still can be a problem with loading of config files.
You have to restart certain bindings from the console to pick up some changes to .things files.
They cannot be easily updated and modified remotely.
OH startup times are significantly faster.
Backups are automatically created
Certain things like Item metadata can persist past an OH restart when Items are managed instead of in .items files. When Items are defined in .items files, the Items themselves are destroyed and recreated anew every time the .items file is loaded. When they are managed, from a rule you can set a metadata property and when OH restarts, because the Item is not destroyed, the metadata persists.
I could go on. It is a little more awkward for some users to use MainUI, the console, and the REST API, but in my experience, any time gained by using text config files is more than lost in fighting syntax errors.
Cron is a wholly separate service that lets you run a command periodically. Look up tutorials for “crontab” and just run docker restart openhab or what ever the name of the container is as the command.
Or you can put that command into a script and drop it into /etc/cron.daily, /etc/cron.weekly, etc and cron will run it at that frequency.
