Shelly Qubino Wave Shutter with wrong channels?

Robert_Kleinmann · January 17, 2024, 9:33am

Hi togther,
in the past i used Qubino ZMNHCD1 Flush Shutter for my blind controll.
Last week one of the moduls brake down and i had to buy a new one. When i try to order i realised that Qubino was overtaken by Shelly, and they provide nearly the same products as Qubino.
I ordered a Shelly Qubino Wave Shutter (QNSH-001P10EU) and include it in my Z-Wave network.
Th device was recognized as shutter module:

But when i switch to the Cannels Tab i see the following:

This are the channels for a Dimmer module. So it is not possible to use this module. Does someone experienced the same?

Robert

Davide_Carboni · February 8, 2024, 12:48pm

I have the same problem…

Robert_Kleinmann · February 8, 2024, 4:52pm

I think this is a general issue with the Z-Wave database in Openhab.
In other home automation solutions the device seems to work.
I also have a Shelly wave 2pm module (2 switches) which has a wrong parameter (not sure which one, because i was able to get the device to work )
So in the moment it’s a risk to buy Shelly Qubino devices when you use Openhab.

apella12 · February 9, 2024, 2:28pm

The ZW DB is community maintained. If there is an issue it just takes someone to do it. FWIW - I believe the dimmer channels need to be changed to blinds_control to match the ZMNHCD1 configs.

Home7 · February 13, 2024, 4:40pm

I’ve the same issue and tried to find a solution.

I changed manually in local waveshutter_0_0.xml
by comparing with zmnhcd_4_1.xml.
Tested a few changes with trial and error - without success.

When clicking the “Dimmer 1” original item percentage-slider the relay switches once for about 100ms to ON and immediately OFF again.
After modification relay is not switching when clicking on the shutter items blinds-buttons.

Simplest changes were:
replace:
waveshutter_0_0.xml:

Dimmer 1

with:
zmnhcd_4_1.xml:

Blinds control 1

=>just changing typeId (and label) is not enough.
also replacing
COMMAND_CLASS_SWITCH_MULTILEVEL:1
with these lines
COMMAND_CLASS_SWITCH_MULTILEVEL:1
COMMAND_CLASS_SWITCH_MULTILEVEL:1

was not successfull

Comparing shelly documentation Wave Shutter on zwave parameters and commands with waveshutter_0_0.xml
looks reasonable to me.

Maybe I made waveshutter_0_0.xml inconsistent. Is there a tool for generating a waveshutter_0_0.xml?

If somebody can provide a valid waveshutter_0_0.xml I would do the testing.

apella12 · February 13, 2024, 5:16pm

Try this
waveshutter_0_0.xml (27.5 KB)

follow this post to overwrite the current file in your binding

Home7 · February 14, 2024, 6:35pm

Thanks for the quick reply!

Unfortunately tests were not successful, waveshutter did not switch any relay.

To make sure my test procedure is correct thats what I do:

I change the value of tag “label” in waveshutter_0_0.xml for each test to assert that the thing reflects my changes to waveshutter_0_0.xml .
In openhab GUI I delete the zwaveshutter thing ,
pause the zwave bridge,
deploy my changes (org.openhab.binding.zwave-4.1.1.jar),
start bridge,
wait for 1 new thing in Inbox,
create new zwaveshutter thing from Inbox,
check label
from zwaveshutter thing channel (e.g. “Blinds control 1”) create an item,
use item blind-control buttons
=> no reaction on relais.

How to proceed?

