If you use the update script (or the Debian bundles) it is executed automatically. You only need to run it manually if you do a manual update.
1 Like
My understanding is this new tool is now executed as part of the apt (used by openHABian), yum, and the upgrade script used by manual installations (I need to check if itās been added to the entrypoint script for Docker). So it should be executed automatically on an upgrade.
I could see it needing to be run manually if you restore the configs for an older OH on a newer OH for apt/yum installs. Itās already part of the documetned process to run the upgrade script for manual installs in this use case.
Over all, these instructions will only be valid until OH 4 is released (by the end of the month? Eeek!).
And my understanding is that the new upgrade toolās intent is to allow a normal upgrade between OH 3 and OH 4 work with minimal updates by the end users to adjust for breaking changes.
I like the approach to start with a new install because that will bring the OS up to date too. I know there are. a bunch still running on old OS images where the install for Java 17 might be problematic. This step avoids that problem.
I believe there is a config file you can put into the boot partition to tell openHABian to install the snapshot or milestone release. This will be important after OH 4 is released because in that case youāll have 3.4 configs being restored to an OH 4 instance without the benefit of the upgrade tool.
In my experience, removing them and re-adding them through MainUI was sufficient and worked. But Iāve been on the snapshots since day one so things may have changed.
IMO bindings that break OH overall need to be fixed and OH core should be fixed to prevent bindings from being able to do that.
I want to make what this step does clear because I see far too often that people do this as sort of an incantation without understanding.
The cache is where the add-ons get installed to. Clearing the cache simply forces OH to reinstall all the add-ons. Nothing more, nothing less.
During a normal upgrade (apt, yum, docker, upgrade script for manual installations, etc.) clearing of the cache is done for you already. There is no need to do this yourself.
Do not blindly clear the cache. Sometimes it can cause more problems than it solves. For example, if the problem is a certain binding cannot be installed, when you clear the cache now all your bindings might fail to install. You could go from a partially working OH to a completely hosed OH system. Only do this deliberately and when you know that the problem is related to the cache (e.g. an add-on is corrupted in the cache which is the case in @stefan.hoehnās instructions).
Note: before OH 4 release we need to make sure that the upgrade tool has been added to the upgrade PowerShell script, shell script, and as part of the upgrade process in entrypoint.sh on the Docker image. I know where to look to do this for Docker but donāt know where to look for the other two.
1 Like
Ran into the same issue, killed the upgradetool.jar to get the upgrade unstuck. (Thanks for the tip!)
Should I re-run the upgrade tool manually?
Or do the intended script work manually in the UI?
What issues might I run into if I just ignore it?
Thank you
I would.
No
Breaking changes from OH 3.4 will not be changed and some of your Things, Items, Marketplace, etc. may cease to work.
Thanks @rlkoshak, I shouldāve added that Iām upgrading from 4.0.0-M2 and the issue I ran into is this one:
[openHAB] Running JSON Database upgrade tool (${OPENHAB_RUNTIME} /bin/upgradetool.jar).
[main] INFO org.openhab.core.tools. internal. Upgrader - Copying item unit from state description to metadata in database '/var/lib/openhab/jsondb/org.openhab.core.items.Item.json'
Exception in thread "main" java.lang. NullPointerException: Cannot invoke "String.contains (java. lang.Charsequence)" because "pattern" is null
at org.openhab. core.tools. internal. Upgrader. lambda$0 (Upgrader. java: 104)
at java.base/java.util.concurrent. ConcurrentHashMap$KeySetView.forEach(ConcurrentHashMap.java:4706)
at org.openhab.core.tools. internal. Upgrader.itemCopyUnitToMetadata (Upgrader. java
:93)
at org.openhab. core.tools. UpgradeTool.main (UpgradeTool. java: 79)
https://github.com/openhab/openhab-core/pull/3630
Thanks!
In that case I suspect that your JDBC persistence might not work correctly if you skip it. I believe the upgrade tool supports command line arguments to tell it to just run certain tasks (e.g. skip the unit metadata updates and the just apply the JDBC upgrades).
1 Like
Thanks @rlkoshak for bringing light into the dark of this command 
I cleared it because I thought that there is some ācached jsondbā for the items itself tooā¦I am completely file based therefore I thought to get the new UoM changes done I need to recreate this ācached jsondbā.
Hi there, posting over here and to you in case you help with the Ambient Weather binding. this is the only case of it I can find in the thread here. (original thread with more detail - https://community.openhab.org/t/amazon-echo-not-working-after-4-0-0-m3-update/147033
I upgraded from 4.0.0 M2 ā 4.0.0 M3 and my Alexa speaker stopped working for commands. Every time I would say something, I would see an error in the openhab.log file (more than the below, but this is the main part)
2023-06-04 19:23:00.914 [ERROR] [io.socket.thread.EventThread ] - Task threw exception java.lang.ClassCastException: class org.json.JSONObject cannot be cast to class org.json.JSONObject (org.json.JSONObject is in unnamed module of loader org.eclipse.osgi.internal.loader.EquinoxClassLoader @28c50b07; org.json.JSONObject is in unnamed module of loader org.eclipse.osgi.internal.loader.EquinoxClassLoader @50160887) at org.openhab.io.openhabcloud.internal.CloudClient.lambda$15(CloudClient.java:358) ~[?:?]
After looking at a few other issues, some of which reported issues with an old Solar Forecast PV binding version (link below), I tried removing some bindings one by one to see if there is one causing the issue since I didnāt have the Solar Forecast PV installed.
Ambient Weather seems to be the cause. Hoping someone could look at that and perhaps compare to the release notes / fix for the Solar Forecast PV version .50 which must have fixed a similar issue.
Happy to help and provide more details / outputs / testing of a manual add on etc. Iām not great on the coding side though.
~Jason
As for the former part (Iām the author of the ecovacs binding): while Iām not sure whatās going on exactly in Stefanās case, this might be related to ecovacs being a marketplace addon in 3.4 and being shipped with the distribution in 4.0.
Also, if the issue is just the old binding still being present in the file system, I donāt see how that old binding should be fixable 
I fully agree about the latter part though.
1 Like
If you have text based configs, those never make it into the JSONDB and only get cached in memory, never to disk. The lifecycle of a text config entity is:
- āmodelā gets loaded and entity is created and marked as readonly
- entity exists and works within OH
- āmodelā gets unloaded and entity gets destroyed
Thereās no caching of Items, Things, nor Rules.
1 Like
@rperales have you found any solution yet? I got the same error when updating to M3.
I use InfluxDB on a seperat host. I donāt know if that can be the resonā¦
Iāve just had a chance to move up to M3 and I can confirm what @MartOs found: PR #1904 breaks use of the vue key property in oh-repeaters.
Moving the key property to an element containing the repeater does cause the whole repeater to be re-rendered and therefore resets the repeater data, but, in the testing I have done, this results in a brief but distinct flicker (multiple successive renders perhaps?) in the UI.
@florian-h05 do you think there is a way keep the benefits of 1904 without nullifying the key property?
edit: the flicker seems to be a slightly different problem, placing the key property on a component that also defines a stylesheet but adding key to any container can still cause a brief but visible shift in page elements when that container re-renders.
Can you please share the oh-repeater code you used to test this?
I need to have a look whatās going on before I can say more, but probably it would help to split the changes from my PR and keep parts of the original asyncComputed while still caching API requests.
It also has the undesirable side effect of reloading, and therefore closing, the accordion list if it is in one
For my part, it is only an issue with repeaters that make extensive use of metadata (which I do have many of) because changes to metadata will not otherwise trigger a redraw (naturally). Iām not sure any of these would be a useful test outside of my system, but I should be able to put together a concise demo widget sometime later today.
Do you want me to just put it in a new issue on the repo?
Yes please.
@JustinG @MartOs
Iāve fixed the regression whilst keeping the benefits from #1904:
This IMO is the expected behaviour since metadata is not really meant to be used to store data dynamically.
2 Likes
I agree. I just have so many system setting type metadatas that I prefer to be able to manage them via UI pages on the rare occasions when they do change. So, I like to see those changes reflected without a full page refresh which is solved much more elegantly by the key property than a metadata change event.
1 Like