ZWave Enerwave ZW15SM stuck at Node Initializing: Manufacturer

Thank you for all your hard work in supporting the vast variety of ZWave devices and their quirks!

It seems that my Enerwave ZW15SM devices are no longer configurable in OpenHab’s Habmin interface, starting around version 2.2, and they are stuck showing the constant message of “Node Initializing: Manufacturer”.
The logs indicate that they are timing out and not sending a response to the MANUFACTURER_SPECIFIC_GET command. The ZWave Database indicates the MANUFACTURER_SPECIFIC NIF column is checked for this device, which I guess was populated when I imported the initial XML report when I had an older version of OpenHab which successfully connected. The /opt/openhab2/userdata/zwave directory no longer has any discovered XML definitions for these devices. Is it possible that the device has lied about supporting MANUFACTURER_SPECIFIC? How can I change the ZWave binding’s definition of the device to not try to do MANUFACTURER_SPECIFIC probes for this device and test it before I change the database? I couldn’t find a stanza in the XML file that mentions Manufacturer Specific things, I presume because it’s enabled by default.
There are also mentions of “node address inconsistent, lastSent=10, incoming=255”, but I understand that is not worrisome.

Thank you so much!

Full log (filtered to just this node) available at https://pastebin.com/6qqFRYgv

Seemingly-relevant snippet:
2018-12-03 21:53:09.011 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 10: Initialisation retry timer started 5000
2018-12-03 21:53:09.011 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 10: Node advancer: loop - IDENTIFY_NODE try 1: stageAdvanced(false)
2018-12-03 21:53:09.011 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 10: Node advancer - advancing to MANUFACTURER
2018-12-03 21:53:09.012 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 10: Got an event from Z-Wave network: ZWaveInitializationStateEvent
2018-12-03 21:53:09.012 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 10: Node advancer: loop - MANUFACTURER try 0: stageAdvanced(true)
2018-12-03 21:53:09.013 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 10: Node advancer: MANUFACTURER - send ManufacturerSpecific
2018-12-03 21:53:09.013 [DEBUG] [WaveManufacturerSpecificCommandClass] - NODE 10: Creating new message for command MANUFACTURER_SPECIFIC_GET
2018-12-03 21:53:09.013 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 10: Node advancer - queued packet. Queue length is 1
2018-12-03 21:53:09.015 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 10: Sending REQUEST Message = 01 09 00 13 0A 02 72 04 25 2C 92
2018-12-03 21:53:09.024 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 10: Sent Data successfully placed on stack.
2018-12-03 21:53:09.039 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 10: SendData Request. CallBack ID = 44, Status = Transmission complete and ACK received(0)
2018-12-03 21:53:13.733 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 10: Transaction not completed: node address inconsistent. lastSent=10, incoming=255
2018-12-03 21:53:14.011 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 10: Stage MANUFACTURER. Initialisation retry timer triggered. Increased to 10000
2018-12-03 21:53:14.011 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 10: Node advancer - MANUFACTURER: queue length(0), free to send(false)
2018-12-03 21:53:14.012 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 10: Initialisation retry timer started 10000
2018-12-03 21:53:14.012 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 10: Node advancer: loop - MANUFACTURER try 1: stageAdvanced(false)
2018-12-03 21:53:14.012 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 10: Node advancer: MANUFACTURER - send ManufacturerSpecific
2018-12-03 21:53:14.013 [DEBUG] [WaveManufacturerSpecificCommandClass] - NODE 10: Creating new message for command MANUFACTURER_SPECIFIC_GET
2018-12-03 21:53:14.013 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 10: Node advancer - queued packet. Queue length is 1
2018-12-03 21:53:14.015 [DEBUG] [ocol.ZWaveController$ZWaveSendThread] - NODE 10: Timeout while sending message. Requeueing - 2 attempts left!
2018-12-03 21:53:14.016 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 10: Got an error while sending data. Resending message.
2018-12-03 21:53:14.017 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 10: Sending REQUEST Message = 01 09 00 13 0A 02 72 04 25 2F 91
2018-12-03 21:53:14.027 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 10: Sent Data successfully placed on stack.
2018-12-03 21:53:14.044 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 10: SendData Request. CallBack ID = 47, Status = Transmission complete and ACK received(0)
2018-12-03 21:53:14.219 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 10: Transaction not completed: node address inconsistent. lastSent=10, incoming=255
2018-12-03 21:53:19.018 [DEBUG] [ocol.ZWaveController$ZWaveSendThread] - NODE 10: Timeout while sending message. Requeueing - 1 attempts left!
2018-12-03 21:53:19.018 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 10: Got an error while sending data. Resending message.
2018-12-03 21:53:24.012 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 10: Stage MANUFACTURER. Initialisation retry timer triggered. Increased to 20000
2018-12-03 21:53:24.012 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 10: Node advancer - MANUFACTURER: queue length(0), free to send(false)
2018-12-03 21:53:24.013 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 10: Initialisation retry timer started 20000

I don’t think that you can do this.

I would try the following:
Exclude the device, factory reset it (?), use the latest Z-Wave Binding included in openHAB 2.4.0.M7 and try to re-add it to your Z-Wave setup.

Keep in mind that when upgrading from OH 2.3 there is a major change wrt the Z-Wave binding: ZWave binding updates

I hope not - without this it is impossible to know what the device is!

You can’t. The binding needs to know what the device is, so that it can find the information in the database, and to do this, it uses the information from the MANUFACTURER_SPECIFIC command class.

This is a debug message only - not an error.