[SOLVED] Shock sensor alarms not triggered

Hi.
I’ve configured without problems the ZS5101 Shock Sensor (https://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/442) using a Z-Wave USB stick (https://z-wave.me/uzb) installed on OH2 (v. 2.4.0-1) binding-zwave v. 2.4.0.
Using either OpenHAB console and Paper-UI I’ve verified that status is “ONLINE” and channels are correctly configured.
The problem is that the Shock Alarm events (Tamper and Alarm) are ignored (not reported by console …)
I’m using other Z-Wave devices that works fine and using rules (… so, Z-Wave controller is working fine …)
I’ve already tried to set the sensibility … without results …
Is there anyone who used this device ?
Have you some suggestion on OpenHAB integration of this device ?

Thanks.
Nicola Cisternino.

Make sure the controller (usually node_1) is in the association group 1. There was a recent update to the binding to ensure the controller is always assigned. But set it manually and see if this helps. You will need to wakeup the device for this to be set. Tailing the log will help to confirm that it was set properly.

Hi Scott
How I can verify the controller association group ?

You will find the associations in the properties of the Thing for the device.

Thank you for replay, Scott.
It seems that association group is “1”

openhab> smarthome:things show zwave:device:fa62667f:node5                                                                           
UID: zwave:device:fa62667f:node5
Type: zwave:vision_zs5101_00_000
Label: Z-Wave Node 005: ZS5101 Shock Sensor
Status: ONLINE
Bridge: zwave:serial_zstick:fa62667f

Properties:
	zwave_class_basic : BASIC_TYPE_ROUTING_SLAVE
	zwave_class_generic : GENERIC_TYPE_SENSOR_NOTIFICATION
	zwave_neighbours : 1,3,4
	zwave_lastwakeup : 2019-02-21T06:34:37Z
	modelId : ZS5101
	zwave_version : 16.6
	zwave_plus_devicetype : NODE_TYPE_ZWAVEPLUS_NODE
	vendor : Vision Security
	defaultAssociations : 1
	zwave_routing : true
	zwave_beaming : true
	zwave_secure : false
	zwave_class_specific : SPECIFIC_TYPE_NOTIFICATION_SENSOR
	zwave_devicetype : 8195
	zwave_frequent : false
	zwave_listening : false
	manufacturerId : 0109
	manufacturerRef : 2003:0306,2003:0307
	dbReference : 442
	zwave_deviceid : 775
	zwave_nodeid : 5
	zwave_lastheal : 2019-02-21T06:34:41Z
	zwave_plus_roletype : ROLE_TYPE_SLAVE_SLEEPING_REPORTING
	zwave_manufacturer : 265

Configuration parameters:
	action_heal : false
	binding_cmdrepollperiod : 1500
	action_reinit : false
	wakeup_node : 1
	action_failed : false
	wakeup_interval : 21750
	group_1 : controller
	action_remove : false
	binding_pollperiod : 86400
	node_id : 5

Channels:
	ID: sensor_binary
	Label: Binary Sensor
	Type: zwave:sensor_binary
	Description: Indicates if a sensor has triggered

	ID: alarm_access
	Label: Shock Alarm
	Type: zwave:alarm_access
	Description: Indicates if the access control alarm is triggered

	ID: alarm_tamper
	Label: Tamper Alarm
	Type: zwave:alarm_tamper
	Description: Indicates if the tamper alarm is triggered

	ID: battery-level
	Label: Battery Level
	Type: system:battery-level
openhab>

Hi.
Problem solved upgrading Z-Wave binding (2.5 snapshot on OH 2.4) … as described in the following post: VISION SECURITY Z-WAVE USB Gen5 controller
Thanks.

I have an issue with my shock sensor ZS5101 as well and I am already on 2.5 stable.

My setup:
Raspberry pi with openhabian and OH 2.5 stable using an ZME_UZB1 Z-wave stick.
several zwave devices work propery:
several Fibaro switches (Wall Plug and others), rollershutter and a sensative strip window contact

The shock sensor used to work properly, but I don’t really know when it stopped working.
In PaperUI all channels are linked properly and if I open the shock sensor I get:
2020-01-04 08:49:13.858 [vent.ItemStateChangedEvent] - Z_Shock_Tamp changed from OFF to ON

However, if I try to trigger a shock, nothing happens.

Karaf returns:
openhab> smarthome:things show zwave:device:12345678-9012-3456-7890-123456789012:node11
UID: zwave:device:12345678-9012-3456-7890-123456789012:node11
Type: zwave:vision_zs5101_00_000
Label: Z-Wave Node 11 (Schock)
Status: ONLINE
Bridge: zwave:serial_zstick:12345678-9012-3456-7890-123456789012

Properties:
        zwave_class_basic : BASIC_TYPE_ROUTING_SLAVE
        zwave_class_generic : GENERIC_TYPE_SENSOR_NOTIFICATION
        zwave_neighbours : 1,3,4,7,9,10,12
        zwave_lastwakeup : 2020-01-04T07:49:35Z
        modelId : ZS5101
        zwave_version : 16.6
        zwave_plus_devicetype : NODE_TYPE_ZWAVEPLUS_NODE
        vendor : Vision Security
        defaultAssociations : 1
        zwave_routing : true
        zwave_beaming : true
        zwave_secure : false
        zwave_class_specific : SPECIFIC_TYPE_NOTIFICATION_SENSOR
        zwave_devicetype : 8195
        zwave_frequent : false
        zwave_listening : false
        manufacturerId : 0109
        manufacturerRef : 2003:0306,2003:0307
        dbReference : 442
        zwave_deviceid : 775
        zwave_nodeid : 11
        zwave_lastheal : 2020-01-04T04:58:50Z
        zwave_plus_roletype : ROLE_TYPE_SLAVE_SLEEPING_REPORTING
        zwave_manufacturer : 265

Configuration parameters:
        action_heal : false
        binding_cmdrepollperiod : 1500
        action_reinit : false
        wakeup_node : 1
        action_failed : false
        wakeup_interval : 21750
        group_1 : [controller]
        action_remove : false
        binding_pollperiod : 86400
        node_id : 11

Channels:
        ID: sensor_binary
        Label: Binary Sensor
        Type: zwave:sensor_binary
        Description: Indicates if a sensor has triggered

        ID: alarm_access
        Label: Shock Alarm
        Type: zwave:alarm_access
        Description: Indicates if the access control alarm is triggered

        ID: alarm_tamper
        Label: Tamper Alarm
        Type: zwave:alarm_tamper
        Description: Indicates if the tamper alarm is triggered

        ID: battery-level
        Label: Batterieladung
        Type: system:battery-level

Could it be a sensor hardware issue? Sometimes things die as they get older.

That’s a valid point.
I would assume a total failure though.

Another option might be low battery - I don’t have a spare on hand, but this will be my next test.
(I just recongized that the battery is shown on 100%)
So, maybe the battery is so low, that the tamper switch is the only operational part of the device.