[SOLVED] Some Z-Wave battery devices are not updating battery level

I know that there are other threads regarding that topic, but since they are mostly older and they do not contain a solution for my problem and due to the fact that the z-wave binding was recently updated to v2.5.0, I decided to start this new thread.

I am using the two z-wave battery devices:

  • FGK101 Door Opening Sensor (as the “smartification”-device of my analogue doorbell - including a temperature sensor)
  • WALLC-S Wall Controller (as a wall controller for my rollershutters)

and they are working fine … that means, they are both sending the information I need (in case if somebody rings the bell or pushes a button on the wall controller).

Unfortunately they both are not updating the battery level!

The door sensor (which I am using as a binary sensor for my door bell with included temperature sensor) is sending a command when somebody rings the bell or when the temperature is changing. But even if I wake the device up manually (by pressing the B-button three times) it is not providing its battery state. The wall controller is also not sending information about its battery level when pushing one of its buttons.

My MT02650 Devolo Thermostat (09356) (which is also a z-wave battery device) is providing its battery level with every temperature update. So there everything is fine.

The items are configured as follows:

Number   klingelsensor_temperature         "Klingelsensor/Temperatur [%.1f °C]"  <temperature>  { channel="zwave:device:71a23be9:node14:sensor_temperature" }
Number   klingelsensor_batterylevel        "Klingelsensor/Batterie [%s %%]"      <battery>      { channel="zwave:device:71a23be9:node14:battery-level" }
Contact  doorbell                          "Klingel betätigt"                    <contact>      { channel="zwave:device:71a23be9:node14:sensor_door" }

Number   wallcs_og_batterie          "WallC-S-Schalter Batterie: [%s %%]" <battery>  { channel="zwave:device:71a23be9:node18:battery-level" }
Number   wallcs_og_scene_number      "WallC-S-Schalter Scene-Number"                 { channel="zwave:device:71a23be9:node18:scene_number" }

Number schlafzimmer_temp_ist                "Ist-Temperatur"   <temperature>  { channel="zwave:device:71a23be9:node30:sensor_temperature" }
Number schlafzimmer_thermostat_batterylevel "Batterie-Level"   <battery>   { channel="zwave:device:71a23be9:node30:battery-level" }

The Wake Up Interval of the door sensor is set to 21600 but (due to a note of Chris Jackson here in the forum) it should provide its battery state at least once an hour.

The Z-Wave controller is set as recipient of the 1st association group (“Lifeline”) for all devices.

