Okay very cool 
thanks for the explanation
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 
Btw. fir this Crash I found a possible causeā¦seems tahoma has Changed their auth-rate-limit: Tahoma Binding compatible with OH2 - #541 by Lolodomo
Ist it possible to Limit the momory per Binding? Or isolate a Binding in some was? So ist doesnāt Crash the whole Installation?
@Ondrej_Pecta die Others Had a Crash of the whole Installation? Btw. Thanks to all of you helping the Community
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ā¦
Okay I Seeā¦I use Rpi 4 with 2gb of memory and a little extended heap-sizeā¦
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.
No.
1 Like
How would an āoptimalā Cron Job look like for OpenHab in docker-compose?
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.
Okay very cool thanks =) I thought there might be a āsoft restartā or something like that, that just dumps the memoryā¦