I am not sure if it’s a oh5.x related topic but my zwave batterie device doesn’t get initialized

I am not sure if it’s a oh5.x related topic but my zwave batterie device doesn’t get initialized

You might want to try a re-interview in ZUI to ensure that is not the problem. Will have to wake to get that started.
I re-interviewed it woke it up and in my zwave js ui and via mqtt everything is fine…so do I need to activate those things when the sensor woken up?
I don’t quite understand. Are you saying everything is fine in ZUI and Mqtt, but there is still a problem in OH5 with the node 14 channels? The thought with my suggestion was to ensure the problem wasn’t upstream of the new zwavejs binding or OH5. I had hoped that the reinterview would also send the same information that was sent to MQTT (upon waking) also through the websocket to your zwavejs device.
My node 14 is included and zwave js ui recognize it. Via mqtt I see all the information which are sent out from node 14 ( node 14 is one of 7 window sensor and all have the same behavior)but the new binding doesn’t recognize it. Still the error is there and no channels…
Ok, so it is likely the new binding. I did some testing for the developer early on, but don’t have much in depth knowledge. The only suggestion I can make is to delete the thing and then rescan to see if it picks up anything from the reinterview
I re-interviewed the batterie devices and include them again this is the situation some are recognized and loaded some are error:config

is there any command I can do to get them included probably?
Are the Devices recognized by the “old” Zwave Binding?

yes and via mqtt I see everything
then it indeed look’s like the zwavejs binding has an issue
I reincluded one device for testing still the device is not online…maybe it needs sometie so I levae it for now
any logs necessary? please guide me
If error config, you certainly have a detailed message when you open the thing page.
It should help the developer.
Maybe you even have interesting warning logs to share.
seeing this in the log
2025-07-21 09:47:27.137 [WARN ] [ejs.internal.conversion.BaseMetadata] - Node 17, unable to parse unitSymbol '%rH', please file a bug report
2025-07-21 09:47:27.142 [WARN ] [.internal.handler.ZwaveJSNodeHandler] - Node 17. Error generating type information
java.lang.IllegalArgumentException: A unit hint must not be set if the item type is not a number with dimension!
at org.openhab.core.thing.type.ChannelType.<init>(ChannelType.java:88) ~[?:?]
at org.openhab.core.thing.internal.type.StateChannelTypeBuilderImpl$StateChannelTypeImpl.<init>(StateChannelTypeBuilderImpl.java:46) ~[?:?]
at org.openhab.core.thing.internal.type.StateChannelTypeBuilderImpl.build(StateChannelTypeBuilderImpl.java:93) ~[?:?]
at org.openhab.binding.zwavejs.internal.type.ZwaveJSTypeGeneratorImpl.generateChannelType(ZwaveJSTypeGeneratorImpl.java:370) ~[?:?]
at org.openhab.binding.zwavejs.internal.type.ZwaveJSTypeGeneratorImpl.generateChannelType(ZwaveJSTypeGeneratorImpl.java:346) ~[?:?]
at org.openhab.binding.zwavejs.internal.type.ZwaveJSTypeGeneratorImpl.getOrGenerate(ZwaveJSTypeGeneratorImpl.java:305) ~[?:?]
at org.openhab.binding.zwavejs.internal.type.ZwaveJSTypeGeneratorImpl.createChannel(ZwaveJSTypeGeneratorImpl.java:212) ~[?:?]
at org.openhab.binding.zwavejs.internal.type.ZwaveJSTypeGeneratorImpl.generate(ZwaveJSTypeGeneratorImpl.java:147) ~[?:?]
at org.openhab.binding.zwavejs.internal.handler.ZwaveJSNodeHandler.setupThing(ZwaveJSNodeHandler.java:577) ~[?:?]
at org.openhab.binding.zwavejs.internal.handler.ZwaveJSNodeHandler.internalInitialize(ZwaveJSNodeHandler.java:383) ~[?:?]
at org.openhab.binding.zwavejs.internal.handler.ZwaveJSNodeHandler.lambda$3(ZwaveJSNodeHandler.java:344) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) ~[?:?]
at java.util.concurrent.FutureTask.run(Unknown Source) ~[?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) ~[?:?]
at java.lang.Thread.run(Unknown Source) [?:?]
I looked at my early testing for the zwavejs developer and the unit symbol for humidity was ‘%’, not %rH. What is odd for your situation is why some seem fine and some don’t. Do you see any difference in how you have the thing (or items) setup between working and non-working in regard to relative humidity? Also in ZUI under the Multilevel sensor CC does that display the same (between working and non-working)?
I have done nothing I just included the devices as thing and thought that the battery devices might be woken up once to send any json (I haven’t checked the workflow) therefore I waited overnight and than this was the result as posted …than I thought about re interview or re including maybe sth. went odd but the same situation…I provided details on GitHub [zwavejs] Node Unit symbol %rH causes IllegalArgumentException during channel type generation · Issue #18998 · openhab/openhab-addons · GitHub may be you can check there for details. But I agree that is strange that some can/must/will/do work and some not…If you need more traces I can share them…
Maybe bugs related to zwavejs new binding can be discussed in a separate topic.
The %rh is not a valid unit. It is reported on GitHub and will be fixed. Probably by removing the rh part.
You could try setting a value (like 0) in the configuration CC section in zui. Compare the setting between non working and working. I seem to have a number
The unit=‘%rH’ is just not common, undocumented and not something the zwavejs binding took into account. In the linked PR on Giuthub is a jar available that has a fix included.
Thanks for reporting!