I can, but I see @rossko57 is already at it, and he´s the overaall expert in this
However I would suggest keeping the modbus issues in its own/new thread, or at least LordLiverpool post some logs and setups/more info… “Getting tons of Modbus commenication errors” doesnt really help anything
Correct. PaperUI also interacts with OH core through the REST API.
I recommend modifying the JSON DB entries using the REST API. The REST API Docs addon (under the Misc tab) is fully interactive meaning you can make the same calls that PaperUI does when creating/editing stuff. At a high level it’s usually a:
GET to get an example Thing/Item/Rule or get the JSON for the specific Thing/Item/Rule you want to edit.
Edit the JSON as desired.
A PUT (edit) or POST (create new) to apply your changes or create a new Thing/Item/Rule.
They can all be done through the API Docs or you can use curl
When you do it this way you get some error checking so if you mess up the JSON syntax or something it tells you before modifying the JSONDB. Also you don’t have to stop openHAB to make the edits.
Not quite. OH loads the config from the JSONDB first into memory. Then it loads the config from $OH_CONF into memory. From that point it operates off of the combined stuff loaded into memory. This is why anything that is in $OH_CONF will take precedence over anything done through PaperUI.
JSONDB is just a way for OH to write out the config changes made through the REST API (e.g. PaperUI) so it persists after OH is shutdown.
tl;dr: OH has two independent methods for defining and preserving it’s configuration: JSONDB and text files. JSONDB configs are read first and the text configs read next. Both are loaded into memory and available for use by OH, but it’s memory that OH is operating on. Configs in text configs are read second and therefore override those in JSONDB. Internally, OH encodes the information about Items/Things/Rules as JSON in response to REST API calls, but that does not mean that it’s all in the JSONDB. For consistency though, the same JSON format is used in the responses to the REST API calls as is used to store them in the JSONDB itself.
(Stuart Hanlon, UK importer of Velbus hardware)
That makes perfect sense now and explains a few things I was misunderstanding.
The main one was (Which is obvious now) …
Why does openHAB need to shut down… BEFORE creating a backup, if everything is stored in the JSON & Text files.
While OH is running, the JSON files are dormant?
So a backup wouldn’t contain any recent changes
Also explains why an OH restart once in a while isn’t such a bad thing.
Pretty much. Periodically OH will write out to the JSONDB. I’ve not looked to see whether it’s every so often or just when something changes to the config (e.g. added a new Thing). But any operation you do through the REST API which results in a change that is stored in the JSONDB, it will immediately write that change out to the JSONDB. And when it does write out the JSONDB, it will create a backup in the $OH_USERDATA/jsondb/backups folder. I’ve not looked at them to try and correlate the backups with changes made to see if that is the only time it writes out or to the JSONDB or if it also periodically writes out stuff at other times too.
This is also why you have to stop OH if you manually edit the JSONDB files directly. OH might turn around and overwrite your changes. Also, I’m not sure if OH reads in the JSONDB files when they change, it might only read them in during startup.
If you attempt to make a backup while OH is actively writing to the JSONDB, the backup would almost certainly become corrupted. I think stopping OH before taking a backup is to ensure that doesn’t happen.
It’s not necessarily a bad thing for lots of reasons (I know Markus disagrees) but I don’t think the JSONDB is part of it. It is more for dealing with orphaned objects (i.e. memory leaks) and other cruft that builds up over time when there are minor bugs in the code. No one writes perfect code.
In fact, from a JSONDB perspective it could be a risky thing as if the machine loses power or otherwise stops before OH has finished closing down the JSONDB might be incomplete or otherwise corrupted. I personally have had cases where I got impatient and issued a kill -9 on OH and ended up with a blank JSONDB file. Luckily there was that automatically created backup to rescue me.
I decided to get on with trying to move the logs off the SD card. Ultimately I plan to use a USB drive, but while waiting for that, I decided to use an old 2.5" hard drive I had lying around. Grappling with the obscurities of fstab in order to mount the drive was hard - I managed to render the system unbootable, probably by forgetting to create the mount point first, or perhaps by omitting a line break (a little more resilience wouldn’t go amiss methinks). I rescued it by using Ext2Fsd under Windows to restore my backup of fstab. I followed a better tutorial and got the drive mounted successfully. I worked out that the fmask and dmask options were preventing the drive from being writeable, so I fixed that and pointed OH’s log settings to the drive. Unfortunately, nothing is being written, either to the standard location or the new one. Not sure why yet.
For the record, when using openHABian you can use openhabian-config to set up ZRAM which will put all the openHAB logging into a compressed RAM file system which prevents those writes to the SD card. I think it might even write persistence (MapDB or rrd4j) there as well.
If your only concern is the logs, that would be an easier and less complicated approach, particularly since is built right in to openHABian.