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 _?
Thanks!
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.
I’m on #3292 also.
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.
[OH 4] Channel ID contains invalid characters · Issue #3336 · openhab/openhab-core · GitHub for reference.
I second this. I always thought this is due to an strange setup on my side. Should we also file an issue for that?
Update: I would relate the issue to the shelly add-on (-> ShellyRelayHandler).
Perhaps, but where? I guess the add-on first?
Yep, the binding shelly addon, I would say.
I’m going to have to step away from a screen for a few hours. Would you mind filing it so I don’t forget? It’s encouraging that it’s not just me.
Done and btw it is also happening at 3.4.1
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.
I’ve had those errors after upgrading from 3.4.0 to 3.4.1. After restarting those errors were gone.
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.
No, it’s fine. When they’re gone they don’t come back. I noticed just like Rich says that they show up after either upgrading the binding or openhab.
A new issue came up for me. I’m still on #3292.
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?
Same over here.
Can you use the API explorer and check what GET /addons returns if you set the serviceId to marketplace? Do you see the addons there? If so, it’s an UI issue. If not, I’ll have a look. And please use a snapshot that was built after Fixes and enhancements for add-on services by J-N-K · Pull Request #3293 · openhab/openhab-core · GitHub was merged.
I get a 404 not found but I’m still on 3292. I’ll try to update and see if I get the same. I think 3292 includes that PR though.
I got empty square brackets on 3291, actually upgrading to latest SNAPSHOT