My installation is based on:
openHAB 2.5.0~S1479-1 (Build #1479) (openHABian)
binding-zwave - 2.5.0.SNAPSHOT

Does somebody had the same problem and a solution for it or an idea how I can get to the bottom of the problem?

Thank you very much in advance for your support!

Some logs (log level DEBUG for zwave binding):

Waking up the door sensor manually:

2019-01-09 21:08:35.007 [DEBUG] [ve.internal.protocol.ZWaveController] - Incoming Message: Message: class=ApplicationUpdate[73], type=Request[0], dest=14, callback=132, payload=84 0E 18 04 07 01 5E 85 59 22 20 80 70 56 5A 7A 72 8E 71 73 98 2B 9C 30 31 86 84 
2019-01-09 21:08:35.010 [DEBUG] [essage.ApplicationUpdateMessageClass] - NODE 14: Application update request. Node information received. Transaction null
2019-01-09 21:08:35.014 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 14: resetResendCount initComplete=true isDead=false
2019-01-09 21:08:35.016 [DEBUG] [essage.ApplicationUpdateMessageClass] - NODE 14: Application update - no transaction.
2019-01-09 21:08:35.020 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2019-01-09 21:08:35.023 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
2019-01-09 21:08:35.271 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 14: Is awake with 0 messages in the queue
2019-01-09 21:08:35.274 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 14: Start sleep timer at 1000ms
2019-01-09 21:08:35.277 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 14: Got an event from Z-Wave network: ZWaveNodeStatusEvent
2019-01-09 21:08:35.315 [DEBUG] [ve.internal.protocol.ZWaveController] - NODE 14: Node Status event - Node is AWAKE
2019-01-09 21:08:35.777 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 14: WakeupTimerTask 0 Messages waiting, state DONE
2019-01-09 21:08:36.278 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 14: WakeupTimerTask 0 Messages waiting, state DONE
2019-01-09 21:08:36.288 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 14: No more messages, go back to sleep
2019-01-09 21:08:36.290 [DEBUG] [commandclass.ZWaveWakeUpCommandClass] - NODE 14: Creating new message for application command WAKE_UP_NO_MORE_INFORMATION
2019-01-09 21:08:36.293 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 14: SECURITY NOT required on COMMAND_CLASS_WAKE_UP
2019-01-09 21:08:36.295 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 14: Command Class COMMAND_CLASS_WAKE_UP is NOT required to be secured
2019-01-09 21:08:36.298 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 14: sendTransaction org.openhab.binding.zwave.internal.protocol.transaction.ZWaveCommandClassTransactionPayload@67fee
2019-01-09 21:08:36.300 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 14: Bump transaction 12612 priority from Immediate to Immediate
2019-01-09 21:08:36.304 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 14: Adding to device queue
2019-01-09 21:08:36.307 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 14: Added 12612 to queue - size 5
2019-01-09 21:08:36.311 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
2019-01-09 21:08:36.315 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 09 00 13 0E 02 84 08 25 9B DB 
2019-01-09 21:08:36.320 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 14: Sending REQUEST Message = 01 09 00 13 0E 02 84 08 25 9B DB 
2019-01-09 21:08:36.330 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Message SENT
2019-01-09 21:08:36.333 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 06
2019-01-09 21:08:36.334 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage started: TID 12612: [WAIT_RESPONSE] priority=Immediate, requiresResponse=true, callback: 155
2019-01-09 21:08:36.337 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=null[0], type=ACK[2], dest=255, callback=0, payload=
2019-01-09 21:08:36.343 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=null[0], type=ACK[2], dest=255, callback=0, payload=
2019-01-09 21:08:36.345 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 04 01 13 01 E8 
2019-01-09 21:08:36.345 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction TID 12612: [WAIT_RESPONSE] priority=Immediate, requiresResponse=true, callback: 155
2019-01-09 21:08:36.348 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg: ACK
2019-01-09 21:08:36.349 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=SendData[19], type=Response[1], dest=255, callback=0, payload=01 
2019-01-09 21:08:36.351 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2019-01-09 21:08:36.355 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 1 out at start. Holdoff false.
2019-01-09 21:08:36.355 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 07 00 13 9B 00 00 02 72 
2019-01-09 21:08:36.358 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=SendData[19], type=Response[1], dest=255, callback=0, payload=01 
2019-01-09 21:08:36.361 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=SendData[19], type=Request[0], dest=0, callback=155, payload=9B 00 00 02 
2019-01-09 21:08:36.361 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction TID 12612: [WAIT_RESPONSE] priority=Immediate, requiresResponse=true, callback: 155
2019-01-09 21:08:36.364 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Checking outstanding transactions: 1
2019-01-09 21:08:36.367 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Last transaction: TID 12612: [WAIT_RESPONSE] priority=Immediate, requiresResponse=true, callback: 155
2019-01-09 21:08:36.371 [DEBUG] [ve.internal.protocol.ZWaveController] - Incoming Message: Message: class=SendData[19], type=Response[1], dest=255, callback=0, payload=01 
2019-01-09 21:08:36.373 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 14: sentData successfully placed on stack.
2019-01-09 21:08:36.378 [DEBUG] [nal.protocol.ZWaveTransactionManager] - TID 12612: Advanced to WAIT_REQUEST
2019-01-09 21:08:36.380 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 14: TID 12612: Transaction not completed
2019-01-09 21:08:36.384 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=SendData[19], type=Request[0], dest=0, callback=155, payload=9B 00 00 02 
2019-01-09 21:08:36.387 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction TID 12612: [WAIT_REQUEST] priority=Immediate, requiresResponse=true, callback: 155
2019-01-09 21:08:36.390 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Checking outstanding transactions: 1
2019-01-09 21:08:36.393 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Last transaction: TID 12612: [WAIT_REQUEST] priority=Immediate, requiresResponse=true, callback: 155
2019-01-09 21:08:36.396 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Checking TID 12612: (Callback 155)
2019-01-09 21:08:36.399 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Callback match!
2019-01-09 21:08:36.401 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Correlated to TID 12612: callback 155
2019-01-09 21:08:36.403 [DEBUG] [ve.internal.protocol.ZWaveController] - Incoming Message: Message: class=SendData[19], type=Request[0], dest=0, callback=155, payload=9B 00 00 02 
2019-01-09 21:08:36.405 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 14: SendData Request. CallBack ID = 155, Status = Transmission complete and ACK received(0)
2019-01-09 21:08:36.407 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 14: resetResendCount initComplete=true isDead=false
2019-01-09 21:08:36.409 [DEBUG] [e.internal.protocol.ZWaveTransaction] - TID 12612: Transaction COMPLETED
2019-01-09 21:08:36.411 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 14: Response processed after 77ms
2019-01-09 21:08:36.413 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 14: TID 12612: Transaction completed
2019-01-09 21:08:36.414 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 14: notifyTransactionResponse TID:12612 DONE
2019-01-09 21:08:36.417 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 14: Got an event from Z-Wave network: ZWaveTransactionCompletedEvent
2019-01-09 21:08:36.417 [DEBUG] [nal.protocol.ZWaveTransactionManager] - TID 12612: Transaction event listener: DONE: DONE -> 
2019-01-09 21:08:36.418 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2019-01-09 21:08:36.419 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 14: Went to sleep COMPLETE
2019-01-09 21:08:36.420 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.

WallC-S button pressed:

2019-01-09 21:14:12.837 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 0B 00 04 00 12 05 5B 03 03 00 05 B9 
2019-01-09 21:14:12.845 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=18, callback=0, payload=00 12 05 5B 03 03 00 05 
2019-01-09 21:14:12.851 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=18, callback=0, payload=00 12 05 5B 03 03 00 05 
2019-01-09 21:14:12.855 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2019-01-09 21:14:12.859 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 18: Application Command Request (ALIVE:UPDATE_NEIGHBORS)
2019-01-09 21:14:12.864 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 18: Incoming command class COMMAND_CLASS_CENTRAL_SCENE, endpoint 0
2019-01-09 21:14:12.868 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 18: SECURITY not supported
2019-01-09 21:14:12.872 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 18: Received COMMAND_CLASS_CENTRAL_SCENE V1 CENTRAL_SCENE_NOTIFICATION
2019-01-09 21:14:12.877 [DEBUG] [dclass.ZWaveCentralSceneCommandClass] - NODE 18: Received scene 5 at key 0 [Single Press]
2019-01-09 21:14:12.882 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 18: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2019-01-09 21:14:12.886 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 18: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_CENTRAL_SCENE, value = 5.0
2019-01-09 21:14:12.891 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 18: Updating channel state zwave:device:71a23be9:node18:scene_number to 5.0 [DecimalType]
2019-01-09 21:14:12.897 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 18: Commands processed 1.
2019-01-09 21:14:12.902 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 18: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@73a0f0.
2019-01-09 21:14:12.906 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2019-01-09 21:14:12.911 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2019-01-09 21:14:12.915 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2019-01-09 21:14:12.920 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.

I don’t believe that as that sort of would be contradicting all the attempts to save on battery.
Dunno what’s the interval to update on battery. That’s not necessarily the same as the wake up interval.

I’d double check the items definition for battery and all zwave parameters that might be related to it.
Carefully re-read the manuals.
For a start, enable long term logging and see if there’s ANY zwave battery message.

I was referring to this post:

… but it was stated in July 2016 so it must not be true for the current version of the binding.

I think it is not correct, that the battery level will be send every hour.

I fixed this by doing this:

  1. change polling periodfrom 1d to 6h
  2. command poll period: disabled
  3. wakeup configuration: 21600

This gives me every 6h a new battery value as an update.

Keep in mind, if the battery level is not changed you see nothing in the eventlog. Only a rule which triggers on update will see the command from the device.

Thank you very much for that hint, @HomeAutomation! I am gonna check that out.

May I ask you which device do you use this way?

Notes:

  • I am already using an on update trigger (to store the last update time) but no updates are sent.
  • the battery level item is empty in my case, thus never set.

Refresh is something different. It doesn’t mean a message is sent. The device needs to wakeup to do this.

with firmware 2.3, 2.5 and 3.2

Thank you @HomeAutomation and @mstormi for your support. I just reconfigured it and will give feedback tomorrow.

Why mustn’t it be true still? It is as far as I know.

It is also governed by the wakeup interval (unless the device is sending battery level unsolicited at a different interval (eg when it sends notifications).

Sorry, @chris, my translation was bad (I used german-like words). The meaning of my note was: “it does not have to be true furthermore”.

Do I understand your words (in the old and the current thread) correctly when I say that the binding tries to poll the battery state at least once an hour but receives it more frequently if the device …
a) … is programmed to send the battery state with the wake up message and the wake up is configured with an interval less than an hour
b) … sends the battery level along with notifications and there is at least one before the hour is over
c) … is programmed to publish its battery state unsolicited but does so before the hour is over
?