Maybe somebody can decode the messages (openhab.log) when “Blinds control” is used or point me to a tool. Dont know which message should actually switch the relais.
[DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 2: Sending REQUEST Message = 01 0D 00 13 02 06 60 0D 01 01 26 02 25 2B A2
[DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 2: Sending REQUEST Message = 01 0D 00 13 02 06 60 0D 01 01 26 05 25 2C A2
[DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 2: Sending REQUEST Message = 01 0D 00 13 02 06 60 0D 01 01 26 02 25 2D A4
[DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 2: Sending REQUEST Message = 01 09 00 13 02 02 26 02 25 2E CA
[DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 2: Sending REQUEST Message = 01 0D 00 13 02 06 60 0D 01 01 26 02 25 2F A6
[DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 2: Sending REQUEST Message = 01 10 00 13 02 09 60 0D 01 01 26 04 60 00 FF 25 30 32
[DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 2: Sending REQUEST Message = 01 09 00 13 02 02 26 02 25 31 D5
[DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 2: Sending REQUEST Message = 01 0D 00 13 02 06 60 0D 01 01 26 02 25 32 BB

apella12 · February 14, 2024, 7:12pm

First I have never had any blind devices, so that is a handicap. Second, I copied the blinds channels from Qubino ZMNHCD1 Flush Shutter (first post that was reported to work), so I think further tests are needed. Are your blinds on channel 1?

I can’t tell anything from that data except that messages are going out.

You need to post the full log, not excerpts
You need to explain what you did to generate the log

On the self-help side there is a log viewer here. For example this is the output from your snippet.

Levin1 · February 17, 2024, 3:28pm

I’m not an expert in regards of Z-Wave but I have many devices working.
I also tried to use the new Shelly wave shutter.
For me it seems obvious that the database entries of this device are wrong. I compared my Fibaro Rollershutter 3 (under Endpoints in DB) and there you can see “blinds_control” instead of “switch_dimmer” for the Shelly.
Shelly wave shutter: OpenSmartHouse Z-Wave Device Database
Fibaro Rollershutter 3: OpenSmartHouse Z-Wave Device Database

If there is someone who can update this in the database it would be great.

apella12 · February 17, 2024, 3:44pm

I created a draft XML with I think are the needed changes, but wanted a test to confirm before making any DB changes since I do not have the device

Levin1 · February 17, 2024, 7:12pm

I have a device but currently no roller shutter motor connected to it. Because I will get new shutters this May, I bought this Shelly to pre-test the device integration in OH.

apella12 · February 17, 2024, 11:22pm

The ZW DB is community maintained, then uploaded into the binding by the developer after review. I do sometimes try to speed things along because I know it is frustrating to not have your shiny new device work (and trying to help in the OH community). My personal guideline when I do choose to get involved and do not have the device, is to produce a test XML (like above) and have it tested (under the " first do no harm" concept). I can’t sort out what is happening above. I expected some sort of blinds moving up/down or stopping test (or not) with supporting debug, so yesterday’s DB update will not have any changes with this device.

However, since you have the device and you won’t be able to do more than include the device until May, my suggestion is to read the ZW DB blog, register and open a ticket for write access and make the changes you desire. ZW DB are generally updated at least every three weeks.

Levin1 · February 18, 2024, 11:00am

I appreciate your effort!
Yes I thought about registering for the DB but I don’t know if I have enough know how.
I will go through the guide and maybe register to it to update the device.

Levin1 · March 8, 2024, 9:42am

I got access to the DB and modified channels from dimmer to blinds_control. This is now in review.
The .xml seems slightly different compared to apella12’s xml.
wave-shutter-modified.xml (28.3 KB)

<property name="binding:*:PercentType">COMMAND_CLASS_SWITCH_MULTILEVEL:1</property>

vs

<property name="binding:*:PercentType">COMMAND_CLASS_SWITCH_MULTILEVEL:1,COMMAND_CLASS_BASIC:1</property>

apella12 · March 8, 2024, 2:34pm

I matched the setup of the ZMNHCD1. It had the Basic CC “true” on Multilevel CC EPs 1 & 2. I don’t know if that is needed for this device. The applicability is when (if?) there is local control that information is sometimes sent back to OH as Basic CC. Without that addition OH may not reflect changes from local (manual) control. Only way to know for sure is to test, but adding should not cause any problems.

Davide_Carboni · April 25, 2024, 11:59am

The channels are finally correct starting from the new version 4.2.0M2 but in my case the open\close and stop commands don’t work

apella12 · April 25, 2024, 1:56pm

Try to delete the thing (do not exclude) and rescan. could be some old data in the XML.
Turn on zw binding debug while trying the commands. Post log, or analyze with log viewer noted in post 7.

Davide_Carboni · April 27, 2024, 8:05pm

Hi here my log
2024-04-27 21:26:39.662 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 13: Polling…
2024-04-27 21:26:39.664 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 13: Polling zwave:device:43fafd954d:node13:blinds_control
2024-04-27 21:26:39.666 [DEBUG] [erter.ZWaveMultiLevelSwitchConverter] - NODE 13: Generating poll message for COMMAND_CLASS_SWITCH_MULTILEVEL, endpoint 0
2024-04-27 21:26:39.667 [DEBUG] [ss.ZWaveMultiLevelSwitchCommandClass] - NODE 13: Creating new message for command SWITCH_MULTILEVEL_GET
2024-04-27 21:26:39.669 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 13: SECURITY not supported
2024-04-27 21:26:39.670 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 13: Command Class COMMAND_CLASS_SWITCH_MULTILEVEL is NOT required to be secured
2024-04-27 21:26:39.671 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 13: Adding to device queue
2024-04-27 21:26:39.673 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 13: Added 256 to queue - size 1
2024-04-27 21:26:39.674 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
2024-04-27 21:26:39.676 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 09 00 13 0D 02 26 02 25 D9 32
2024-04-27 21:26:39.679 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 13: Sending REQUEST Message = 01 09 00 13 0D 02 26 02 25 D9 32
2024-04-27 21:26:39.681 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Message SENT
2024-04-27 21:26:39.682 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 06
2024-04-27 21:26:39.682 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage started: TID 256: [WAIT_RESPONSE] priority=Get, requiresResponse=true, callback: 217
2024-04-27 21:26:39.683 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=null[0], type=ACK[2], dest=255, callback=0, payload=
2024-04-27 21:26:39.684 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=null[0], type=ACK[2], dest=255, callback=0, payload=
2024-04-27 21:26:39.685 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction TID 256: [WAIT_RESPONSE] priority=Get, requiresResponse=true, callback: 217
2024-04-27 21:26:39.686 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg: ACK
2024-04-27 21:26:39.687 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2024-04-27 21:26:39.688 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 04 01 13 01 E8
2024-04-27 21:26:39.689 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 1 out at start. Holdoff false.
2024-04-27 21:26:39.690 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=SendData[19], type=Response[1], dest=255, callback=0, payload=01
2024-04-27 21:26:39.691 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=SendData[19], type=Response[1], dest=255, callback=0, payload=01
2024-04-27 21:26:39.693 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction TID 256: [WAIT_RESPONSE] priority=Get, requiresResponse=true, callback: 217
2024-04-27 21:26:39.694 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Checking outstanding transactions: 1
2024-04-27 21:26:39.696 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Last transaction: TID 256: [WAIT_RESPONSE] priority=Get, requiresResponse=true, callback: 217
2024-04-27 21:26:39.699 [DEBUG] [ve.internal.protocol.ZWaveController] - Incoming Message: Message: class=SendData[19], type=Response[1], dest=255, callback=0, payload=01
2024-04-27 21:26:39.704 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 13: sentData successfully placed on stack.
2024-04-27 21:26:39.706 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 18 00 13 D9 00 00 02 00 C3 7F 7F 7F 7F 00 00 03 00 00 00 00 03 01 00 00 ED
2024-04-27 21:26:39.708 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=SendData[19], type=Request[0], dest=0, callback=217, payload=D9 00 00 02 00 C3 7F 7F 7F 7F 00 00 03 00 00 00 00 03 01 00 00
2024-04-27 21:26:39.709 [DEBUG] [nal.protocol.ZWaveTransactionManager] - TID 256: Advanced to WAIT_REQUEST
2024-04-27 21:26:39.710 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 13: TID 256: Transaction not completed
2024-04-27 21:26:39.715 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=SendData[19], type=Request[0], dest=0, callback=217, payload=D9 00 00 02 00 C3 7F 7F 7F 7F 00 00 03 00 00 00 00 03 01 00 00
2024-04-27 21:26:39.716 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction TID 256: [WAIT_REQUEST] priority=Get, requiresResponse=true, callback: 217
2024-04-27 21:26:39.719 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 0D 00 04 00 0D 05 26 03 63 63 00 C3 00 18
2024-04-27 21:26:39.721 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=13, callback=0, payload=00 0D 05 26 03 63 63 00 C3 00
2024-04-27 21:26:39.736 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Checking outstanding transactions: 1
2024-04-27 21:26:39.737 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Last transaction: TID 256: [WAIT_REQUEST] priority=Get, requiresResponse=true, callback: 217
2024-04-27 21:26:39.738 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Checking TID 256: (Callback 217)
2024-04-27 21:26:39.739 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Callback match!
2024-04-27 21:26:39.741 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Correlated to TID 256: callback 217
2024-04-27 21:26:39.742 [DEBUG] [ve.internal.protocol.ZWaveController] - Incoming Message: Message: class=SendData[19], type=Request[0], dest=0, callback=217, payload=D9 00 00 02 00 C3 7F 7F 7F 7F 00 00 03 00 00 00 00 03 01 00 00
2024-04-27 21:26:39.752 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 13: SendData Request. CallBack ID = 217, Status = Transmission complete and ACK received(0)
2024-04-27 21:26:39.754 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 13: resetResendCount initComplete=true isDead=false
2024-04-27 21:26:39.754 [DEBUG] [nal.protocol.ZWaveTransactionManager] - TID 256: Advanced to WAIT_DATA
2024-04-27 21:26:39.755 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 13: TID 256: Transaction not completed
2024-04-27 21:26:39.756 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=13, callback=0, payload=00 0D 05 26 03 63 63 00 C3 00
2024-04-27 21:26:39.756 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2024-04-27 21:26:39.757 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 13: Application Command Request (ALIVE:DONE)
2024-04-27 21:26:39.757 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 13: resetResendCount initComplete=true isDead=false
2024-04-27 21:26:39.758 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 13: Incoming command class COMMAND_CLASS_SWITCH_MULTILEVEL, endpoint 0
2024-04-27 21:26:39.759 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 13: SECURITY not supported
2024-04-27 21:26:39.760 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 13: Received COMMAND_CLASS_SWITCH_MULTILEVEL V3 SWITCH_MULTILEVEL_REPORT
2024-04-27 21:26:39.761 [DEBUG] [ss.ZWaveMultiLevelSwitchCommandClass] - NODE 13: Switch Multi Level report, value = 99
2024-04-27 21:26:39.763 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 13: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2024-04-27 21:26:39.765 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 13: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_SWITCH_MULTILEVEL, value=99
2024-04-27 21:26:39.766 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 13: Updating channel state zwave:device:43fafd954d:node13:blinds_control to 100 [PercentType]
2024-04-27 21:26:39.767 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 13: Commands processed 1.
2024-04-27 21:26:39.768 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 13: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@1bfd7a0.
2024-04-27 21:26:39.770 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 13: Command verified org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@1bfd7a0.
2024-04-27 21:26:39.770 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 13: notifyTransactionResponse TID:256 DONE
2024-04-27 21:26:39.777 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 13: Got an event from Z-Wave network: ZWaveTransactionCompletedEvent
2024-04-27 21:26:39.778 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 1
2024-04-27 21:26:39.779 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2024-04-27 21:26:39.779 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2024-04-27 21:26:39.780 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.

apella12 · April 28, 2024, 12:02am

Hard to tell anything without context. Log shows no problem. Device was polled and responded correctly. What were you doing? There was no command captured. Did you delete and rescan the device as suggested? Lastly use the </>, so code is readable

Edit: Also may need to unlink item, then relink.

Davide_Carboni · April 28, 2024, 7:15am

Hi bob thanks for your support
I’ll try to give you more information:
First: I downloaded the updated device firmware from this page:
https://support.shelly.cloud/en/support/solutions/articles/103000258471-shelly-qubino-wave-firmware-updates
I updated the firmware via OTA using the zwave PC controller software by Silicon Labs.
I updated because the device had a problem: after a while it stopped working even through physical commands, after the update the problem disappeared, physical controls always work.
to answer your question:
Yes, I tried several times to remove the thing and add it again, I also tried to relink the item but the problem persists.
I have 2 Shelly Qubino Wave 2PM devices, which I updated via OTA and which work fine.
My openHAB version 4.2.0-SNAPSHOT - Build #4048 installed on a Raspberry PI 4
the previous log command was: DOWN
This below is the log for the UP command

2024-04-28 09:14:49.506 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 13: Command received zwave:device:43fafd954d:node13:blinds_control --> UP [UpDownType]
2024-04-28 09:14:49.509 [DEBUG] [ss.ZWaveMultiLevelSwitchCommandClass] - NODE 13: Creating new message for command SWITCH_MULTILEVEL_START_LEVEL_CHANGE
2024-04-28 09:14:49.511 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 13: SECURITY not supported
2024-04-28 09:14:49.514 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 13: Command Class COMMAND_CLASS_SWITCH_MULTILEVEL is NOT required to be secured
2024-04-28 09:14:49.516 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 13: Adding to device queue
2024-04-28 09:14:49.517 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 13: Added 304 to queue - size 1
2024-04-28 09:14:49.518 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
2024-04-28 09:14:49.520 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 0C 00 13 0D 05 26 04 20 00 FF 25 07 37 
2024-04-28 09:14:49.523 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 13: Sending REQUEST Message = 01 0C 00 13 0D 05 26 04 20 00 FF 25 07 37 
2024-04-28 09:14:49.525 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Message SENT
2024-04-28 09:14:49.526 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 06
2024-04-28 09:14:49.527 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=null[0], type=ACK[2], dest=255, callback=0, payload=
2024-04-28 09:14:49.527 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage started: TID 304: [WAIT_RESPONSE] priority=Set, requiresResponse=true, callback: 7
2024-04-28 09:14:49.528 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=null[0], type=ACK[2], dest=255, callback=0, payload=
2024-04-28 09:14:49.529 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 13: Polling initialised at 86400 seconds - start in 1500 milliseconds.
2024-04-28 09:14:49.529 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction TID 304: [WAIT_RESPONSE] priority=Set, requiresResponse=true, callback: 7
2024-04-28 09:14:49.530 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg: ACK
2024-04-28 09:14:49.530 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2024-04-28 09:14:49.531 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 1 out at start. Holdoff false.
2024-04-28 09:14:49.533 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 04 01 13 01 E8 
2024-04-28 09:14:49.535 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=SendData[19], type=Response[1], dest=255, callback=0, payload=01 
2024-04-28 09:14:49.536 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=SendData[19], type=Response[1], dest=255, callback=0, payload=01 
2024-04-28 09:14:49.537 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction TID 304: [WAIT_RESPONSE] priority=Set, requiresResponse=true, callback: 7
2024-04-28 09:14:49.538 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Checking outstanding transactions: 1
2024-04-28 09:14:49.538 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Last transaction: TID 304: [WAIT_RESPONSE] priority=Set, requiresResponse=true, callback: 7
2024-04-28 09:14:49.539 [DEBUG] [ve.internal.protocol.ZWaveController] - Incoming Message: Message: class=SendData[19], type=Response[1], dest=255, callback=0, payload=01 
2024-04-28 09:14:49.540 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 13: sentData successfully placed on stack.
2024-04-28 09:14:49.541 [DEBUG] [nal.protocol.ZWaveTransactionManager] - TID 304: Advanced to WAIT_REQUEST
2024-04-28 09:14:49.541 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 13: TID 304: Transaction not completed
2024-04-28 09:14:49.542 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2024-04-28 09:14:49.542 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 1 out at start. Holdoff false.
2024-04-28 09:14:49.551 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 18 00 13 07 00 00 02 00 BF 7F 7F 7F 7F 00 00 03 00 00 00 00 03 01 00 00 4F 
2024-04-28 09:14:49.553 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=SendData[19], type=Request[0], dest=0, callback=7, payload=07 00 00 02 00 BF 7F 7F 7F 7F 00 00 03 00 00 00 00 03 01 00 00 
2024-04-28 09:14:49.554 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=SendData[19], type=Request[0], dest=0, callback=7, payload=07 00 00 02 00 BF 7F 7F 7F 7F 00 00 03 00 00 00 00 03 01 00 00 
2024-04-28 09:14:49.555 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction TID 304: [WAIT_REQUEST] priority=Set, requiresResponse=true, callback: 7
2024-04-28 09:14:49.555 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Checking outstanding transactions: 1
2024-04-28 09:14:49.556 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Last transaction: TID 304: [WAIT_REQUEST] priority=Set, requiresResponse=true, callback: 7
2024-04-28 09:14:49.556 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Checking TID 304: (Callback 7)
2024-04-28 09:14:49.557 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Callback match!
2024-04-28 09:14:49.558 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Correlated to TID 304: callback 7
2024-04-28 09:14:49.558 [DEBUG] [ve.internal.protocol.ZWaveController] - Incoming Message: Message: class=SendData[19], type=Request[0], dest=0, callback=7, payload=07 00 00 02 00 BF 7F 7F 7F 7F 00 00 03 00 00 00 00 03 01 00 00 
2024-04-28 09:14:49.559 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 13: SendData Request. CallBack ID = 7, Status = Transmission complete and ACK received(0)
2024-04-28 09:14:49.560 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 13: resetResendCount initComplete=true isDead=false
2024-04-28 09:14:49.561 [DEBUG] [e.internal.protocol.ZWaveTransaction] - TID 304: Transaction COMPLETED
2024-04-28 09:14:49.561 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 13: Response processed after 34ms
2024-04-28 09:14:49.562 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 13: TID 304: Transaction completed
2024-04-28 09:14:49.562 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 13: notifyTransactionResponse TID:304 DONE
2024-04-28 09:14:49.564 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 13: Got an event from Z-Wave network: ZWaveTransactionCompletedEvent
2024-04-28 09:14:49.566 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2024-04-28 09:14:49.567 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.