Z-Wave Binding:Abus SHRM10000 included but all channels NULL

Add-ons Bindings
,
1

Hi,
openhab 3.1.0, Raspberry PI 3, openhabian; Z-wave Stick ZMEEUZBB; Latest updates installed
I’ve bought Abus SHRM10000 Smoke detectors. I can include them without problems. They were correctly detected as SHRM10000.
But in the network map I don’t see the nodes of smoke detectors and all channels (alarm_smoke and battery-level) are NULL. Very curios is, no matter if the batteries are putted in or not the the things pages always shows the detectors with state ONLINE.
I also tried to exclude/reset/include them, but no success.

Cheers Peter

2

battery devices need to woken a number of times to fully configure. At the bottom of the UI page for the thing there needs to be five lines.Screenshot 2021-09-10 172956

Also since battery devices are only awake periodically, they will show online until messages are not getting through.

Bob

3

Thank you. But the smoke detector is included since 5 days with no change of this NULL value behavior. Per default it wakes up one times a day, I‘ve also set this value shorter than 24 hours. Unfortunetaly you can‘t wakup this Abus device via pushing a button. You have to wait or put the batteries out and in.
I see this 5 lines at the end. In the network map I don‘t see the nodes.

4

Interesting. Most all channel problems are related to incomplete configuration. So I looked at the device in the zwave binding and I see three channels. Is the battery channel working?