No problem :slight_smile:

Yes, you understand correctly. When the binding polls, it does it every hour - this will not be sent until the next wakeup of the device (which could be another hour, or day, or…). The device can however also send the battery level on its own for the possible reasons you list. Even if the device does this, the binding will still send the poll to request the battery level.

Thank you very much, @chris , for the detailed information! Now I think I got it.

One additional note for others with the same problem:

after reconfiguring my affected devices (like @HomeAutomation suggested) and waking them up to receive the new parameter values, nothing changed in the behaviour which means I got no information about the battery levels of these devices. But as I saw in habmin that the device is now more frequently waking up, I created a second openhab-item for the battery level besides the already existent one … but with the difference that I did it by using the UI instead of defining them in an items-file. From then on, everything worked fine … even with the “old” items. Since then I get the battery state regularly about every six hours. Strange, but it works now!

Thank you very much for your support to all of you!

1 Like

Hi everyone and especially @chris :smiley:

i know, this topic is marked as solved, but i am facing mostly the same problem and didn’t find a solution yet.

I’m running some battery powered z-wave door/window sensors Vision ZD-2102 with an Aeon Z-Stick Gen 5 on Raspberry Pi.

Everything working properly for years with OpenHAB 1.8 an Z-Wave Binding 1.9 Snapshot.

