Problems with WiDom Double Switch

Hello,
i´m new to opeHab but still i managed to set up a complete system within a day.

Everything is working fine except the WiDom Switch won´t work correctly. I use it to control two lights with 2 switches connected.

My first problem is that the switch always is switching to off after a random time. Its always after 6
to 10 minutes, without any notifications in the openHab log. The paperUI still thinking it is on. I
disabled (Remove batteries, disconnect from power) all other Z-Wave devices but the behavior
did not change.

when i search the log file i can see many suspicious log entries:

2018-04-07 13:55:13.630 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 8: Transaction not completed: node address inconsistent.  lastSent=8, incoming=255
2018-04-07 13:55:15.843 [DEBUG] [ocol.ZWaveController$ZWaveSendThread] - NODE 8: Too many retries. Discarding message: Message: class=SendData[0x13], type=Request[0x00], priority=Config, dest=8, callback=45, payload=08 03 70 05 00

2018-04-07 14:04:57.405 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: class=ApplicationCommandHandler, callback id=74, expected=SendData, cancelled=false      MISMATCH

I also saw that the node initialization stucks at the state GET_CONFIGURATION. After a while this disapears.

Hope someone can help me.

The middle one is the only one of concern - the others are perfectly normal. The timeout though indicates that there is no response, or an incorrect response from the device.

You should enable debug logging to see what is going on. It’s possible that the device is too far from the controller and isn’t responding, or possibly it is responding with an incorrect or unexpected response.

I don´t think the device is too far away. Its about 5 meter without anything in between.

I digged a little bit deeper about the second log entry. I found out that the database file widom_wds_0_0.xml is possible wrong.
There is a parameter 0 but when i look into the documentation Widom Double Relay_EN.pdf it starts with parameter 1. There are other minor differences but i thing they are no problem
It seem that they changed the firmware 3 years ago. The older document i did not found, so i could´t double check it with the database file

Here the log when i try to change the parameter 0:

