I saw this at startup on build 3292. I have 4 jars in the addons directory. 3 of the 4 bindings have been modified for addon.xml; 1 has not been converted. Not knowing one way or the other if this could be related to having an unconverted binding, I thought it best to mention.
2023-01-24 08:25:01.094 [INFO ] [org.openhab.core.Activator ] - Starting openHAB 4.0.0 (build Build #3292)
2023-01-24 08:25:01.156 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.util.ConcurrentModificationException: null
at java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1712) ~[?:?]
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509) ~[?:?]
at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499) ~[?:?]
at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:921) ~[?:?]
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) ~[?:?]
at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:682) ~[?:?]
at org.openhab.core.internal.addon.JarFileAddonService.refreshSource(JarFileAddonService.java:143) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) ~[?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) [?:?]
at java.lang.Thread.run(Thread.java:833) [?:?]
2023-01-24 08:25:01.219 [INFO ] [.core.internal.i18n.I18nProviderImpl] - Time zone set to 'US/Eastern'.```
I’ve seen this the last few times I’ve upgraded the snapshot. It’s pretty consistent so it’s worth reporting I think.
After an upgrade, when OH comes back online, my logs get filled up with:
2023-01-24 09:32:37.968 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler ShellyRelayHandler tried updating the thing status although the handler was already disposed.
Restarting makes these messages go away. It’s a minor annoyance but probably needs to be addressed before we release.
It’s complaining about the Shelly Binding but the warning comes from core so it’s not clear where the problem lies.
On a different note, after just upgrading an hour ago I’m seeing the following from Zigbee which I want to investigate a bit.
2023-01-24 09:37:30.609 [ERROR] [ng.zigbee.handler.ZigBeeThingHandler] - 000D6F000A79BADF: Exception creating channels │
20│java.lang.IllegalArgumentException: UID segment 'zigbee:device:zg_coordinator:000d6f000a79badf:000D6F000A79BADF_1_voltage' contains invalid characters. The last segment│
20│ of the channel UID must match the pattern '[\w-]*|[\w-]*#[\w-]*'.
at org.openhab.core.thing.ChannelUID.validateSegment(ChannelUID.java:136) ~[bundleFile:?]
at org.openhab.core.common.AbstractUID.<init>(AbstractUID.java:76) ~[bundleFile:?]
at org.openhab.core.thing.UID.<init>(UID.java:66) ~[bundleFile:?]
at org.openhab.core.thing.ChannelUID.<init>(ChannelUID.java:59) ~[bundleFile:?]
at org.openhab.core.thing.internal.ThingImpl.getChannel(ThingImpl.java:125) ~[?:?]
at org.openhab.binding.zigbee.handler.ZigBeeThingHandler.doNodeInitialisation(ZigBeeThingHandler.java:377) [bundleFile:?]
at org.openhab.binding.zigbee.handler.ZigBeeThingHandler$1.call(ZigBeeThingHandler.java:244) [bundleFile:?]
at org.openhab.binding.zigbee.handler.ZigBeeThingHandler$1.call(ZigBeeThingHandler.java:1) [bundleFile:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) [?:?]
at java.lang.Thread.run(Thread.java:833) [?:?]
It looks like something changed in the last week regarding what’s allowed for Thing IDs?
Edit: An initial investigation appears that the discovered Things use the MAC address as the UID which contains numbers and letters which should match the pattern. The regex101 tester matches no problem.
I don’t recall seeing such a PR in core but I don’t thoroughly read them all so maybe missed it.
The regex reported doesn’t make much sense to me either. Why [\w-]*|[\w-]*? They are both the same expression.
And why is it Zigbee the only one reporting the error? All most all of my other Things have a mix of numbers and letters and some start with numbers too and those are working no problem. Maybe something changed on the binding (I don’t read those issues and PRs, there’s too many)?
Good catch! I clearly didn’t read the stack trace closely enough. I was looking only at the Thing ID.
I’ll go manually change the ID on one of them and see what happens. I’ll file an issue on the binding if that turns out to be the problem. Or does it make sense to fix this in core and allow _?
This is very odd. We must be missing something. The Z-Wave binding has a bunch of channels that contain underscores, and I’m not seeing any issues. What build are you running? I’m on 3292.
The error is coming from code that hasn’t seen a meaningful change in years so the mystery grows.
I filed an issue on core but may have to close it because as I was mucking around in the JSONDB file I too found a bunch of other Channels that work that included _.
And after changing the Things (not the Links oops) to use - instead for the UID I’m still getting the error.
Now I wonder if that wasn’t a lucky accident that I forgot the Links. I wonder if the error is coming from the Link?
Nope, still not working.
This has to be a UID that is being generated dynamically in the add-on. The string 1_voltage no longer exists anywhere in my JSONDB files yet I’m still seeing
20│2023-01-24 11:41:47.499 [ERROR] [ng.zigbee.handler.ZigBeeThingHandler] - 000D6F00053AC32D: Exception creating channels │
20│java.lang.IllegalArgumentException: UID segment 'zigbee:device:zg_coordinator:000d6f00053ac32d:000D6F00053AC32D_1_voltage' contains invalid characters. The last segment│
20│ of the channel UID must match the pattern '[\w-]*|[\w-]*#[\w-]*'. │
20│ at org.openhab.core.thing.ChannelUID.validateSegment(ChannelUID.java:136) ~[bundleFile:?] │
20│ at org.openhab.core.common.AbstractUID.<init>(AbstractUID.java:76) ~[bundleFile:?] │
20│ at org.openhab.core.thing.UID.<init>(UID.java:66) ~[bundleFile:?] │
20│ at org.openhab.core.thing.ChannelUID.<init>(ChannelUID.java:59) ~[bundleFile:?] │
20│ at org.openhab.core.thing.internal.ThingImpl.getChannel(ThingImpl.java:125) ~[?:?] │
00│ at org.openhab.binding.zigbee.handler.ZigBeeThingHandler.doNodeInitialisation(ZigBeeThingHandler.java:377) [bundleFile:?] │3820│ at org.openhab.binding.zigbee.handler.ZigBeeThingHandler$1.call(ZigBeeThingHandler.java:244) [bundleFile:?] │
20│ at org.openhab.binding.zigbee.handler.ZigBeeThingHandler$1.call(ZigBeeThingHandler.java:1) [bundleFile:?] │
20│ at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?] │
20│ at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) [?:?] │
20│ at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) [?:?] │
20│ at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) [?:?] │
20│ at java.lang.Thread.run(Thread.java:833) [?:?]
Yep, I was just wondering if this is a dynamically created channel versus one statically defined in the thing xml. It could be that these are now being validated when in the past they were not.
One question regarding this: Do the warnings still show up after completely rebooting the server (not just restarting openhab)? I ask because similar things were discussed in the Shelly thread and after completely restarting the server those warnings disappeared for most users.
To be honest, I don’t know. I know that restarting OH solves the problem. I did’t check restarting the whole server. Do you like to me to restart the whole server and see if the logs come up again?
I’m running in Docker so restarting the container should be equivalent to restarting the whole machine. Given that just restarting the container makes the warnings go away I’m sure that restarting the machine will also make them go away.
They only show up after an upgrade. I suspect they may show up in other situations like immediately after first installing the add-on or possibly after disabling and reenabling the add-on but have not tested that.
After restarting OH after that upgrade the warning messages go away until the next upgrade.
I don’t see anything from the openHAB Marketplace. I still see bindings from the Smarthome/J marketplace but not the marketplace here. I only noticed because I’ve started slowly reimplementing some of my rule templates to JS Scripting and to take advantage of new stuff in OH like the privateCache and such.
There is nothing under Automation, UI, nor Blockly Libraries for me from the marketplace.
I did see a new “API Key for community.openhab.org” option under the “Community Marketplace” options. Maybe I’ve run into a work in progress and the existing entries in the marketplace need to be reviewed before we can see them?
The regex101 tester matches no problem.