Few weeks ago i did a complete fresh install of openhab 2.4 using openhabian and started migrating all my configuration. I also upgraded to the new 2.4 Z-Wave Binding installed through PaperUI.

Z-Wave Things have been added through Habmin, Items are manually configured in items files.

Now none of my ZD-2102 is reporting it’s battery-level.
With 1.8 it’s been reularly updated. I only have one other battery device, POPE009303, which is updating it’s battery-level.

I already tried to exclude an reinclude one of the devices to the Z-Wave network and readded the thing, but nothing changed. I also tried adding the battery item through PaperUI with no success.

This is my zstick thing

  "zwave:serial_zstick:7c2d2216": {
    "class": "org.eclipse.smarthome.core.thing.internal.BridgeImpl",
    "value": {
      "label": "Z-Wave Serial Controller",
      "channels": [
        {
          "acceptedItemType": "Number",
          "kind": "STATE",
          "uid": {
            "segments": [
              "zwave",
              "serial_zstick",
              "7c2d2216",
              "serial_sof"
            ]
          },
          "channelTypeUID": {
            "segments": [
              "zwave",
              "serial_sof"
            ]
          },
          "label": "Start Frames",
          "description": "Counter tracking the number of SOF bytes received",
          "configuration": {
            "properties": {}
          },
          "properties": {},
          "defaultTags": []
        },
        {
          "acceptedItemType": "Number",
          "kind": "STATE",
          "uid": {
            "segments": [
              "zwave",
              "serial_zstick",
              "7c2d2216",
              "serial_ack"
            ]
          },
          "channelTypeUID": {
            "segments": [
              "zwave",
              "serial_ack"
            ]
          },
          "label": "Frames Acknowledged",
          "description": "Counter tracking the number of frames acknowledged by the controller",
          "configuration": {
            "properties": {}
          },
          "properties": {},
          "defaultTags": []
        },
        {
          "acceptedItemType": "Number",
          "kind": "STATE",
          "uid": {
            "segments": [
              "zwave",
              "serial_zstick",
              "7c2d2216",
              "serial_nak"
            ]
          },
          "channelTypeUID": {
            "segments": [
              "zwave",
              "serial_nak"
            ]
          },
          "label": "Frames Rejected",
          "description": "Counter tracking the number of frames rejected by the controller",
          "configuration": {
            "properties": {}
          },
          "properties": {},
          "defaultTags": []
        },
        {
          "acceptedItemType": "Number",
          "kind": "STATE",
          "uid": {
            "segments": [
              "zwave",
              "serial_zstick",
              "7c2d2216",
              "serial_can"
            ]
          },
          "channelTypeUID": {
            "segments": [
              "zwave",
              "serial_can"
            ]
          },
          "label": "Frames Cancelled",
          "description": "Counter tracking the number of frames cancelled by the controller",
          "configuration": {
            "properties": {}
          },
          "properties": {},
          "defaultTags": []
        },
        {
          "acceptedItemType": "Number",
          "kind": "STATE",
          "uid": {
            "segments": [
              "zwave",
              "serial_zstick",
              "7c2d2216",
              "serial_oof"
            ]
          },
          "channelTypeUID": {
            "segments": [
              "zwave",
              "serial_oof"
            ]
          },
          "label": "OOF Bytes Received",
          "description": "Counter tracking the number of out of flow bytes received",
          "configuration": {
            "properties": {}
          },
          "properties": {},
          "defaultTags": []
        },
        {
          "acceptedItemType": "Number",
          "kind": "STATE",
          "uid": {
            "segments": [
              "zwave",
              "serial_zstick",
              "7c2d2216",
              "serial_cse"
            ]
          },
          "channelTypeUID": {
            "segments": [
              "zwave",
              "serial_cse"
            ]
          },
          "label": "Received Checksum Errors",
          "description": "Counter tracking the number of frames received with checksum errors",
          "configuration": {
            "properties": {}
          },
          "properties": {},
          "defaultTags": []
        }
      ],
      "configuration": {
        "properties": {
          "controller_softreset": false,
          "security_networkkey": "55 17 75 56 3F 2D 18 55 77 1F FD D9 65 2B 9C 93",
          "security_inclusionmode": 0,
          "controller_sisnode": 1,
          "controller_sync": false,
          "port": "/dev/ttyACM0",
          "controller_master": true,
          "inclusion_mode": 2,
          "controller_wakeupperiod": 3600,
          "heal_time": 2,
          "controller_exclude": false,
          "controller_inclusiontimeout": 30,
          "controller_hardreset": false
        }
      },
      "properties": {
        "zwave_neighbours": "2,6,8,9,14,16,17,18,19,20,21,22,23",
        "zwave_nodeid": "1"
      },
      "uid": {
        "segments": [
          "zwave",
          "serial_zstick",
          "7c2d2216"
        ]
      },
      "thingTypeUID": {
        "segments": [
          "zwave",
          "serial_zstick"
        ]
      }
    }
  }