2018-04-07 16:50:00.006 [DEBUG] [ocol.ZWaveController$ZWaveSendThread] - NODE 8: Timeout while sending message. Requeueing - 1 attempts left!
2018-04-07 16:50:00.008 [TRACE] [l.serialmessage.SendDataMessageClass] - NODE 8: Handling failed message.
2018-04-07 16:50:00.034 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 8: Got an error while sending data. Resending message.
2018-04-07 16:50:00.035 [TRACE] [ve.internal.protocol.ZWaveController] - Callback ID = 20
2018-04-07 16:50:00.035 [DEBUG] [ve.internal.protocol.ZWaveController] - Message queued. Queue length = 1. Queue={}
2018-04-07 16:50:00.036 [DEBUG] [ocol.ZWaveController$ZWaveSendThread] - Took message from queue for sending. Queue length = 0
2018-04-07 16:50:00.037 [TRACE] [wave.internal.protocol.SerialMessage] - Calculated checksum = 0xA9
2018-04-07 16:50:00.038 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 0A 00 13 08 03 70 05 00 25 14 A9
2018-04-07 16:50:00.039 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 8: Sending REQUEST Message = 01 0A 00 13 08 03 70 05 00 25 14 A9
2018-04-07 16:50:00.039 [TRACE] [ing.zwave.handler.ZWaveSerialHandler] - Message SENT
2018-04-07 16:50:00.041 [TRACE] [WaveSerialHandler$ZWaveReceiveThread] - Received ACK
2018-04-07 16:50:00.047 [TRACE] [WaveSerialHandler$ZWaveReceiveThread] - Received SOF
2018-04-07 16:50:00.048 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 04 01 13 01 E8
2018-04-07 16:50:00.048 [TRACE] [wave.internal.protocol.SerialMessage] - NODE 255: Creating new SerialMessage from buffer = 01 04 01 13 01 E8
2018-04-07 16:50:00.049 [TRACE] [wave.internal.protocol.SerialMessage] - Calculated checksum = 0xE8
2018-04-07 16:50:00.049 [TRACE] [wave.internal.protocol.SerialMessage] - NODE 255: Checksum matched
2018-04-07 16:50:00.049 [TRACE] [wave.internal.protocol.SerialMessage] - NODE 255: Message payload = 01
2018-04-07 16:50:00.050 [TRACE] [WaveSerialHandler$ZWaveReceiveThread] - Message is valid, sending ACK
2018-04-07 16:50:00.050 [TRACE] [WaveSerialHandler$ZWaveReceiveThread] - Response SENT
2018-04-07 16:50:00.051 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
2018-04-07 16:50:00.051 [TRACE] [wave.internal.protocol.SerialMessage] - Calculated checksum = 0xE8
2018-04-07 16:50:00.051 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 04 01 13 01 E8
2018-04-07 16:50:00.052 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 04 01 13 01 E8
2018-04-07 16:50:00.053 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=SendData[0x13], type=Response[0x01], priority=High, dest=255, callback=0, payload=01
2018-04-07 16:50:00.053 [TRACE] [ve.internal.protocol.ZWaveController] - Incoming Message type = RESPONSE
2018-04-07 16:50:00.054 [TRACE] [l.serialmessage.SendDataMessageClass] - Handle Message Send Data Response
2018-04-07 16:50:00.054 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 8: Sent Data successfully placed on stack.
2018-04-07 16:50:00.054 [TRACE] [wave.internal.protocol.SerialMessage] - Ack Pending cleared
2018-04-07 16:50:00.063 [TRACE] [WaveSerialHandler$ZWaveReceiveThread] - Received SOF
2018-04-07 16:50:00.064 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 07 00 13 14 00 00 02 FD
2018-04-07 16:50:00.065 [TRACE] [wave.internal.protocol.SerialMessage] - NODE 255: Creating new SerialMessage from buffer = 01 07 00 13 14 00 00 02 FD
2018-04-07 16:50:00.066 [TRACE] [wave.internal.protocol.SerialMessage] - Calculated checksum = 0xFD
2018-04-07 16:50:00.066 [TRACE] [wave.internal.protocol.SerialMessage] - NODE 255: Checksum matched
2018-04-07 16:50:00.067 [TRACE] [wave.internal.protocol.SerialMessage] - NODE 255: Message payload = 14 00 00 02
2018-04-07 16:50:00.067 [TRACE] [WaveSerialHandler$ZWaveReceiveThread] - Message is valid, sending ACK
2018-04-07 16:50:00.068 [TRACE] [WaveSerialHandler$ZWaveReceiveThread] - Response SENT
2018-04-07 16:50:00.068 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
2018-04-07 16:50:00.068 [TRACE] [wave.internal.protocol.SerialMessage] - Calculated checksum = 0xF3
2018-04-07 16:50:00.069 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 09 00 13 14 00 00 02 00 00 F3
2018-04-07 16:50:00.069 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 09 00 13 14 00 00 02 00 00 F3
2018-04-07 16:50:00.070 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=SendData[0x13], type=Request[0x00], priority=High, dest=255, callback=0, payload=14 00 00 02
2018-04-07 16:50:00.070 [TRACE] [ve.internal.protocol.ZWaveController] - Incoming Message type = REQUEST
2018-04-07 16:50:00.070 [TRACE] [l.serialmessage.SendDataMessageClass] - Handle Message Send Data Request
2018-04-07 16:50:00.071 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 8: SendData Request. CallBack ID = 20, Status = Transmission complete and ACK received(0)
2018-04-07 16:50:00.071 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 8: Starting initialisation from DONE
2018-04-07 16:50:00.072 [DEBUG] [ve.internal.protocol.ZWaveController] - Event Listener org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer@3a484685 already registered
2018-04-07 16:50:00.072 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Sent Message: class=SendData[0x13], type=Request[0x00], priority=Config, dest=8, callback=20, payload=08 03 70 05 00
2018-04-07 16:50:00.073 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Recv Message: class=SendData[0x13], type=Request[0x00], priority=High, dest=255, callback=0, payload=14 00 00 02
2018-04-07 16:50:00.073 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: class=SendData, callback id=20, expected=ApplicationCommandHandler, cancelled=false      MISMATCH
2018-04-07 16:50:05.040 [DEBUG] [ocol.ZWaveController$ZWaveSendThread] - NODE 8: Timeout while sending message. Requeueing - 0 attempts left!
2018-04-07 16:50:05.042 [TRACE] [l.serialmessage.SendDataMessageClass] - NODE 8: Handling failed message.
2018-04-07 16:50:05.066 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 8: Got an error while sending data. Resending message.
2018-04-07 16:50:05.068 [TRACE] [ve.internal.protocol.ZWaveController] - Callback ID = 21
2018-04-07 16:50:05.069 [DEBUG] [ve.internal.protocol.ZWaveController] - Message queued. Queue length = 1. Queue={}
2018-04-07 16:50:05.070 [DEBUG] [ocol.ZWaveController$ZWaveSendThread] - Took message from queue for sending. Queue length = 0
2018-04-07 16:50:05.071 [TRACE] [wave.internal.protocol.SerialMessage] - Calculated checksum = 0xA8
2018-04-07 16:50:05.072 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 0A 00 13 08 03 70 05 00 25 15 A8
2018-04-07 16:50:05.073 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 8: Sending REQUEST Message = 01 0A 00 13 08 03 70 05 00 25 15 A8
2018-04-07 16:50:05.074 [TRACE] [ing.zwave.handler.ZWaveSerialHandler] - Message SENT
2018-04-07 16:50:05.076 [TRACE] [WaveSerialHandler$ZWaveReceiveThread] - Received ACK
2018-04-07 16:50:05.081 [TRACE] [WaveSerialHandler$ZWaveReceiveThread] - Received SOF
2018-04-07 16:50:05.083 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 04 01 13 01 E8
2018-04-07 16:50:05.085 [TRACE] [wave.internal.protocol.SerialMessage] - NODE 255: Creating new SerialMessage from buffer = 01 04 01 13 01 E8
2018-04-07 16:50:05.086 [TRACE] [wave.internal.protocol.SerialMessage] - Calculated checksum = 0xE8
2018-04-07 16:50:05.086 [TRACE] [wave.internal.protocol.SerialMessage] - NODE 255: Checksum matched
2018-04-07 16:50:05.087 [TRACE] [wave.internal.protocol.SerialMessage] - NODE 255: Message payload = 01
2018-04-07 16:50:05.087 [TRACE] [WaveSerialHandler$ZWaveReceiveThread] - Message is valid, sending ACK
2018-04-07 16:50:05.088 [TRACE] [WaveSerialHandler$ZWaveReceiveThread] - Response SENT
2018-04-07 16:50:05.088 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
2018-04-07 16:50:05.089 [TRACE] [wave.internal.protocol.SerialMessage] - Calculated checksum = 0xE8
2018-04-07 16:50:05.090 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 04 01 13 01 E8
2018-04-07 16:50:05.090 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 04 01 13 01 E8
2018-04-07 16:50:05.091 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=SendData[0x13], type=Response[0x01], priority=High, dest=255, callback=0, payload=01
2018-04-07 16:50:05.091 [TRACE] [ve.internal.protocol.ZWaveController] - Incoming Message type = RESPONSE
2018-04-07 16:50:05.092 [TRACE] [l.serialmessage.SendDataMessageClass] - Handle Message Send Data Response
2018-04-07 16:50:05.092 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 8: Sent Data successfully placed on stack.
2018-04-07 16:50:05.093 [TRACE] [wave.internal.protocol.SerialMessage] - Ack Pending cleared
2018-04-07 16:50:05.097 [TRACE] [WaveSerialHandler$ZWaveReceiveThread] - Received SOF
2018-04-07 16:50:05.098 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 07 00 13 15 00 00 02 FC
2018-04-07 16:50:05.099 [TRACE] [wave.internal.protocol.SerialMessage] - NODE 255: Creating new SerialMessage from buffer = 01 07 00 13 15 00 00 02 FC
2018-04-07 16:50:05.099 [TRACE] [wave.internal.protocol.SerialMessage] - Calculated checksum = 0xFC
2018-04-07 16:50:05.099 [TRACE] [wave.internal.protocol.SerialMessage] - NODE 255: Checksum matched
2018-04-07 16:50:05.100 [TRACE] [wave.internal.protocol.SerialMessage] - NODE 255: Message payload = 15 00 00 02
2018-04-07 16:50:05.100 [TRACE] [WaveSerialHandler$ZWaveReceiveThread] - Message is valid, sending ACK
2018-04-07 16:50:05.101 [TRACE] [WaveSerialHandler$ZWaveReceiveThread] - Response SENT
2018-04-07 16:50:05.101 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
2018-04-07 16:50:05.102 [TRACE] [wave.internal.protocol.SerialMessage] - Calculated checksum = 0xF2
2018-04-07 16:50:05.102 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 09 00 13 15 00 00 02 00 00 F2
2018-04-07 16:50:05.103 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 09 00 13 15 00 00 02 00 00 F2
2018-04-07 16:50:05.103 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=SendData[0x13], type=Request[0x00], priority=High, dest=255, callback=0, payload=15 00 00 02
2018-04-07 16:50:05.104 [TRACE] [ve.internal.protocol.ZWaveController] - Incoming Message type = REQUEST
2018-04-07 16:50:05.104 [TRACE] [l.serialmessage.SendDataMessageClass] - Handle Message Send Data Request
2018-04-07 16:50:05.104 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 8: SendData Request. CallBack ID = 21, Status = Transmission complete and ACK received(0)
2018-04-07 16:50:05.105 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 8: Starting initialisation from DONE
2018-04-07 16:50:05.105 [DEBUG] [ve.internal.protocol.ZWaveController] - Event Listener org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer@3a484685 already registered
2018-04-07 16:50:05.106 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Sent Message: class=SendData[0x13], type=Request[0x00], priority=Config, dest=8, callback=21, payload=08 03 70 05 00
2018-04-07 16:50:05.106 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Recv Message: class=SendData[0x13], type=Request[0x00], priority=High, dest=255, callback=0, payload=15 00 00 02
2018-04-07 16:50:05.107 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: class=SendData, callback id=21, expected=ApplicationCommandHandler, cancelled=false      MISMATCH
2018-04-07 16:50:10.076 [DEBUG] [ocol.ZWaveController$ZWaveSendThread] - NODE 8: Too many retries. Discarding message: Message: class=SendData[0x13], type=Request[0x00], priority=Config, dest=8, callback=21, payload=08 03 70 05 00 

