Running Openhabian with 3.4.2. Recently noticed I can not install or even view bindings in the GUI. I’m running 3.4.2. I did an upgrade to 4.x but I have lots of work to do on config to get it working right. Is there a common problem with missing add-ons? Has it been blocked for 3.x in favor of 4.x?
Any insight?
Thanks.
All I can offer is this is not a common issue and add-ons have not been blocked for OH 3. Beyond that I can offer little else. Maybe there’s an error in the logs that is informative.
Yeah I started digging into it more, I have a problem with the MainUI/Pages preventing me from moving to 4.x. I posted about that. If I can solve that problem I won’t need to fix this one. But was hoping somebody had a quick “hey I know that” answer to buy me a bit of time.
I think it got caused by package mis-matches on an update that might have tried pulling in some of the 4.x packages even tho the core is on 3.4.2.
That type of problem should be solved with a clear the cache.
Yeah I did that. But it results in the already installed bindings disappearing, and not getting re-installed. (this is why I image my SD cards before doing any updates/changes).
I’m on the edge to getting off OpenHabian, and moving to either docker or native openhab. I’ve already moved my Zigbee (40+) devices to zigbee2MQTT on a seperate PI, and moving my 150+ Z-Wave devices over to Z-Way.me on it’s own Pi. This was done to help mitigate the impact of failures when everything was on a single platform.
This is one of the many reasons I love file-based config. I have the list of my addons inside services/addons.cfg, my things/items in conf/things, conf/items, and all my rules in conf/automation. So I just need to worry about backing up conf/ folder. Everything else can get nuked, even userdata/, although I do back it up just for convenience. Yes userdata contains mapdb and rrd4j persistence files, but I don’t really care if they get deleted.
How did you install your addons originally? If you installed them via GUI, the settings are stored in userdata/jsondb.
It also contains certificates, users (both karaf accounts, and MainUI accounts), logging config, and many bindings store important information in userdata as well (e.g. zwave). Lots of global OH configuration settings done through the UI (e.g. which add-ons to install, timezone, regional settings, etc.) are stored in userdata/config.
Whether you install add-ons through addons.cfg or through the UI the file that controls what OH actually installs is in userdata/config/org/openhab/addons.config. That along with other configuration stuff like regional settings default unit system, location, timezone, default persistence, etc. are all stored under userdata/config.
When changes to these settings are made through the UI, that’s where they get saved. When those configs are defined by .cfg files in conf, periodically the conf file is read in and the userdata/config file is updated. But it’s that userdata/config file that is what Karaf/OH uses.
There are rare cases where the transfer from cfg to config gets messed up so the first file to check regardless of how you configure OH is the config file.
This is mostly to do a checklist for myself:
That’s generated from conf/services/addons.cfg when using file-based config. Everything inside userdata/config is disposable, except cloud connection credentials which can be regenerated anyway. I have absolutely zero concerns over anything inside userdata. It’s needed for keeping runtime states, but for backup purposes, it’s not critical.
OK, maybe one thing is precious inside userdata: the Pages created through MainUI, I do have one page. I’m working on turning that into file-based too but for the time being I’ll copy paste and save the yaml… into conf/misc/
In any case, it wouldn’t hurt to backup userdata alongside conf and I do this anyway. I did delete my userdata completely when I upgraded from 3.x to 4.x.
This isn’t config so much as stuff that the binding creates and stores itself. For example, if you restore a backup and don’t have the userdata/zwave folder, you will have to re-wake up your battery powered devices so that OH can rediscover what they are.
Obviously this doesn’t apply to everyone but I want to be clear for future readers that even if you do everything in conf, there might be stuff in userdata you need to back up too.
It’s generated by the binding so you’re only option is probably going to be to have a script to copy it over from conf to userdata on a restore. Or modify the add-on to look for them in a .cfg file.
My point was though that sometimes something can go wrong in that translation so when problems occur like OP has, looking at userdata/config/org/openhab/addons.config is the first place to look. I’ve not seen it in quite some time (maybe because fewer use addons.cfg?) but it used to be a common problem where changes to addons.cfg didn’t get translated over properly (often stuff that was deleted didn’t get deleted from addons.config) so it’s important to check the config file first.
As far as I’m aware, to do that properly will require changes in core as there is currently no way to load pages or custom widgets from anywhere but JSONDB.
If you do go down that path, I’d encourage you to coordinate with the YAML Config PR that started work on creating a file format that more closely mirrors what we see in the Code tab. I wish the part that’s done (i.e. creating new semantic tags) had been merged before OH 4 release.
Found a fix for my problem. Recreated it twice from SD backup to verify.
I was able to restore my ability to view and reinstall addons. I kept getting corrupt bundle errors
This worked for me. I did it twice on SD card images to verify. Maybe this will help someone in future.