This is one of the ZD-2102 things

  "zwave:device:7c2d2216:node26": {
    "class": "org.eclipse.smarthome.core.thing.internal.ThingImpl",
    "value": {
      "label": "Z-Wave Door Window Sensor Büro Osten",
      "bridgeUID": {
        "segments": [
          "zwave",
          "serial_zstick",
          "7c2d2216"
        ]
      },
      "channels": [
        {
          "acceptedItemType": "Contact",
          "kind": "STATE",
          "uid": {
            "segments": [
              "zwave",
              "device",
              "7c2d2216",
              "node26",
              "sensor_door"
            ]
          },
          "channelTypeUID": {
            "segments": [
              "zwave",
              "sensor_door"
            ]
          },
          "label": "Sensor (Alarm)",
          "description": "Indicates if the door/window is open or closed",
          "configuration": {
            "properties": {}
          },
          "properties": {
            "binding:*:OpenClosedType": "COMMAND_CLASS_ALARM;type\u003dACCESS_CONTROL, event\u003d23"
          },
          "defaultTags": []
        },
        {
          "acceptedItemType": "Switch",
          "kind": "STATE",
          "uid": {
            "segments": [
              "zwave",
              "device",
              "7c2d2216",
              "node26",
              "alarm_tamper"
            ]
          },
          "channelTypeUID": {
            "segments": [
              "zwave",
              "alarm_tamper"
            ]
          },
          "label": "Tamper Alarm",
          "description": "Indicates if the tamper alarm is triggered",
          "configuration": {
            "properties": {}
          },
          "properties": {
            "binding:*:OnOffType": "COMMAND_CLASS_ALARM;BURGLAR"
          },
          "defaultTags": []
        },
        {
          "acceptedItemType": "Number",
          "kind": "STATE",
          "uid": {
            "segments": [
              "zwave",
              "device",
              "7c2d2216",
              "node26",
              "battery-level"
            ]
          },
          "channelTypeUID": {
            "segments": [
              "system",
              "battery-level"
            ]
          },
          "label": "Batterieladung",
          "configuration": {
            "properties": {}
          },
          "properties": {
            "binding:*:PercentType": "COMMAND_CLASS_BATTERY"
          },
          "defaultTags": []
        }
      ],
      "configuration": {
        "properties": {
          "action_heal": false,
          "config_1_1": 0,
          "binding_cmdrepollperiod": 1500,
          "action_reinit": false,
          "wakeup_node": 1,
          "action_failed": false,
          "wakeup_interval": 3600,
          "group_1": [
            "node_1"
          ],
          "action_remove": false,
          "binding_pollperiod": 86400,
          "node_id": 26
        }
      },
      "properties": {
        "zwave_class_basic": "BASIC_TYPE_ROUTING_SLAVE",
        "zwave_class_generic": "GENERIC_TYPE_SENSOR_NOTIFICATION",
        "zwave_frequent": "false",
        "zwave_neighbours": "",
        "modelId": "ZD2102-5",
        "zwave_version": "5.1",
        "zwave_listening": "false",
        "zwave_plus_devicetype": "NODE_TYPE_ZWAVEPLUS_NODE",
        "manufacturerId": "0109",
        "manufacturerRef": "2001:0105,2001:0106",
        "dbReference": "816",
        "zwave_deviceid": "262",
        "zwave_nodeid": "26",
        "vendor": "Vision Security",
        "defaultAssociations": "1",
        "zwave_routing": "true",
        "zwave_plus_roletype": "ROLE_TYPE_SLAVE_SLEEPING_REPORTING",
        "zwave_beaming": "true",
        "zwave_secure": "false",
        "zwave_class_specific": "SPECIFIC_TYPE_NOTIFICATION_SENSOR",
        "zwave_manufacturer": "265",
        "zwave_devicetype": "8193",
        "zwave_lastwakeup": "2019-02-22T10:12:39Z"
      },
      "uid": {
        "segments": [
          "zwave",
          "device",
          "7c2d2216",
          "node26"
        ]
      },
      "thingTypeUID": {
        "segments": [
          "zwave",
          "vision_zd2102plus_00_000"
        ]
      }
    }
  }

