I don’t think you have that error - have you seen anything in your log?
I think that is something that happened on my system for some reason and assume that’s why I don’t have channels, I just don’t know yet. As I’m running 5.2.0 on my dev installation here, maybe the parser have gotten more picky since 4.1.2 - or maybe there is some other problem. I did an XML “syntax check” in Notepad++, and it claims that the XML is valid.
Unfortunately I don’t see the gear icon on my marketplace binding listing, so I’m at a loss to how to enable debug logging. I could swear I saw one before, but it may have been with the beta jar. Should I go back to that one and see if I’m able to change the log level?
I noticed that it’s something weird there too, it doesn’t seem to “have a logger registered” according to OH. It does, it’s just not registered properly, I think. I did try to find some reason for this in the add-on earlier, but I can’t really find anything. I’m wondering if there’s an issue with the “coordinates”, this isn’t a binding, but a “misc” add-on. Binding usually have org.openhab.binding.<name> coordinates, “misc” uses org.openhab.io.<name> instead. I’m wondering if whatever code is supposed to “detect” the logging coordinates don’t know to look for org.openhab.io, since there are very few such add-ons. But, this is all speculation.
If adding the JAR to the addons folder makes a difference, by all means, do that.
But, you shouldn’t have to just to see these errors, as I log them with WARN, which is shown by default. DEBUG is needed to actually see that it picks up and processes the file if nothing goes wrong, but when there’s a problem, it should show up anyway.
OK, I’ll just leave the marketplace binding.
I checked again, deleting the xml and adding it again shows nothing in the logs.
I don’t see any xml files with the node number/name in that folder. (There are many others.)
Thanks!
Doesn’t that indicate that the binding never “discovered” the device? I thought it should create a file there even for “unknown” devices. Have you done a scan for new devices and then added a new Thing from the inbox?
By the way, I don’t get the EOF error anymore either, and the channels are populated, so that must have been some momentary confusion only:
{
"channels": [
{
"description": "Switch the power on and off",
"id": "switch_binary",
"label": "Switch",
"tags": [
"Power",
"Switch"
],
"properties": {
"binding:*:OnOffType": "COMMAND_CLASS_SWITCH_BINARY"
},
"category": "Switch",
"advanced": false,
"typeUID": "zwave:switch_binary"
},
{
"description": "Triggers when a scene button is pressed",
"id": "scene_number",
"label": "Scene Number",
"tags": [],
"properties": {
"binding:*:DecimalType": "COMMAND_CLASS_CENTRAL_SCENE"
},
"category": "",
"advanced": false,
"typeUID": "zwave:scene_number"
}
],
"channelGroups": [],
"configParameters": [
{
"description": "Sets the node ID<BR/>The node ID is assigned by the controller and can not be changed.",
"label": "Node ID",
"name": "node_id",
"required": true,
"type": "INTEGER",
"min": 1,
"max": 232,
"readOnly": true,
"multiple": false,
"groupName": "thingcfg",
"advanced": true,
"verify": false,
"limitToOptions": true,
"options": [],
"filterCriteria": []
}
],
"parameterGroups": [],
"properties": {
"modelId": "ZEN58",
"vendor": "Zooz",
"manufacturerId": "027A",
"manufacturerRef": "0004:0322",
"dbReference": "1687"
},
"extensibleChannelTypeIds": [],
"UID": "zwave:zooz_zen58_00_000",
"label": "ZEN58 XS Low Voltage Relay",
"description": "XS Low Voltage Relay<br /> <h1>Overview</h1><p>Manual or z-wave on/off control for low voltage loads. </p><p>Monitors analog dry contact inputs like open/close sensors. </p><p>Installs behind your existing wall switch (single pole or 3-way). </p><p>Z-wave Long Range for next -level wireless network</p><p>Remembers and restores on/off status after power failure</p><p>800 series z-wave and s2 SmartStart security.</p><p>Specs: </p><p>Power 9-40v ac/dc</p><p>Max load: 3A @ 240V.</p><p>Range: up to 300ft LoS and 1300ft with zwave long range enabled. </p><p>Indoor use only.</p><p>1.2\"x1\"x0.6\" (its so tiny!)</p> <br /> <h2>Inclusion Information</h2><p>Initiate inclusion on hub and press the z-wave button 3 times as quickly as possible.</p> <br /> <h2>Exclusion Information</h2><p>Initiate exclusion on hub and press the z-wave button 3 times as quickly as possible.</p> <br /> <h2>Wakeup Information</h2><p><br /></p>",
"category": "Valve",
"listed": false,
"supportedBridgeTypeUIDs": [],
"bridge": false
}
To me, it looks like the file is valid.
I’ve made a little tweak to the logging in the binding, but to be honest, I don’t quite understand what happened earlier, because the error I’m getting now would have been shown without my tweak as well.
I made an error in the file on purpose, which leads to this being logged:
---- Debugging information ----
cause-exception : com.thoughtworks.xstream.io.StreamException
cause-message :
class : java.util.ArrayList
required-type : java.util.ArrayList
converter-type : com.thoughtworks.xstream.converters.collections.CollectionConverter
path : /thing-descriptions
line number : 252
class[1] : org.openhab.io.thingtypes.internal.copied.ThingDescriptionList
required-type[1] : org.openhab.io.thingtypes.internal.copied.ThingDescriptionList
converter-type[1] : org.openhab.io.thingtypes.internal.copied.ThingDescriptionConverter
version : 1.4.21
Even though not all of the information is that helpful, it does at least say what line number the problem is at.
Yes. Many times (hoping it would work each time too!).
But, is the device never found during the scan at all? Because, that’s not what happens if the thing-type is missing, it’s still found, it’s just never “recognized” as the device it is - but remains an “unknown device”.
Not sure if we’re using the same terminology:
Thing properties:
Yes, that’s how it looks when the thing-type is missing. But, the binding must know the thing-type before the scan. I usually don’t create the Thing until it has been “recognized” while in the inbox. I don’t know if that actually matters, but it can take some time before it changes from “unknown device” to the actual device.
If you have scanned and found the device after the add-on and the XML was in place (and thus the thing-type known), it can look like maybe the thing-type definition doesn’t “match” the device. This is done using the IDs that @apella12 mentioned earlier I think, manufacturer ID and model ID or something like that.
But, I thought that the XML file in userdata/zwave would be created as soon as the node was found, even if it is “unknown device” - so when you said that you don’t have anything there, I thought that maybe it was never “found” in the first place.
I don’t know enough about the internals of the Z-Wave binding to effectively debug that part though.
I have released the new version on the marketplace. I don’t think it will make any difference, but just uninstall and reinstall the marketplace add-on to get the new version.
I think you’re right. This ZEN58 was just one of a couple new Zooz devices I acquired and the others were recognized almost immediately so the Z-wave binding is working.
Would you happen to know if I manually pieced together a xml file for userdate/zwave if it would work? I’m thinking it won’t (which is why your binding is a really needed).
I’ll install your latest.
Thank you!
No, this is waay beyond my knowledge of the binding, but I kind of doubt it. There should be a reason why no file is created though. I think @apella12 is the one most likely to be able to help with this.
Thank you to both of you for your help.
So, I would like to see this addon work, however, at this point we need to start without it. As noted above even totally unknown devices generate an XML in the userdata/zwave folder. I don’t know if this addon is interfering with that or there is something else. Note that the userdata/zwave XML is a record file after the device is initially interviewed. It is not the same XML as the binding uses to discover the device. I’d say your device is not being discovered (maybe partially, but not fully).
My advice is to remove the addon completely for now. Either factory reset the device or use the exclude devices on the controller page (while putting the ZWave binding into Debug so we can see what happens). Then, while still in debug try to include the device. Either we’ll get a record XML in the Zwave folder or hopefully see what is going wrong. Post that XML if it appears
Not to get ahead, but at that point we can try the addon again
There is absolutely no reason to remove or disable the add-on - it doesn’t interfere with the binding in any way.
You have different “providers” for things in OH, like a thing-type provider, channel-type provider etc. There are several such providers in Core itself, and any add-on that wants to can register as providers as well:
The ones you see there are a bit randomly based on which bindings I have installed in my dev environment, but as you can see, MQTT, SystemInfo, Homematic and Homekit must also be uninstalled if you’re afraid that a thing-type provider can cause “problems”.
The XmlThingTypeProvider is a part of Core, which processes all the add-on bundles and the embedded XML files that are in the JARs. These are then handed off to different providers, so if it finds a thing-type definition, XmlThingTypeProvider will register that thing-type and make it available to all other components of the system.
The thing-types aren’t special or particular for the Z-Wave binding at all, except for this definition inside the XML file:
<thing:thing-descriptions bindingId="zwave">
My add-on can therefore be used to provide thing- and channel-types to any binding that doesn’t have what they need embedded. It doesn’t interfere with the Z-Wave binding directly in any way, and it doesn’t even “know” that the binding is there.
So, any troubleshooting as to whether the device isn’t being detected/discovered/registered/processed is completely independent of this add-on. It only plays a role when, after registering the “unknown device”, the Z-Wave binding tries to find a matching thing-type for the device.
In addition, when I tested it, I made a special build of the Z-Wave binding where I removed all embedded definitions. I then supplied the XML files via my add-on for some of the devices that I have, and “scanned and discovered” them. They were added to the inbox exactly as normal, so I know that this process itself works.
Thanks guys, I’m trying to catch up. Here’s what I’ve got:
Thing Node116 properties now shows 14 (was previously 11). Progress?
I see 10 date modified changes of xml’s in /var/lib/openhab/zwave. Not sure how identify any newly created ones (or how the naming number sequence corresponds to devices).
Debug log:
2026-02-10 13:39:34.722 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2026-02-10 13:39:34.723 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
2026-02-10 13:39:35.209 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - Initializing ZWave thing handler zwave:device:43d6869b:node116.
2026-02-10 13:39:35.211 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 116: MANUFACTURER not set
2026-02-10 13:39:35.212 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 116: Controller status changed to ONLINE.
2026-02-10 13:39:35.215 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 116: Controller is ONLINE. Starting device initialisation.
2026-02-10 13:39:35.224 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 116: Updating node properties.
2026-02-10 13:39:35.226 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 116: Updating node properties. MAN=634
2026-02-10 13:39:35.227 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 116: Updating node properties. MAN=634. SET. Was null
2026-02-10 13:39:35.228 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 116: Properties synchronised
2026-02-10 13:39:35.235 [DEBUG] [ve.internal.protocol.ZWaveController] - Event listener added.
2026-02-10 13:39:35.236 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 116: Initialising Thing Node...
2026-02-10 13:39:35.237 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 116: Polling initialised at 86400 seconds - start in 39225600 milliseconds.
2026-02-10 13:39:35.238 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 116: Device initialisation complete.
2026-02-10 13:39:37.022 [DEBUG] [al.protocol.ZWaveInclusionController] - ZWave inclusion controller finalised
2026-02-10 13:39:38.164 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 10 00 04 00 04 0A 32 02 21 74 00 00 00 00 00 00 80
2026-02-10 13:39:38.166 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=4, callback=0, payload=00 04 0A 32 02 21 74 00 00 00 00 00 00
2026-02-10 13:39:38.167 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=4, callback=0, payload=00 04 0A 32 02 21 74 00 00 00 00 00 00
2026-02-10 13:39:38.168 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2026-02-10 13:39:38.169 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 4: Application Command Request (ALIVE:DONE)
2026-02-10 13:39:38.170 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 4: resetResendCount initComplete=true isDead=false
2026-02-10 13:39:38.171 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 4: Incoming command class COMMAND_CLASS_METER, endpoint 0
2026-02-10 13:39:38.173 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 4: SECURITY NOT required on COMMAND_CLASS_METER
2026-02-10 13:39:38.177 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 4: Received COMMAND_CLASS_METER V3 METER_REPORT
2026-02-10 13:39:38.178 [DEBUG] [.commandclass.ZWaveMeterCommandClass] - NODE 4: Meter: Type=Electric(1), Scale=W(2), Value=0E+1
2026-02-10 13:39:38.179 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 4: Got an event from Z-Wave network: ZWaveMeterValueEvent
2026-02-10 13:39:38.180 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 4: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_METER, value=0E+1
2026-02-10 13:39:38.181 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 4: Updating channel state zwave:device:43d6869b:node4:meter_watts to 0 [DecimalType]
2026-02-10 13:39:38.182 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 4: Commands processed 1.
2026-02-10 13:39:38.185 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 4: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@2bbb9aed.
2026-02-10 13:39:38.187 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2026-02-10 13:39:38.187 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2026-02-10 13:39:38.190 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
Thanks!
It seems like the new node id is 116 - so is there no file there for node 116?
That said, it looks to me like the device has been “discovered” as far as you can expect without the thing-type. I don’t know if it helps to add the thing-type now (if the “resolving” will continue) or if it’s now “too late” and it has given up identifying the device.
I would think that just deleting the Thing and scanning again would restart that process though, which could be done once the thing-type is in (add-on reinstalled and OH restarted).
It says manufacturer ID 634 - which seems to match what is in the thing-type configuration (0x27a is hex for 634 decimal).
<properties>
<property name="vendor">Zooz</property>
<property name="modelId">ZEN58</property>
<property name="manufacturerId">027A</property>
<property name="manufacturerRef">0004:0322</property>
<property name="dbReference">1687</property>
</properties>
Device ID 802 decimal = 0x322 hex so that also seems to match, however I’m not sure what 0x0004 refers to. This is where I thought @apella12 what know.
What I do know is that these values must “match” for the thing-type definition provided to be applied to the device/Thing.
This is from the definition of one of the devices I have myself (that is working)
<properties>
<property name="vendor">Fibargroup</property>
<property name="modelId">FGD212</property>
<property name="manufacturerId">010F</property>
<property name="manufacturerRef">0102:1000,0102:1001,0102:2000,0102:3000,0102:4000,0102:6000</property>
<property name="versionMin">3.5</property>
<property name="dbReference">787</property>
<property name="commandClass:COMMAND_CLASS_SWITCH_MULTILEVEL">ccAdd</property>
<property name="commandClass:COMMAND_CLASS_SCENE_ACTIVATION">ccAdd</property>
<property name="commandClass:COMMAND_CLASS_MULTI_CHANNEL">ccAdd</property>
<property name="defaultAssociations">1</property>
</properties>
It shows in OH with
So, it seems like it “should” match, except that I’m not sure what the first part of the manufacturerRef is - in my case they are all 0102 - in your case it’s 0004. Converting 0x0102 hex to decimal gives 258, which happens to match what zwave_devicetype is in my device. The same is true in your instance, zwave_devicetype is 4, so as far as I can tell, it should have “matched” with the thing-type, if the definition had been known during discovery.
The log snippet is a little short, but it seems to be discovered (at least the type:id are verified). As noted by @Nadahar is there an XML with node116? It should look like this;
network_xxxxxxx__node_116? If yes step one is complete. If not you didn’t capture the full inclusion log, so can’t tell what happened. What might help is to use the zwave log viewer on your file. I’m looking for the DONE. That is when the record XML is written
Edit: Example from the archives;