Yes, I think you are probably correct that the problem is related to the incorrect parameters in the database.

It would be great if you could check if they are correct, and if not, make any changes. I can delete parameter 0, but there are a lot of other warnings in this entry that we should try and remove. Before I remove parameter 0, we should make sure that it’s not meant to just be renumbered as there is a long description which I guess someone didn’t enter just for fun :wink:

If you can update the database it would be appreciated - you’ll need an account, and you’ll need to drop me a line to update your access to allow editing.

OK, i created a account - same name.
I will fix it, but How can i test it before i change it? I´m using the debian package.

I’ve updated access - thanks.

Unfortunately this is not so easy. I would just suggest to update the database as per the manufacturers data - if there are still problems once this is updated, then we can resolve them then.

After i compared the database entry with the englisch documentation version i found out that the parameter id was simply wrong.
I also changed the Association 1 name.
The other things i did not change as they are copied from the documentation.

Thanks. So do you consider the updates complete?

They still need to be fixed though at some stage. There is no category (not at all related to the documentation), no image, and the labels are too long as per the guidelines.

I still can fix this.
But first i want that my light in living room is working again. Now its a bit annoying that it is automatically switching of every 5 to 10 minutes.
If it still does not work i have to go back to my old system or get a other device until it is working correctly.

I managed to create a v2.2.1 snapshot build with a fixed database entry.
It looks like the problem with the timeout messages is gone.
But the real problem still exists. No matter how i configure the WiDOM Universal Double Switch the light is going off or sometimes also on without any action from openhab or other devices in the network. There is no log entry in openhab at all. The device also does not notify the new state.
I think it is a firmware bug of the device. Every time i change the configuration of the device the behavior is little bit different.

Hi

I have a Widom double switch too, but it is not recognised. Openhab says " The device is not in the database."

I assume the identifier has changed? How can I add it?

|zwave_beaming|true|
|---|---|
|zwave_class_basic|BASIC_TYPE_ROUTING_SLAVE|
|zwave_class_generic|GENERIC_TYPE_SWITCH_BINARY|
|zwave_class_specific|SPECIFIC_TYPE_POWER_SWITCH_BINARY|
|zwave_deviceid|2816|
|zwave_devicetype|4628|
|zwave_frequent|false|
|zwave_lastheal|2019-02-03T01:30:05Z|
|zwave_listening|true|
|zwave_manufacturer|329|

I have read through the manual how to add devices:
https://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-database-guide

It looks like exporting the xml file is no longer an option, since the DB is now used? So I tried to update the existing file. However, I do not see the “tools” button on the page:
https://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list

Is there another way of doing it?

The manufacturer is stated as
|zwave_manufacturer|329|
I assume PaperUI does not show the leading 0 here and it should be 0329. That is different though from the manufaturer ID in the database for Widom. Do they have two IDs?

Would appreciate if someone could point me into the right direction. I don’t mind creating the file but need to know what to do.