And finally the corresponding item

Contact ZWAVE_CONTACT_23         {channel="zwave:device:7c2d2216:node26:sensor_door"}
Number  ZWAVE_CONTACT_23_BATTERY {channel="zwave:device:7c2d2216:node26:battery-level"}

There are no errors or warnings in the logs, battery-level just never occurs.
Hope somebody can help me to identify the problem.

I realized, i wasn’t 100% honest.
There is one error in openhab.log for every of the ZD-2102 devices. This error is only showing up once on system startup.

2019-02-11 20:57:54.435 [ERROR] [pse.smarthome.core.thing.internal.ThingManagerImpl] - Exception occurred during notification about bridge status change on thing 'zwave:device:7c2d2216:node26': 1
java.lang.ArrayIndexOutOfBoundsException: 1
        at org.openhab.binding.zwave.handler.ZWaveThingHandler.initialiseNode(ZWaveThingHandler.java:226) ~[?:?]
        at org.openhab.binding.zwave.handler.ZWaveThingHandler.bridgeStatusChanged(ZWaveThingHandler.java:512) ~[?:?]
        at org.eclipse.smarthome.core.thing.internal.ThingManagerImpl$4.run(ThingManagerImpl.java:901) [109:org.eclipse.smarthome.core.thing:0.10.0.oh240]
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
        at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [?:?]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [?:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
        at java.lang.Thread.run(Thread.java:748) [?:?]

I had the same problem with the ZD-2102 devices.

There must be a change between 2.3 and 2.4 of the z-wave binding which causes this effect. With 2.3 all went good. Tamper and battery was working. With 2.4 version of the binding, both was gone. I had only three of them and exchanged them with fibaro sensors. Now I’m happe again.

This normally happens if the device sends corrupted data - please can you post the debug messages that appear before this.

2.3 and 2.4 are quite different, but I’m not sure what effect you are talking about? Battery requests should be handled the same.

Please provide debug logs - it’s really pretty much impossible to understand what might be wrong without this.

I had battery issues with snapshots of 2.4, stable 2.4, 2.5 M1 zwave battery %s showed up again for my door sensors which are very similar to yours (purchased mine from monoprice). Not saying to upgrade your zwave binding, just passing along something that worked for me.

I thought you would say that. :slight_smile:

I’m not sure which log level to set to DEBUG.
Only the z-wave binding?

# ZWave log appender
log4j2.logger.zwave.name = org.openhab.binding.zwave
log4j2.logger.zwave.level = DEBUG
log4j2.logger.zwave.additivity = false
log4j2.logger.zwave.appenderRefs = zwave
log4j2.logger.zwave.appenderRef.zwave.ref = ZWAVE

seems like there is realy an issue with this version of the binding?

Yes, in Karaf, just type log:set DEBUG org.openhab.binding.zwave.

I think it’s unlikely that there is a general issue or we would have a lot more people talking about this than 2 :wink:

The 2.5 binding hasn’t really seen any changes in the battery management from 2.4 either…

Let’s look at the logs to see what is happening - otherwise we can just speculate, and that won’t get anything fixed.

Hi chris,

not to confuse you. The battery issue is only related to this one z-wave device ZD-2102. All other devices work perfect. I do not have this one anymore, so I cannot make a debug log.