By default, the add-ons are installed on demand. Only if you install openhab-addons via apt or download the kar file manually and drop it into openhab’s add-ons folder are all the add-ons downloaded and installed. In all other cases, the add-ons are downloaded on demand.
The zipped up manual package that includes OH core only is just under 100 MB.
I’ve not seen any suggestions this far that would increase the size of openhab-core in any appreciable way. Between OH 3.3 and 3.4 there were over 100k new/modified lines of code. The size difference is negligable.
Maybe I have been doing this wrong. I was using apt update/upgrade and the full kar file was downloaded into the addons folder. I guess I’ll have to read how not to do that. Thanks My wish is granted
Since the first version of OH I have been using only text configuration for rules, things, items, etc.
The backup is straight forward and hassle free.
My Xmas wish is that TEXTUAL CONFIGURATION will be always mainteined and enhanced including every single part of the system (i.e. addons like it was in OH2).
Another Xmas wish is to enhance the sitemap capabilities to enable more features (i.e. dialog boxes, push (momentary) buttons, etc.).
Since we all can add wishes, no matter how realistic they are, here is my wish: openHAB completely drops textual configuration and makes DSL rules an add-on. That way we can rid of Xtext/Xtend in core. There is absolutely no need to make it more complicated than necessary and the need to retro-fit everything to DSL and textual configuration makes introducing new features a PITA.
Well as you probably guess I’ll have a wish, too:
I’d wish textual configuration will get a proper parser which can model metadata properly.
And I’d wish the fight about the preferred configuration method will finally cease and both methods can coexist.
Also I’d wish for
a better differentiation between runtime data and configuration data
A userdata folder that can be deleted to get a fresh openHAB installation
HABApp becoming a first class citizen with better support
Nothing - HABApp should not be included in the distribution.
It’s a separate project which has to be installed separately.
I’d wish for a perception shift.
I’m under the impression that sometimes HABApp is being viewed being as more or less annoying attachment to openHAB.
I’d like it to be viewed as a chance to make openHAB a better experience for people that want to create rules in python.
To clarify:
This is not an attempt to blame anyone. Especially not you @J-N-K . Even though we disagree on some issues you have been nothing but kind and helping me out tirelessly.
This is already possible with Docker. It might be possible to port that approach to be more generally applicable. It works by looking to see if certain files exist in userdata and if not backs up what’s there and creates a brand new userdata folder in the script that runs to kick off openHAB inside the container.
I am missing a csv export at least for the most important entities like things and items including all their “attributes” like name of channel, tags, state descriptions, semantics, groups, etc (for items). An export for rules would also be nice.
This will make housekeeping much easier.
For example if you want to do mass updates on your item’s label or want to double check if you have added consistently the correct tags to your items, it was easier to do it outside of openHAB, e.g. in Excel and upload the xls file for updating your items.
fairly easy: if you have 1:n related information to an item (like groupsNames, tags) simply insert a delimiter seperated string into one cell or add as many columns as required.
I have seen that my previous post was somehow cut off. I have added the rest which makes my wish clearer.
But it’s not a 1:n, and that’s the point. For example, 1 Item could have N Item metadata. Each Item metadata can have a config and that config is a dictionary of name value pairs. The csv becomes pretty unusable pretty fast.
But for reference, there are many JSON to CVS tools available. This is the list of columns for my Items:
How about mapping the internal data to files in a directory so that the user can just zip the files without exporting.
And after editing the user can place them in the same directory and they will automatically get loaded again.
Edit (so this is not only a joke post):
Exporting into *.items / *.things / etc - files would actually be quite nice
Base framework configs are in userdata/etc (stuff like logging config, users, etc.)
individual component configs settable through the UI (not Things, top level configs like locale and such) are in userdata/config
all entities (Things, Items, Widgets, Rules, Rule Templates, etc.) are in userdata/jsondb
embedded persistence is in userdata/persistence
openhab-cli backup will grab all of these folders (as well as some custom ones created by individual add-ons). So the first part I think is already supported, i.e. creating a zip with all the files without exporting.
Restore is not as straight forward because OH has to be stopped.
That is exactly my point. Yes, it IS complex. YOU have huge knowledge and know what/how to do and work with additional tools to help yourself. But I think this is about a wish list and these wishes should make life easier also for USERS.
Let me give you an example:
If you want to have an overview about all your items with metadata defined, you’ll need to import both org.openhab.core.items.Item.json
and org.openhab.core.items.Metadata.json
into a separate database (or tool) and you need to link them by itemName.
You keep teling us that items do not cost anything, which is a good advice - don’t get me wrong. But if you end up with some hundreds of items and you want to maintain your system, it is easier to have a download/upload facility for housekeeping stuff. And that housekeeping, I truly believe, is important to the maintainability of your system.
Coming back to
Let’s do not complicate things at the beginning and go away from a technically correct 100% export mechanism (this is where you are 100% correct).
In cases where we just have a 1:n relationship (like tags or groupNames) a csv cell will be fine. In cases where we have a more complex structure underneath (like command options) the whole json string will do at the beginning.
It was actually meant as a joke post because the feature is quite similar to textual configuration.
It’s not exactly the same but there is a rather large overlap.
Many of the arguments by @Oliver2 are the exact same arguments users of textual configuration make
Obviously this export feature only makes sense if you can round trip.
So you’d also need an import function, too. We already can import from textual configuration, so why not just add an export to textual configuration.
tbh if I export something and import it again it would be nice if the data was complete and nothing is missing.
