If MapDB were throwing an error over Item state NULL, that would be a bug. That should be silently ignored when persisting, and as it is ignored there should not be any persisted NULLs either. You’ll likely have hundreds of Items in NULL state at system startup.
Equally random guess, there’s a bit of rubbish in your MapDB database (potentially from OH1 days depending on your migration route) that new persistence code is choking on.
I wonder what happens when an Item changed type since last recorded. Maybe a restore-on-startup used to fail silently and now complains.
How costly would it be to delete your DB and let it start a fresh one? MapDB is usually only used for restore-on-startup
I upgraded 3.0.? to 3.1 using apt on a Ubuntu system. I rebooted and OH did not come up. In the logs I see the following errors:
2021-07-13 02:18:24.477 [ERROR] [Events.Framework ] - Framewo
rkEvent ERROR
org.osgi.framework.BundleException: Could not resolve module: org.apache.cxf.cxf
-core [66]
2021-07-13 02:18:24.523 [ERROR] [Events.Framework ] - Framewo
rkEvent ERROR
org.osgi.framework.BundleException: Could not resolve module: org.apache.cxf.cxf
-rt-frontend-jaxrs [67]
2021-07-13 02:18:24.530 [ERROR] [Events.Framework ] - Framewo
rkEvent ERROR
org.osgi.framework.BundleException: Could not resolve module: org.apache.cxf.cxf
-rt-rs-client [68]
2021-07-13 02:18:24.545 [ERROR] [Events.Framework ] - Framewo
rkEvent ERROR
org.osgi.framework.BundleException: Could not resolve module: org.apache.cxf.cxf
-rt-rs-sse [69]
2021-07-13 02:18:24.549 [ERROR] [Events.Framework ] - Framewo
rkEvent ERROR
org.osgi.framework.BundleException: Could not resolve module: org.apache.cxf.cxf
-rt-security [70]
2021-07-13 02:18:24.552 [ERROR] [Events.Framework ] - Framewo
rkEvent ERROR
org.osgi.framework.BundleException: Could not resolve module: org.apache.cxf.cxf
-rt-transports-http [71]
I don’t know if that points to a problem as some seem to be listed as “optional”. But those were the only things in the log. A quick search on the forum on “Could not resolve” returned a post that a reboot helped, and another suggested editing a pom.xml file (although that was for different dependencies). So I rebooted and now I’m not getting anything in the logs.
Before I start digging into this more I’m hoping someone might know of a quick resolution. When OH isn’t working I realize how much I use it! I did take a backup before the upgrade, but (silly me) have never tested a restore. For that do I need to load the 3.0 package with apt then just run the openhab-cli restore command?
Hello Ross,
I’m not sure what you mean about an item changing ‘type’ since last recorded but I doubt that because I would have created the backup file only 5 mins before doing the restore into the new OH version. Also, I never had OH1 and I have rebuilt the system from scratch a few times during ver OH2.x.x so there’s unlikely to be any rubbish in the MapDB.
Surely there can’t be major code differences between 3.1.0-M4 and the final Release 3.1.0… how can a final release be WORSE than the preceding later Milestone versions???
I’m going to have to stay with M4 until a clear definitive diagnosis and cure is recommended by the user community. Thanks for your thoughts anyway.
Sounds like you need to ask for your money back, really. How dare they not give you an immediate definitive diagnosis.
Let us know if you ever want to look into it further.
Dear Bernhard, I have the same problem as you are describing with the icons. Another user also described that issue here:
I’ve recorded a GIF to show the issue. It always happens when I’m navigating to another page. And it happens since I’ve updated to OH3.1.
After a refresh the images appear again.
you’re hilarious Ross… seriously though, sounds like you’ve misinterpreted my reply and have taken umbrage at me expressing a modicum of frustration that a release version might disappoint. I am always polite and very appreciative of help from the community members and do try to contribute to the forum also with solutions.
Courtesy costs nothing…
Thank you @Integer Mike for your quick reply. In my case refresh does not help.
Your reply motivated me to deeper analyze the behavior.
When I open the overview page (default start page without “/page/…” in the URL) the icons are displayed even after I do a refresh (I first thought that they show up because they are stored in the cache).
The problem seems to be related to the OH build-in webserver (URL, timeout, …?)
F7 icons work fine, only icons stored on the OH build-in webserver do not show up (icons stored in the folder /etc/openhab/html/icons … SMB share: \\openhab\openHAB-conf\html\icons ).
I get a similar problem, when I am using the openHAB App (Android) and try to rotate the tablet cross or upwards.
The error occurs only, if u open a widget like in this case “Wohnzimmer” from the overview page.
When the overview page is displayed solo, the rotation works fine.
Tried to record my tablet screen, hope it is bearable.
Exactly that was the thread I remembered but couldn’t find (@NCO for your reference) . AFAIK the startup levels cannot be used in rules but only in the UI though. Therefore the “started” trigger still fires quite early when not all items are loaded. So in my example this leads to logInfo() not being available during startup.
Now that I am thinking of it I probably should use virtual startup-items that get triggered by UI rules which have a proper startup-level trigger to avoid the issues.
I’m getting the same error
‘’’
org.graalvm.polyglot.PolyglotException: Error: Invalid CommonJS root folder: /etc/openhab/automation/lib/javascript/personal
‘’’
unfortunately for me I can’t get past it, have tried everything I can think of.I’m doing scripts from within the rule not file level.
running on 3.1.0
Well, who knew, for me this was the fix:
was using the Oracle jdk 11, switched to Zulu jdk 11, no dice
Switch to openjdk 11.0.11 2021-04-20, back in business!
After upgrading from 3.02 to 3.1 I got problems with IHC (not working).
There is a new select option for “TLS version” and I suspect this is where the problem is. I get the following error: COMMUNICATION_ERROR
javax.net.ssl.SSLHandshakeException: Remote host terminated the handshake
I have seen comments on the net suggesting changing java configuration, but I am running Openhab3 in a docker on Synology, så this is not an option.
Anny sugestions? Thanks in advance.
I found the root cause of the problem that the images or icons used in oh-image within a widget have no longer been displayed since the upgrade from OH3.0 to OH 3.1
with OH3.0 I used the following code within the widget to display a icon from folder /etc/openhab/html/icons
I don’t know if this change in behavior has been done intentional (a new feature) or by accident (a bug)
Anyway now you and I know how to live with it. If you use my posted widgets you have to adjust the YAML code of these widgets whenever “oh-image” is used.
Thank you @ysc Yannick for the clarification. I copied the “url: line” from a posted widget into my custom widget and it worked in OH 3.0 without leading slash - I don’t know why. After the upgrade to OH 3.1 my widget no longer worked and I tried to fix the problem.
I now verified the documentation and other widget examples … the relative addressing of a url: always started with slash as you said. So it was my fault and not a OH change. OH3.0 tolerated my wrong relative url: OH3.1 does not.
Hi All,
My apologies, i am new here.
Trying to find relevant place to report two issues i had
1 issue and 2 is a very minor bug, may not be worthy to fix, just in case - I am running 310 on Synology in Docker. Was playing with API explorer and seem like have came across some issue with swagger.
I used Settings - Pages - Created SiteMap. When i go to BasicUI - get message that there is no any site map defined - use documentation to create one. My problem here that the sitemap i just created does not display.
When i query things for example - response has two options - copy and download.
So, download does not work - (attached) response i get:
Sorry,
Requested content not found.
Hey, I had the same problem when upgrading from OpenHAB 2.5 to 3.1 on a raspberry Pi 3 running OepnHABian and for me it turned out to be that the Kernel modules in /lib/modules/ were for kernel version 5.10.52 but I was still running kernel 5.4.7+
This mean that the cdc_acm module/driver wasnt loading so the Aeotec Z-Wave stick wasn’t seen by anything other than doing an lsusb.
I fixed it (well, my experienced linux sys admin friend did) by downloading the latest OpenHABian image then copying over the entire contents /boot using rsync with the --delete option so it removed all the existing files. After that we ran an rpi-update then rebooted. After that it worked and my Z-Wave stick was found and showed up as online in OpenHAB.
After we did this my friend said there might have been a quicker way by just running:
It took a couple of hours to work out what was going on here and looking at lots of other posts about the Aeotec Z-Wave stick not working so I hope this helps people!
Kind of, I installed the mqtt binding and switched to using zigbee2mqtt. Seems to be working well with openhab and as a bonus my radiator valves are now working that I could not get to pair with the ZigBee binding.
you’re hilarious Ross… seriously though, sounds like you’ve misinterpreted my reply and have taken umbrage at me expressing a modicum of frustration that a release version might disappoint. I am always polite and very appreciative of help from the community members and do try to contribute to the forum also with solutions.
