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).
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.
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:
There’s no caching of Items, Things, nor Rules.
@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.
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.
Forgive me if this isn’t the right place to post but I’m struggling with units of measurement as it relates to humidity for several of my items in OH4. I posted previously and rlkoshak linked me to the current documentation (thx!) including this thread.
For example my ecobee thermostat sensors have items that are type = Number:Dimensionless, class = measurement, property = humidity. Prior to OH4 these reported correct correct quantity and units, eg. 49%. However in OH4 these now report 0.49.
I understand that I should be using Unit metadata to set these but I’m not having any success with the units setting of (Percent + ’ %').
Can anyone suggest the proper units metadata code?
I had a similar problem with with memory percent. I just went to number from number:dimensionless. Not sure about the metadata part.