[SOLVED][Z-Wave] Hank - HKZW-MS02 type 200 motion not detected

Add-ons Bindings
1

Dear forum users,

I recently got a Hank - HKZW-MS02 (type 200). I scanned for devices via the PaperUI zwave-discovery procedure and since the latest zwave database update (2018-11-20), the device gets recognized and added to openhab zwave device list.

There are two channels created by Openhab: 1. Alarm (burglar) and 2. Battery level.

Unfortunately I cannot see the “Alarm (burglar)” reacting on motion in PaperUI or on the sitemap with the MS02 items. The “Alarm (burglar)” output always shows “OK” (doesn’t change) and the Battery output is showing “90%”.

The debug log only shows:

[DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 14: Updating channel state zwave:device:c949557e:node14:alarm_burglar to OFF [OnOffType]

I don’t see an “updating channel state to ON” in the debug log.

The full zwave debug log for this device:

2018-11-21 23:49:01.288 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2018-11-21 23:49:01.291 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 14: Application Command Request (ALIVE:DONE)
2018-11-21 23:49:01.296 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 14: resetResendCount initComplete=true isDead=false
2018-11-21 23:49:01.304 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 14: Incoming command class COMMAND_CLASS_ALARM, endpoint 0
2018-11-21 23:49:01.311 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 14: SECURITY NOT required on COMMAND_CLASS_ALARM
2018-11-21 23:49:01.312 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 14: Received COMMAND_CLASS_ALARM V5 NOTIFICATION_REPORT
2018-11-21 23:49:01.324 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 14: NOTIFICATION report - 0 = 0, event=8, status=255, plen=0
2018-11-21 23:49:01.330 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 14: Alarm Type = BURGLAR (0)
2018-11-21 23:49:01.335 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 14: Got an event from Z-Wave network: ZWaveAlarmValueEvent
2018-11-21 23:49:01.336 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 14: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_ALARM, value = 255
2018-11-21 23:49:01.367 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 14: Alarm converter processing NOTIFICATION
2018-11-21 23:49:01.410 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 14: Alarm converter NOTIFICATION event is 8, type OnOffType
2018-11-21 23:49:01.442 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 14: Commands processed 1.
2018-11-21 23:49:01.470 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 14: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@1b44c995.
2018-11-21 23:49:01.482 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2018-11-21 23:49:01.483 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2018-11-21 23:49:01.483 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2018-11-21 23:49:01.495 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
2018-11-21 23:49:05.595 [vent.ItemStateChangedEvent] - zwave_serial_zstick_c949557e_serial_sof changed from 6078 to 6079
==> /var/log/openhab2/openhab.log <==
2018-11-21 23:49:05.594 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 0F 00 04 00 0E 09 71 05 00 00 00 FF 07 09 00 76 
2018-11-21 23:49:05.659 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=14, callback=0, payload=00 0E 09 71 05 00 00 00 FF 07 09 00 
2018-11-21 23:49:05.660 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=14, callback=0, payload=00 0E 09 71 05 00 00 00 FF 07 09 00 
2018-11-21 23:49:05.661 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2018-11-21 23:49:05.661 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 14: Application Command Request (ALIVE:DONE)
2018-11-21 23:49:05.662 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 14: resetResendCount initComplete=true isDead=false
2018-11-21 23:49:05.665 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 14: Incoming command class COMMAND_CLASS_ALARM, endpoint 0
2018-11-21 23:49:05.666 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 14: SECURITY NOT required on COMMAND_CLASS_ALARM
2018-11-21 23:49:05.669 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 14: Received COMMAND_CLASS_ALARM V5 NOTIFICATION_REPORT
2018-11-21 23:49:05.672 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 14: NOTIFICATION report - 0 = 0, event=9, status=255, plen=0
2018-11-21 23:49:05.675 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 14: Alarm Type = BURGLAR (0)
2018-11-21 23:49:05.679 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 14: Got an event from Z-Wave network: ZWaveAlarmValueEvent
2018-11-21 23:49:05.681 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 14: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_ALARM, value = 255
2018-11-21 23:49:05.684 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 14: Alarm converter processing NOTIFICATION
2018-11-21 23:49:05.688 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 14: Alarm converter NOTIFICATION event is 9, type OnOffType
2018-11-21 23:49:05.690 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 14: Commands processed 1.
2018-11-21 23:49:05.693 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 14: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@6e18be0a.
2018-11-21 23:49:05.697 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2018-11-21 23:49:05.700 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2018-11-21 23:49:05.702 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2018-11-21 23:49:05.706 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
==> /var/log/openhab2/events.log <==
2018-11-21 23:49:08.728 [vent.ItemStateChangedEvent] - zwave_serial_zstick_c949557e_serial_sof changed from 6079 to 6080
==> /var/log/openhab2/openhab.log <==
2018-11-21 23:49:08.729 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 10 00 04 00 0E 0A 71 05 00 00 00 FF 07 00 01 09 6B 
2018-11-21 23:49:08.731 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=14, callback=0, payload=00 0E 0A 71 05 00 00 00 FF 07 00 01 09 
2018-11-21 23:49:08.732 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=14, callback=0, payload=00 0E 0A 71 05 00 00 00 FF 07 00 01 09 
2018-11-21 23:49:08.732 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2018-11-21 23:49:08.733 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 14: Application Command Request (ALIVE:DONE)
2018-11-21 23:49:08.733 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 14: resetResendCount initComplete=true isDead=false
2018-11-21 23:49:08.734 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 14: Incoming command class COMMAND_CLASS_ALARM, endpoint 0
2018-11-21 23:49:08.734 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 14: SECURITY NOT required on COMMAND_CLASS_ALARM
2018-11-21 23:49:08.735 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 14: Received COMMAND_CLASS_ALARM V5 NOTIFICATION_REPORT
2018-11-21 23:49:08.735 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 14: NOTIFICATION report - 0 = 0, event=0, status=255, plen=1
2018-11-21 23:49:08.736 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 14: Alarm Type = BURGLAR (0)
2018-11-21 23:49:08.736 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 14: Got an event from Z-Wave network: ZWaveAlarmValueEvent
2018-11-21 23:49:08.736 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 14: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_ALARM, value = 255
2018-11-21 23:49:08.737 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 14: Alarm converter processing NOTIFICATION
2018-11-21 23:49:08.737 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 14: Alarm converter NOTIFICATION event is 0, type OnOffType
2018-11-21 23:49:08.738 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 14: Updating channel state zwave:device:c949557e:node14:alarm_burglar to OFF [OnOffType]
2018-11-21 23:49:08.740 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 14: Commands processed 1.
2018-11-21 23:49:08.740 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 14: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@610a3106.
2018-11-21 23:49:08.741 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2018-11-21 23:49:08.741 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2018-11-21 23:49:08.741 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2018-11-21 23:49:08.742 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
2018-11-21 23:49:13.520 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 10 00 04 00 02 0A 71 05 00 00 00 FF 07 00 01 08 66 
==> /var/log/openhab2/events.log <==
2018-11-21 23:49:13.523 [vent.ItemStateChangedEvent] - zwave_serial_zstick_c949557e_serial_sof changed from 6080 to 6081
==> /var/log/openhab2/openhab.log <==
2018-11-21 23:49:13.524 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=2, callback=0, payload=00 02 0A 71 05 00 00 00 FF 07 00 01 08 
2018-11-21 23:49:13.524 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=2, callback=0, payload=00 02 0A 71 05 00 00 00 FF 07 00 01 08 
2018-11-21 23:49:13.525 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null

Does anyone else experience the same issues with the MS02 type 200 or type 201?

Thanks a lot!

2

I don’t know why you are not receiving the ON while you are receiving OFF on the Lifeline (that’s strange)

Can you try the following: Enable BASIC_SET command using:
Set Parameter 14 to 1
Make sure that Association Group 2 is linked to the Controller

If I am not wrong, payload 255 is considered OFF, so you may want to change Parameter 15 to 1 also (not sure)

3

Hi,

Thanks for your help and information.
I tried setting the proposed values via PaperUI, but the final result is exactly the same.

In the meanwhile, trying to get the settings updated, I’m now at node 17 (previously node 14) and I must add that it is really painful and time-consuming, adding zwave devices to openhab. Anyway… :slight_smile:

The result in the debug log shows the following, when motion is detected:

NODE 17: Alarm converter NOTIFICATION event is 8, type OnOffType
NODE 17: Commands processed 1

After a while the OFF messaged is sent, as before.

NODE 17: Alarm converter NOTIFICATION event is 0, type OnOffType
NODE 17: Updating channel state zwave:device:c949557e:node17:alarm_burglar to OFF [OnOffType]
NODE 17: Commands processed 1

Digging into the manual, I see a parameter 18, which is not in the zwave settings for this device. There is a paramter 17 in the zwave openhab settings, but that is nowhere mentioned in the manual. I don’t know if this means anything. But it seems some device definitions are incorrect , compared between the manual and database entries.

Parameter No.18 MOTION ALARM CANCELLATION DELAY

Motion alarm will be canceled in the main controller after 3 seconds, the alarm cancellation can
be delay by this parameter. Any motion detected during the cancellation delay time countdown
will result in the countdown being restarted. Available settings: 0-65535 (seconds)

Default setting: 30 (seconds)
Parameter size: 1[byte]

The following is NOT mentioned in the manual, but configurable in Openhab:

Parameter 17: enable/disable shock alarm  
Disable/Enable

Could this mean that the type 200 is a bit different or at least with other functions than the type 201?
The type 200 has recently been added to the database, with type 201 as the reference device.

Thanks for helping!

4

yup.
can you upload here the xml that this node produces in /var/lib/openhab2/zwave/?

use code fences to post it

5

I have attached the xml files, which is generated by openhab and I also found that following parameters differ with the manual:

In the manual:

Parameter NO. 12 MOTION SENSOR’S SENSITIVITY
The higher the value, the more sensitive the PIR sensor. 

Available settings: 1-8
Default setting: 8
Parameter size: 1 [byte]

Openhab zwave database:

12: Motion Sensor`s Sensitivity
Available settings: 0-2

And lastly, parameter 14 and 15 have reversed descriptions, comparing the manual and the actual description in openhab (paperUI).

Here are two XML Node files for this device:
hkzwms02-type200_OH2.4.xml (12.9 KB)
hkzwms02-type200_OH2.3.xml (8.1 KB)

6

@chris : I need some help here since I am not yet very familiar with this scenario…
There is already a DB entry here: 676 (for both 0200 and 0201 types) with some missing info and parameters

Should I update that DB entry or copy that and create a new one (for type 0200) using the xml from the post above ?

7

The question I have is if the differences seen in these parameters are errors in the database, or changes to the firmware. If they are errors, then we should just fix them - if the firmware has been updated, then we’d need a new database entry.

If it’s possible to find the manual for the old device (it should be attached to the database) then it is hopefully possible to check this.

If you have to create a new version, let me know as it probably requires a little messing around which I’ll need to do to get the new entry added in the first place.

Looking at the original issue - it is probably caused by the channel type being wrong - I’ve just updated this to alarm_motion.

Thanks @Dim.

1 Like
8

I don’t know if we can find the info about the firmware of the device that was used to create the existing entry on 2018-01-13 (to compare with the one that @openhab-aj has)

The manual that was uploaded at that time, does describe additional parameters that are not included in the DB entry (18 = motion alarm cancelation delay).

I think that I will try the following: Update existing entry with all additional info that we have and then we will see if things improve.

9

Sounds fine to me - thanks.

I don’t think the parameters will make any difference to the motion not working - that should be fixed though by the channel change that I made.

1 Like
10

Here is a manual for v1.0, which I found. This one mentions parameter 17 and also 18.

The manual I have, which came with the product (on paper) doesn’t mention parm 17, it is the same manual as uploaded on the cd-jackson website. I know that “The SuperUser” uploaded that manual recently (after making the type 0200 change) and that there was no manual included before.

HKZW-MS02-ProductManual.pdf (v1.0) (711.0 KB)

HKZW-MS02-ProductManual.pdf (v1.1)

1 Like
11

I have updated the zwave-binding (removing and reinstalling via PaperUI, didn´t work as expected). I have stopped openhab cleaned …/tmp and …/cache and started openhab again. I hope that is the correct way to get the latest zwave database updated?

After starting openhab, I checked the logs for alarm_motion messages, but there is no change in behavior, still the exact same results. I already tried to remove and rescan with PaperUI. Do I need to exclude/re-include the zwave device?

If yes, does anyone know how to properly exclude with openhab UI’s. Trying to exclude devices, I always end up with dead-devices, and then I need to use a 3rd -party tool to remove it from the zwave-stick (zensystools).

Thank you all!

12

which steps did you follow to do this?

to get the latest version of the DB, you need to update to the latest Z-Wave binding jar since the xml DB is embedded into the binding itself. I assume that you are on OH2.4.x.

I will do the parameters update also but the fix that Chris provided should be in the latest jar

You shouldn’t need to exclude and re-include. With the latest jar enabled, just remove the Thing and re-discover it

13

I have updated the entry @ https://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/676

to include Parameter 18 and made some cosmetic changes to the other DB entries

Waiting review. These are minor changes and do not affect functionality.

14

Thanks very much @Dim: +1:

I will update to the latest OH2.4 snapshot, check and post the results.

For updating the zwave-binding, I first removed the binding within PaperUI and then reinstalled, since that didn’t work, I stopped openhab and cleaned the /var/lib/openhab2/tmp/* and /var/lib/openhab2/cache/* directories, then started openhab up again. I assumed that the zwave-binding (inlcuding) database would get updated that way?

I probably have to do I complete update/reinstall of the latest snapshot release, or get the .jar somewhere and install with karaf, right?

B.T.W. I had completely missed the option for zwave-exclusion in the controller options of PaperUI and Habmin. Next time, when excluding, I’ll try that.

Thanks a lot!

15

To update the Z-Wave database which is included in the Z-Wave binding, you need to update the Z-Wave Binding itself (the jar file)

but… if you are on a specific openHAB2 version, uninstalling the binding from PaperUI and re-installing it will bring back the same jar (with the same database info)

To get the latest database, you have 2 options:
a) Upgrade your OH2 core to a newer one (this will bring along the corresponding Z-Wave binding)
b) Keep your OH2 core at same version, uninstall the included binding and deploy manually a newer version of the Z-Wave binding in the addons folder

The latest and greatest Z-Wave binding jar can be found @ https://ci.openhab.org/job/openHAB2-Bundles/lastBuild/org.openhab.binding$org.openhab.binding.zwave/

Keep in mind also that after you update your Z-Wave binding using either method, you need to delete the existing discovered Thing and re-discover it in order to get all the updated parameters from the new DB.

Example:
File org.openhab.binding.zwave-2.3.0.jar (which is included in the OH 2.3.0 Stable) has a timestamp of: 28/May/2018 and a file size of: 2.012.153 bytes
File org.openhab.binding.zwave-2.4.0-SNAPSHOT.jar (from OH 2.4.0 Snapshot #1443) has a timestamp of: 25/Nov/2018 and a file size of: 2.378.950 bytes)

16

Hello again,

I have updated to the latest z-wave binding. In the Karaf console I can see this:
190 │ Active │ 80 │ 2.4.0.201811281515 │ ZWave Binding

After putting the .jar file in /usr/share/openhab2/addons folder, openhab tries to install, but fails with a java exception:

[WARN ] [org.apache.felix.fileinstall] - Error while starting bundle: file:/usr/share/openhab2/addons/org.openhab.binding.zwave-2.4.0-SNAPSHOT.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.zwave [190]
  Unresolved requirement: Import-Package: gnu.io

To resolve this I did
feature:install openhab-transport-serial in the karaf console (ssh -p 8101 openhab@localhost).

Then the z-wave binding started. After this I removed the device from paperUI and then rescanned. But I don’t see a change in the configuration parameters e.g. I don’t see the parameter 18, after the device is (re)added.

I also stopped, cleaned /var/lib/openhab2/tmp and openhab2/cache and started openhab (you again need to do feature:install openhab-transport-serial); removed the device and scanned again, but no changes.

Any clue or ideas?

17

The new parameters will be made available a couple of days after the DB entry has been updated, approved and finally exported.

In this specific case, the entry was added on: 27/Nov/18, it was approved and it was exported also a few mins later.

So: Your binding with a timestamp of: 28/Nov/18. Does not have (yet) the new parameters for this device.

You can check yourself by:
extracting the jar (using an archive tool like 7zip) and browsing to:
org.openhab.binding.zwave-2.4.0-SNAPSHOT\ESH-INF\thing\hank
You will find there the file: hkzwms02_0_0.xml

Most likely, the next build will include the new stuff.

18

ah, Thanks @Dim,

I’ll check again on a later moment then. Thanks for the info, much appreciated!

1 Like
19

The device should work now properly since Chris updated the channel type.
Does it work ok? (even with the missing parameter # 18)

20

I haven’t checked that yet. Will do when I get home. I know I have still seen a channel alarm_burglar, where I would expect alarm_motion. But I´ll check first :slight_smile:

1 Like