Is there a way to test the device? I have seen some channels be null until they are activated once (my water detector works this way.

As to the nodes not appearing does group 1 on the UI thing page have the controller node? Using the API explorer with the thing ID, does the thing have a bridge ID and is that ID the controller?

As a minor note the XML does refer to a pin that can be pressed.

Inclusion Information

  • Press the pin 3 times within 1.5s, Green LED is Blinking 3 times within 1 second.
  • If Inclusion Process is successful, Green led will turn off.

Exclusion Information

  • Press the pin 3 times within 1.5s.
  • If Exclusion Process is successful, Green led is Blinking 6 times, then turn off.

Wakeup Information

The SHRM10000 does not permanently listen for messages sent from the controller - it will periodically wake up automatically to check if the controller has messages to send, but will sleep most of the time to conserve battery life. The wakeup period can be configured in the user interface - it is advisable not to make this too short as it will impact battery life - a reasonable compromise is 1 hour.

The wakeup period does not impact the devices ability to report events or sensor data. The device can be manually woken with a button press on the device as described below - note that triggering a device to send an event is not the same as a wakeup notification, and this will not allow the controller to communicate with the device.

Bob

5

Thank you Bob. All channels (battery, smoke, binary sensor) have NULL values.
I also thought about to raise the sensor with a real smoketest. Now I will do this.

Association groups are all set to node 1 (the z-wave controler) as target. About the day (and if triggered by battery change) I don‘t see any wakeups in the log.
I also tried to include the device in unsecure mode.
Again, I can include it without any problems (type and channels are correctly detected)
Peter

Update:
I‘ve made now a real smoke tests. The sensor raises an acustic alert but in the openhab events nothing is raised.

6

Here the response from REST API explorer from thing:

`{
  "statusInfo": {
    "status": "ONLINE",
    "statusDetail": "NONE"
  },
  "editable": true,
  "label": "Schlafzimmer - SHRM10000 Smoke detector",
  "bridgeUID": "zwave:serial_zstick:bf6d0d67c4",
  "configuration": {
    "wakeup_node": 1,
    "wakeup_interval": 21600,
    "node_id": 9
  },
  "properties": {
    "zwave_class_basic": "BASIC_TYPE_ROUTING_SLAVE",
    "zwave_class_generic": "GENERIC_TYPE_SENSOR_NOTIFICATION",
    "zwave_frequent": "false",
    "zwave_neighbours": "",
    "modelId": "SHRM10000",
    "zwave_version": "0.0",
    "zwave_listening": "false",
    "manufacturerId": "0403",
    "manufacturerRef": "0002:0003,0400:0002",
    "dbReference": "1047",
    "zwave_deviceid": "3",
    "zwave_nodeid": "9",
    "vendor": "ABUS Security-Center GmbH & Co. KG",
    "defaultAssociations": "1",
    "zwave_routing": "true",
    "zwave_beaming": "true",
    "zwave_secure": "false",
    "zwave_class_specific": "SPECIFIC_TYPE_NOTIFICATION_SENSOR",
    "zwave_manufacturer": "1027",
    "zwave_devicetype": "2"
  },
  "UID": "zwave:device:bf6d0d67c4:node9",
  "thingTypeUID": "zwave:abus_shrm10000_00_000",
  "channels": [
    {
      "linkedItems": [],
      "uid": "zwave:device:bf6d0d67c4:node9:sensor_binary",
      "id": "sensor_binary",
      "channelTypeUID": "zwave:sensor_binary",
      "itemType": "Switch",
      "kind": "STATE",
      "label": "Binary Sensor",
      "description": "Indicates if a sensor has triggered",
      "defaultTags": [],
      "properties": {
        "binding:*:OnOffType": "COMMAND_CLASS_SENSOR_BINARY"
      },
      "configuration": {}
    },
    {
      "linkedItems": [
        "Schlafzimmer_Alarmsmoke"
      ],
      "uid": "zwave:device:bf6d0d67c4:node9:alarm_smoke",
      "id": "alarm_smoke",
      "channelTypeUID": "zwave:alarm_smoke",
      "itemType": "Switch",
      "kind": "STATE",
      "label": "Alarm (smoke)",
      "description": "Indicates if a smoke is triggered",
      "defaultTags": [],
      "properties": {
        "binding:*:OnOffType": "COMMAND_CLASS_ALARM,COMMAND_CLASS_BASIC;type=SMOKE"
      },
      "configuration": {}
    },
    {
      "linkedItems": [
        "Schlafzimmer_Batterieladung"
      ],
      "uid": "zwave:device:bf6d0d67c4:node9:battery-level",
      "id": "battery-level",
      "channelTypeUID": "system:battery-level",
      "itemType": "Number",
      "kind": "STATE",
      "label": "Batterieladung",
      "defaultTags": [],
      "properties": {
        "binding:*:PercentType": "COMMAND_CLASS_BATTERY"
      },
      "configuration": {}
    }
  ]
}

Response headers`

Here from item alarm_smoke

	
Response body
Download

{
  "link": "http://openhabian:8080/rest/items/BrandmelderFlurOben_Alarmsmoke",
  "state": "NULL",
  "stateDescription": {
    "readOnly": true,
    "options": [
      {
        "value": "OFF",
        "label": "OK"
      },
      {
        "value": "ON",
        "label": "Alarm"
      }
    ]
  },
  "commandDescription": {
    "commandOptions": [
      {
        "command": "OFF",
        "label": "OK"
      },
      {
        "command": "ON",
        "label": "Alarm"
      }
    ]
  },
  "editable": true,
  "type": "Switch",
  "name": "BrandmelderFlurOben_Alarmsmoke",
  "label": "Brandmelder Flur Oben",
  "category": "Smoke",
  "tags": [
    "Point"
  ],
  "groupNames": [
    "Brandmelder"
  ]
}
7

I don’t have the device (obviously), but everything mostly looks in order on the OH side. Based on your comments, I’m beginning to wonder if there is a network communication problem. Where is the device relative to the controller? Was it included with both the controller and device in their current locations? Have you found the pin to force a wakeup? Does the manual help show where this “pin” could be? One thing that is missing from the REST API that I have in my devices is last wakeup

“zwave_lastwakeup”: “2021-09-13T11:14:18Z”,

This seems to imply the device hasn’t awaken since inclusion. (and the device and controller aren’t trading messages)

I’m thinking you have to find a way to do a manual wake-up without removing the battery.

Bob

8

I‘ve also ask this in GitHub.

How can I debug such issue?
Does anybody got the SHRM1000 smoke detector working in OpenHab?

The detector is Online but doesn‘t report anything to the controller.

9

So the directions are at the end of the zwave binding documention either in OH or on Github, titled something like" If things do not go as planned…" You are going to need a debug log to see if messages are getting through to the binding and OH. There is a better chance for attention here in the forum, but feel free to do what you have to do.

Bob

10

I‘ve set the logging mode to DEBUG in zwave binding since 2 weeks. And I‘ve got no messages from there.
I never see a wakeup and no errors. I think the missing wakeup messages are the point.
As Chris Jackson states it‘s not a binding issue and if the channels have NULL values the sensor doesn‘t report to the controller.
I’m not very familar with zwave implementation, but I think the sensor reports during wakup to the wrong controler and I can not change the sensors config because they never correctly wakes up. I assume I have to sniff the zwave communication. Maybe the Abus sensors expect another node id per default. It‘s just an idea.

I‘ve also asked if anybody could work wiith this sensor type in Openhab. This would be good to know to get infos about the config.
Cheers Peter

11

Hi Bob,
Chris Jacksons and your advices could helps to solve this issue! I assume the key point is how to force of a wakeup of this device.
I guess the default period of SHRM1000 smoke detector of 24 hrs is very long and I guess openhab won’t keep the changes in command queue for 24 hrs. But this is an assumption only I’m not an expert.

What I have done:

  • Setting controller in low inclusion mode
  • Include the SHRM1000 very closed to controller. Channels has NULL values, wake-up node is 0 (but the controller has id 1)
  • Setting the wake up node to controller, the wake up interval to 60 sec (for testing purpose), and the association to controller with id 1
  wakeup_node: 1
  wakeup_interval: 60
  • config status changes to “pending”
  • ** Random guessing I try to push 3 times the network button, and the “pending” status disappears **

Now the device works as expected!

Cheers Peter

12

Hi Peter,

I have the same issue with my Abus Smoke detectors and I have configured the wake-up according to your suggestion above.
The wake-up seems to work fine (obviously a manual wake-up is triggered with ONE push of the network button):

zwave_short.log (82.6 KB)

However, even after multiple wake-ups, the Battery channel is still not updating from NULL

Do you mean, you have excluded the devices and re-included them with the “Low Power option” on the controller thing?

Thank you!

13

Is the channel linked to an item? In your short log everything looks good and the battery is reported at 100% at 11:25:42.036.

Bob

14

It is you again, Bob :slight_smile:
Yes, it is.

image
image1157×497 30.1 KB

I even recreated it from the thing because I had it configured as Number:Dimensionless and wondered, if this might create issues.

15

I have no idea why it is still Null since the zwave log shows a value being provided. There may be something between the Zwave and the OH UI core that is hung up. You could try to delete thing on the Device UI page (do not exclude), go to inbox zwave scan to pick up the thing again, then wake the device. Also maybe an OH restart might help (with a device wake after).

Bob

16

That might be true, because I have also two Fibaro Motion detectors, which do not receive Battery updates either.
(I have included these newly after I have swithed to the new Aeotec stick.)

I will try this!

Thank you.

EDIT:
I deleted the thing and reincluded it.
The loog looks like this:
zwave_node15.log (52.8 KB)

Please allow a few questions:

image
image978×151 12.3 KB

This “received” is from the point of view of the controller, right (sorry, that’s possibly a stupid question).
Means TX is always going from the controller to the Node and RX from the Node to the controller?
(Here: Battery report from node 15 to the controller)?

image
image787×151 12.6 KB

This indicates a communication problem, but if the Batteryvalue above is received, this does still not explain, why OH is not receiving it on the item.

So, maybe there are two issues:

  1. Network unstable because of not enough z-wave nodes across the house (with concrete ceilings)
  2. General issue with z-wave data into OH

Actually I just recognized that NONE of my battery driven nodes have received any battery level since I started from scratch with the z-wave network (changing the UZB with the Aeotec using the same thing.)
So, there seems to be a general battery node issue. :frowning:

17

Do you keep the wake up interval at 60s or have you raised it later? Can I do this directly after inclusion or shall I wait a heal period?

18

I’m sorry @NCO I do not think I got an alert from your edit. Do you still have issues?

Anyway you are correct about RX and TX.

Also how many of these SHRM1000 do you have? The log shows 6

Bob

19

Thank you very much, Bob.

Actually I gave up and started to test home assistant.
This might be blasphemic to post it here, but it’s worth a try, I guess….
:grimacing: