Great. I’ll give it go again tomorrow and post the results.
@chris so the error message is definitely gone now, but I still don’t receive any updates to the channel/item. I have it set up as a Switch/Alarm, and have it logging if it receives and update or changes…is there something I may be missing?
I’m not sure - it looks ok and I have a test running which I believe simulates the doorbell. Can you provide a log again please so I can check what’s happening with the changes made recently.
@chris here ya go:
15:14:47.345 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 10 00 04 00 0E 0A 71 05 00 00 00 FF 08 01 00 00 6D
15:14:47.358 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
15:14:47.364 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 10 00 04 00 0E 0A 71 05 00 00 00 FF 08 01 00 00 6D
15:14:47.371 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 10 00 04 00 0E 0A 71 05 00 00 00 FF 08 01 00 00 6D
15:14:47.376 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 0E 0A 71 05 00 00 00 FF 08 01 00 00
15:14:47.379 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 14: Application Command Request (ALIVE:DETAILS)
15:14:47.383 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 14: Incoming command class ALARM
15:14:47.387 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 14: Received ALARM command V3
15:14:47.391 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 14: Process NOTIFICATION_REPORT V3
15:14:47.396 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 14: NOTIFICATION report - 0 = 0, event=1, status=255
15:14:47.400 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 14: Alarm Type = POWER_MANAGEMENT (0)
15:14:47.404 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveAlarmValueEvent
15:14:47.408 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 14: Got an event from Z-Wave network: ZWaveAlarmValueEvent
15:14:47.411 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 14: Got a value event from Z-Wave network, endpoint = 0, command class = ALARM, value = 255
15:14:47.417 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 4: Transaction not completed: node address inconsistent. lastSent=4, incoming=255
15:14:47.886 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 09 00 04 00 0E 03 80 03 21 5D
15:14:47.889 [INFO ] [marthome.event.ItemStateChangedEvent] - zwave_serial_zstick_home_serial_sof changed from 1656 to 1657
15:14:47.896 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
15:14:47.900 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 09 00 04 00 0E 03 80 03 21 5D
15:14:47.905 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 09 00 04 00 0E 03 80 03 21 5D
15:14:47.909 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 0E 03 80 03 21
15:14:47.912 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 14: Application Command Request (ALIVE:DETAILS)
15:14:47.914 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 14: Incoming command class BATTERY
15:14:47.915 [DEBUG] [ommandclass.ZWaveBatteryCommandClass] - NODE 14: Received Battery Request
15:14:47.916 [DEBUG] [ommandclass.ZWaveBatteryCommandClass] - NODE 14: Battery report value = 33
15:14:47.918 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveCommandClassValueEvent
15:14:47.919 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 14: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
15:14:47.921 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 14: Got a value event from Z-Wave network, endpoint = 0, command class = BATTERY, value = 33
15:14:47.924 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 14: Updating channel state zwave:device:home:node14:battery-level to 33 [DecimalType]
15:14:47.929 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 4: Transaction not completed: node address inconsistent. lastSent=4, incoming=255
15:14:48.601 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 10 00 04 00 0E 0A 71 05 00 00 00 FF 08 00 00 00 6C
15:14:48.603 [INFO ] [marthome.event.ItemStateChangedEvent] - zwave_serial_zstick_home_serial_sof changed from 1657 to 1658
15:14:48.613 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
15:14:48.619 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 10 00 04 00 0E 0A 71 05 00 00 00 FF 08 00 00 00 6C
15:14:48.624 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 10 00 04 00 0E 0A 71 05 00 00 00 FF 08 00 00 00 6C
15:14:48.629 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 0E 0A 71 05 00 00 00 FF 08 00 00 00
15:14:48.631 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 14: Application Command Request (ALIVE:DETAILS)
15:14:48.633 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 14: Incoming command class ALARM
15:14:48.634 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 14: Received ALARM command V3
15:14:48.636 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 14: Process NOTIFICATION_REPORT V3
15:14:48.638 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 14: NOTIFICATION report - 0 = 0, event=0, status=255
15:14:48.640 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 14: Alarm Type = POWER_MANAGEMENT (0)
15:14:48.641 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveAlarmValueEvent
15:14:48.643 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 14: Got an event from Z-Wave network: ZWaveAlarmValueEvent
15:14:48.644 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 14: Got a value event from Z-Wave network, endpoint = 0, command class = ALARM, value = 255
15:14:48.647 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 4: Transaction not completed: node address inconsistent. lastSent=4, incoming=255
15:14:49.145 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 09 00 04 00 0E 03 80 03 21 5D
15:14:49.151 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
15:14:49.158 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 09 00 04 00 0E 03 80 03 21 5D
15:14:49.158 [INFO ] [marthome.event.ItemStateChangedEvent] - zwave_serial_zstick_home_serial_sof changed from 1658 to 1659
15:14:49.164 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 09 00 04 00 0E 03 80 03 21 5D
15:14:49.168 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 0E 03 80 03 21
15:14:49.170 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 14: Application Command Request (ALIVE:DETAILS)
15:14:49.171 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 14: Incoming command class BATTERY
15:14:49.173 [DEBUG] [ommandclass.ZWaveBatteryCommandClass] - NODE 14: Received Battery Request
15:14:49.174 [DEBUG] [ommandclass.ZWaveBatteryCommandClass] - NODE 14: Battery report value = 33
15:14:49.176 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveCommandClassValueEvent
15:14:49.178 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 14: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
15:14:49.179 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 14: Got a value event from Z-Wave network, endpoint = 0, command class = BATTERY, value = 33
15:14:49.181 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 14: Updating channel state zwave:device:home:node14:battery-level to 33 [DecimalType]
15:14:49.186 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 4: Transaction not completed: node address inconsistent. lastSent=4, incoming=255
As a matter of interest, since the configuration changed have you deleted the thing and re-added it to get the updated configuration?
@chris Well, I did after the original notifications update. I also noticed there’s now the Power Level Timeout setting, but it doesn’t seem to stick when I change it. I’ll try removing and re-adding again.
@chris Success! Finally. I had to: delete/re-add, which changed the channel to Power Management. The default was a Number type, and it didn’t set a category, so it wasn’t originally working. I noticed that it was at least saying that it was updating the channel, but the item still showed null. I changed the item to Switch/Alarm and that did the trick. I also added the controller as the association group, but not sure if that was needed or not. I don’t know if there’s a way for you to set the defaults for category/type for others, as that may be helpful.
Thanks for your help in sorting this out…I really appreciate it!
Good stuff - glad it’s working.
Would it be possible to add a few “delete” buttons to the database editor? I have accidentally added a few configuration options to the wrong configuration parameter for the Nodon ASP-3-1 device. Ultimately, I think it would be good to have a delete button for all items where there is an add (+) button, but right now I only need it for the configuration item options.
In any way, I think the database tool is really great!
I’ve currently avoided adding delete buttons for users as I want to avoid mishaps ;). I’ll have a think about this, but for now you can change the label of anything you want to delete to DELETE ME or something, and then let me know the device and I’ll go through and delete them…
Ok, so I did. I have marked a few options with DELETE ME on the Nodon ASP-3-1 Smart Plug device. Also note that the alarm with type “system” has to be removed, since it cannot be mapped to a channel.
I have another question: I was a little surprised when I pulled new changes from the main repository and the Nodon device had already been included in the Z-Wave binding source code, even though I had requested a review for it. Was that intentional?
On the review question-not everyone requests the review, but they still expect their changes to be added. So, I normally go through the list of changes and if there’s a device with updates, and it looks ok, then I normally add it…
Yesterday I’ve switched to ZWAVE2 Binding (again) after quite some time. Looks really good and stable now! Zwave devices respond faster than they did with 1.9 (on RPi3).
I do have only two little feature requests:
- Support for (yet another) MCO wallswitch (TP S412) - Mine is a 015F:4121:1302:1.4. Quite similar to http://www.pepper1.net/zwavedb/device/660 . If you allow my account for editing the DB (Acc: Patrick), I will add it to db by myself.
- Support for Fibar-Command-Class for rollershutters. Controlling the lamella angle is really neat stuff. Perhaps I just didn’t get it, but I found no way to do so with 2.0 snapshot.
If you need more input for those requests feel free to ask.
Swipe support works great! I was able to cancel my workaround for controlling swipe via mqtt over second controller running z-way.
Will there be full SUC/SIS support for Zwave2 in a future release? ATM I do use a Z-Way RPi as SIS, for having a redundant approach in case of a single stick failure.
Done - thanks.
This needs some thought on how to add it in a ‘nice’ way…
What do you actually miss? SIS is a function of the network so I’m not sure what you actually required to be implemented in the binding? Generally, it’s not possible to have a fully redundant system that will continue to work if the stick fails - this is because there are many things that only allow a single controller to be added.
@chris I do know about the restrictions of a redundant zwave network. Atm my oh2 is a secondary controller, while my Zway is primary. Due to the lack of a second lifeline all my nodes use the secondary oh2 as lifeline controller. Both controllers are used in every other assoc group. Zway supports backup of the network and an update of all other controllers after an inclusion. With my configuration it is possible to include another controller after failure and make this primary without having to reinclude even a single node. Not perfect, but the best I could get from my configuration. Daily operations are performed by openhab.
Oh2 does not do any updates if used as primary.
Ok, so what you want is the network replication functions. This is already coded, but not called routinely at the moment, but it will be in future.
Hah. Great! You did sum it up to two words while I wrote a full essay on that crappy mobile 
Hi @chris,
maybe you could light this up: I have used a window sensor (Sensative Strip http://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/251 for quite a while in my OH1 environment. Configured as item type CONTACT (which is pretty normal I think). Some weeks ago I switched over to OH2 and couldn’t get the sensor to go. After many tries, I just desperately changed the item type in OH2 from CONTACT to SWITCH and…et voila…things got going.
Is this possible? Do you have an explanation for this behavior? I just found at least one other person who told me the same, so I assume it’s not an isolated problem of my installation.
any timeline yet for
reenabling HEAL ?
and adding support for Security (other than locks) ?
cheers
In OH2 you must use the data type associated with the channel definition. The binding will updated the channel with this data type, so if you use an item with a different type, it will not work.
This is simply the way OH2 works. The binding has no visibility of the item so if you use a different type the binding doesn’t know this.