The change in the first number of OH versions means there will be many breaking changes. Stuff you may have used will go away (e.g. 1.x add-ons) or change. That’s the nature of breaking changes. Obviously the developers do what they can to help but ultimately it’s going to take some work. It’s never going to be as smooth or pain free as a second point level upgrade (e.g. 3.3 to 3.4).
Things I can point out which might be a problem so far (it’s been only a couple of weeks):
there might be problems if you are on an end of life operating system (e.g. Debian buster, unsupported versions of OSX) as Java 17 is unavailable and/or some of the system level libraries are too old
some things that just come with OH might require installation as an add-on (e.g. Nashorn JS), it remains to be see if it will be possible to detect that you were using it and install it automatically.
I’m not sure what running in a Docker environment has to do with anything. If you are doing a standard configuration as outlined in the docs, you have volumes mapped for both conf and userdata. All the UI configured stuff is in userdata (and it’s all text too).
I’m not saying you should change, but if Docker is the only reason, it’s not a valid one. There is nothing about UI configs that are harder or easier in Docker compared to text configs.
I understand and don’t get me wrong, I am very happy with all the hard work of the developers. Just consider it an item on the wish list. For now your list is reassuring. It already helps if people make these lists, that way others (users and developers) can think about how to mitigate the impact.
Let me elaborate a little bit:
For me, Docker is mostly about having the possibility to move from one environment/host/node/whatever somewhere else, start it and have the same result as you had before.
The textual configuration in the /conf folder can easily be moved over (for me I’m having those in a git repository).
However there are lots of files in the /userdata folder that are not specific to my configuration, but just general stuff that OH needs to run. Logs go into that folder too and you would not want to move those to a clean install, would you?
In addition OH won’t perform its first-start-logic if there is something present in the /userdata folder.
In the end it is not about the format of the files (.things, .items, … vs .json), but about their location.
Non-interactive batch import/selective export for things & items ? I have no clear picture yet, just thinking out loud.
It would not be exactly textual configuration but almost, bringing text config’s benefits such as scripted generation by provisioning tools and external editability to MainUI, ideally obsoleting today’s still existing need for OH1/2 Xtext based config files.
Yes I would, many of them anyway. If I’ve made any configuration changes to add-ons, my locale, default units of measurement, etc. I need the contents of userdata/config. If you don’t include that you’r backup of the OH config is incomplete. If you’ve changed your users, logging, want to preserve your uuid and secret for the cloud connector, those are all in userdata too.
If you are truly trying to preserve your configuration than you don’t want the first start logic to run, except in the case where the userdata folder is for a different version of OH than what is in the container, in which case it will back up what’s there and do the initialization/upgrade steps necessary.
You can force it by changing the version number in userdata/etc/versions.properties to be different from the version of OH in the image if you really wanted to force it to run.
Were I to try and approach that today with OH right now I’d use JSON and the REST API to push such configs. That should hit much of the requirement. Of course, as I said before, working in JSON directly is pretty miserable but if you built it up initially how ever you choose to, export the JSON from the API and then it wouldn’t take much, could even be a shell script or a small Python script, to mix and match the JSON and push it back into OH. It probably wouldn’t be too hard to figure something out in MainUI itself for this as well given there’s no new REST API endpoints required.
But I think this idea has additional use cases. One of the biggest complaints a lot of people have is how hard it is to bulk edit in MainUI. And while it’s true that this is a relatively rare activity most end users will face, it would still be a nice feature to have.There might be more.
I have worked on this in the past week, and according to some user feedback, there are some improvements, e.g. JS Scripting performance problems compared to Nashhorn - #17 by MikeJMajor.
Unfortunately, I am not really able to test myself, because I am running openHAB on a more powerful machine with a decent amount of RAM.
I would be happy to get some feedback how the current SNAPSHOT performs on smaller machines like Raspberries.
The language, region, etc. can be set in /conf/services/runtime.cfg
##################### LOCALE ####################
# The default language that should be used. If not specified, the system default locale is used.
# The ISO 639 alpha-2 or alpha-3 language code (if there is no alpha-2 one).
# Example: "en" (English), "de" (German), "ja" (Japanese), "kok" (Konkani)
#
org.openhab.i18n:language=en
# The region that should be used.
# ISO 3166 alpha-2 country code or UN M.49 numeric-3 area code.
# Example: "US" (United States), "DE" (Germany), "FR" (France), "029" (Caribbean)
#
org.openhab.i18n:region=DE
org.openhab.i18n:location=123,123
org.openhab.i18n:timezone=Europe/Berlin
I have a script in /etc/cont.init.d to read the UUID and secret from an environment variable which I set in docker-compose.yml
#!/bin/sh -ex
if [ ! -z ${OHC_UUID} ]
then
mkdir -p /openhab/userdata
echo ${OHC_UUID} > /openhab/userdata/uuid
fi
if [ ! -z ${OHC_SECRET} ]
then
mkdir -p /openhab/userdata/openhabcloud
echo ${OHC_SECRET} > /openhab/userdata/openhabcloud/secret
fi
I’ve set up all addon installations, user logins, settings, etc. so that everything is set up automatically just how I need it. If I need something changed, I can just change the files in /conf and /etc to restart/recreate the container.
I would like to improve the usability of the UI a bit.
I personally do not like to change between mouse and keyboard so often and prefer to work with the keyboad only as much as possible.
So these features would be nice
WebUI:
when I am in a selection list (e.g. category for an item) and only a single element is left after entering the filter text, it is selected automatically when I press
when I press in any window popup, the popup is closed
what about key shortcuts
when I’m in some page that allows editing - pressing “e” goes to the
when I’m in some page that allows “back” - pressing “backspace” goes
when I’m able to “save” changes +S will save the changes
… to be extended
when I press “reload” in the model page I’m still seeing my currently selected item and not the root
widget develpment:
currently the list of properties available with items[<itemname>] in custom widgets is limited to (display)State. I would like to also have
** Name
** Tags
** metadata
and then counting those that would be solved by a solution for that PR, I conclude: It’s a lot. I know it’s like wishing for socks, but both developers and users would benefit from this. Users would experience fewer breaking changes, and developers would be more free to get rid of technical debt without having to implements all sorts of work-arounds/backwards compatibility tricks and provide distro PR’s announcing yet another breaking change.
I’ve already updated my post where I have all of my wishes, but here’s a couple more basic ideas around the UI and context awareness. Mostly useful new new people, but still useful
A simpler way of using the state description pattern through the Main UI to pick, choose and display units, that do not require using special characters. E.g.: if I want to display my units in watts, let me choose through a list menu, drop-down menu or similar, and have the unit automagically appear in the item/dashboard/mainUI etc.
Linked to previous topic:
Add a link to the relevant documentation to help those who might not be familiar with it.
E.g.:
1.) metadata / state description : link to UoM documentation
Like so:
Which relevant rules page? There’s more than one already and there’s going to be more. The rules controls page? Parts of the Getting Started Tutorial? The readme for the automation add-on?
Fair point. So I’d expect each one of those rule pages will have (or already have) a relevant page in the documentation website. What I’m asking is for these pages (relevant for each rule menu you just pointed out) to be linked (somewhere, maybe a ui icon in that same page? Something a “help” icon.) in the main UI menu itself.
that way the relevant documentation is linked in the main ui itself.
Hi Rich,
thanks for your answer, but for me it’s not clear what are you referring to. I know “createtimer” + “expire”. Createtimer is lost after a reboot, expire (as far as i learned from several threads) is recreated after a reboot, but it starts completely new and not only the remaining time. May I ask you to give me additional hints?
I’m not sure how to make it clearer. Maybe step-by-step.
Create a DateTime Item which stores when the timer needs to go off.
Create a rule that has the code to execute when the timer goes off.
Add a trigger to the rule to trigger it based on the state of the DateTime Item created in 1.
If you have a customized persistence config, make sure the DateTime Item created in step 1 gets restored on startup.
The rule will run at the DateTime stoked in the Item. Persistence will restore the state of the DateTime so that the rule will run at the scheduled time even after a reboot.
This brings me to two interesting points I think about when talking abou a wishlist:
Up to now we have unchangable identifiers for things and rules and names for items, … Understandable from a technical point of view, but a pain when an installation grows over the time and naming conceps may have to be thought over. A big step to solve this situation would be to implement a third level between given, unchangable, technical identifier and label, as a changable identifier following a also changable hierarchy. An easier solution could be a user defined namespace as you mentioned, just giving up already given identifiers, sticking with random identifiers for new stuff and using the user name space instead.
The human friendly label is nice, but to be honest: If you set up pages/UIs for different uses you always have to chance the label. Within a room a label “heating” oder “radiator desk” is nice, having a page with all the radiators on one floor you would like to see just the room and perhaps a more detailed information like “office - desk” for the radiator behind the desk in the office. And for an overview of all radiators in the house you might look for something like “1st floor office” to differ it from the office in the basement. This is also something that could be implemented directly (with some effort) or be done by using a user name space that could be used to name items in the UIs instead.
As you indicated yourself it’s the object identifier and changing those is a hassle in about every database.
You shouldn’t really be changing namespaces more than once or twice at most, and that’s a mass edit thing you could be doing with text ex/import.
For single items it’s really just copy’n’create the YAML tab, that’s easy enough.
In total, it’s not much worth spending efforts so don’t expect that to happen.
Hierarchy should NOT be changeable beyond the extent it already is and we do not need more layers. More flexibility is not a good thing per se if you can represent all your building in the given model taxonomy because it encourages (call it “forces” if you like) users to build housing models alike, reusing existing concepts, allowing for reusable code to be built on top.
This:
