Channel - Fibaro Motion Sensor FGMS001 FW 2.7

Raspi 3B
Installation: Openhabian
openHAB 2.4.0 Build # 1380
Aeotec Z-Stick Gen5

Fibaro Motion Sensor FGMS001 FW 2.7

The motion sensor does not work with the alarm_motion channel, but with the alarm_tamper channel.
Before the conversion of the zwave binding it was always on the binary_sensor channel.

I have one with firmware 2.7 and the motion alarm channel is working. I did not link the tamper alarm channel.

The motion alarm channel does not react to me.

This is strange. The new binding directly interprets the commands, so unless this device is sending the wrong event numbers, I’m not sure it can be wrong in the binding or it would be wrong for every motion sensor device.

It’s possible you may need to change some configuration in the device? The binary_sensor channel is an old channel, so in general I try to use the notification command class (ie alarm) these days and maybe your device needs to be configured differently?

Anyway, can you provide a debug log and I will be happy to take a look.

2018-10-08 10:26:28.505 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0

2018-10-08 10:26:28.506 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty

2018-10-08 10:26:28.508 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.

2018-10-08 10:26:36.240 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 09 00 04 00 16 03 30 03 FF 2B

2018-10-08 10:26:36.248 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=22, callback=0, payload=00 16 03 30 03 FF

2018-10-08 10:26:36.252 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=22, callback=0, payload=00 16 03 30 03 FF

2018-10-08 10:26:36.254 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null

2018-10-08 10:26:36.257 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 22: Application Command Request (ALIVE:DONE)

2018-10-08 10:26:36.259 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 09 00 04 00 16 03 20 01 FF 39

2018-10-08 10:26:36.259 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 22: resetResendCount initComplete=true isDead=false

2018-10-08 10:26:36.263 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 22: Incoming command class COMMAND_CLASS_SENSOR_BINARY, endpoint 0

2018-10-08 10:26:36.266 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 22: SECURITY not supported

2018-10-08 10:26:36.267 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=22, callback=0, payload=00 16 03 20 01 FF

2018-10-08 10:26:36.269 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 22: Received COMMAND_CLASS_SENSOR_BINARY V1 SENSOR_BINARY_REPORT

2018-10-08 10:26:36.273 [DEBUG] [dclass.ZWaveBinarySensorCommandClass] - NODE 22: Sensor Binary report, type=Unknown, value=255

2018-10-08 10:26:36.276 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 22: Got an event from Z-Wave network: ZWaveBinarySensorValueEvent

2018-10-08 10:26:36.279 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 22: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_SENSOR_BINARY, value = 255

2018-10-08 10:26:36.283 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 22: Updating channel state zwave:device:512:node22:alarm_motion to ON [OnOffType]

2018-10-08 10:26:36.286 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 22: Commands processed 1.

2018-10-08 10:26:36.289 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 22: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@1220390.

2018-10-08 10:26:36.292 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0

2018-10-08 10:26:36.294 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0

2018-10-08 10:26:36.297 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=22, callback=0, payload=00 16 03 20 01 FF

2018-10-08 10:26:36.300 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null

2018-10-08 10:26:36.303 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 22: Application Command Request (ALIVE:DONE)

2018-10-08 10:26:36.305 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 22: resetResendCount initComplete=true isDead=false

2018-10-08 10:26:36.308 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 22: Incoming command class COMMAND_CLASS_BASIC, endpoint 0

2018-10-08 10:26:36.311 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 22: SECURITY not supported

2018-10-08 10:26:36.314 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 22: Received COMMAND_CLASS_BASIC V1 BASIC_SET

2018-10-08 10:26:36.316 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 22: Basic report, value = 255

2018-10-08 10:26:36.319 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 22: Got an event from Z-Wave network: ZWaveCommandClassValueEvent

2018-10-08 10:26:36.322 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 22: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_BASIC, value = 255

2018-10-08 10:26:36.325 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 22: Updating channel state zwave:device:512:node22:alarm_tamper to ON [OnOffType]

2018-10-08 10:26:36.331 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 22: Commands processed 1.

2018-10-08 10:26:36.336 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 22: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@1555d66.

2018-10-08 10:26:36.341 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0

==> /var/log/openhab2/events.log <==

2018-10-08 10:26:36.342 [vent.ItemStateChangedEvent] - Bewegungsmelder_TE changed from OFF to ON

It doesn’t look like the device is sending the correct messages. What associations are configured? IS there any other configuration that alters what the device sends?

In HABmin under Association Groups in
1: Controller (in progress)
2: - (in progress)
3: - (in progress)

Which configuration could change that?

You should only have the one called “Controller” - which is group 3. Don’t set the others as it will likely cause problems.

However, looking at your log again, it looks like it is working -:

Your statement above doesn’t seem correct -:

To me, this looks ok - the binding is updating the channel correctly. Or am I misunderstanding something?

2018-10-08 14:47:29.775 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:512:node22' has been updated.
2018-10-08 14:47:29.784 [vent.ConfigStatusInfoEvent] - ConfigStatusInfo [configStatusMessages=[ConfigStatusMessage [parameterName=group_1, type=PENDING, messageKey=null, arguments=null, message=null, statusCode=null], ConfigStatusMessage [parameterName=group_3, type=PENDING, messageKey=null, arguments=null, message=null, statusCode=null], ConfigStatusMessage [parameterName=group_2, type=PENDING, messageKey=null, arguments=null, message=null, statusCode=null], ConfigStatusMessage [parameterName=config_16_1, type=PENDING, messageKey=null, arguments=null, message=null, statusCode=null], ConfigStatusMessage [parameterName=wakeup_node, type=PENDING, messageKey=null, arguments=null, message=null, statusCode=null], ConfigStatusMessage [parameterName=config_12_1, type=PENDING, messageKey=null, arguments=null, message=null, statusCode=null], ConfigStatusMessage [parameterName=config_14_1, type=PENDING, messageKey=null, arguments=null, message=null, statusCode=null], ConfigStatusMessage [parameterName=config_64_2, type=PENDING, messageKey=null, arguments=null, message=null, statusCode=null], ConfigStatusMessage [parameterName=config_20_1, type=PENDING, messageKey=null, arguments=null, message=null, statusCode=null], ConfigStatusMessage [parameterName=config_40_2, type=PENDING, messageKey=null, arguments=null, message=null, statusCode=null], ConfigStatusMessage [parameterName=config_87_1, type=PENDING, messageKey=null, arguments=null, message=null, statusCode=null], ConfigStatusMessage [parameterName=config_62_2, type=PENDING, messageKey=null, arguments=null, message=null, statusCode=null], ConfigStatusMessage [parameterName=config_86_1, type=PENDING, messageKey=null, arguments=null, message=null, statusCode=null], ConfigStatusMessage [parameterName=config_42_2, type=PENDING, messageKey=null, arguments=null, message=null, statusCode=null], ConfigStatusMessage [parameterName=config_83_2, type=PENDING, messageKey=null, arguments=null, message=null, statusCode=null], ConfigStatusMessage [parameterName=config_82_2, type=PENDING, messageKey=null, arguments=null, message=null, statusCode=null], ConfigStatusMessage [parameterName=config_60_1, type=PENDING, messageKey=null, arguments=null, message=null, statusCode=null], ConfigStatusMessage [parameterName=config_81_1, type=PENDING, messageKey=null, arguments=null, message=null, statusCode=null], ConfigStatusMessage [parameterName=config_80_1, type=PENDING, messageKey=null, arguments=null, message=null, statusCode=null], ConfigStatusMessage [parameterName=wakeup_interval, type=PENDING, messageKey=null, arguments=null, message=null, statusCode=null], ConfigStatusMessage [parameterName=config_1_1, type=PENDING, messageKey=null, arguments=null, message=null, statusCode=null], ConfigStatusMessage [parameterName=config_2_1, type=PENDING, messageKey=null, arguments=null, message=null, statusCode=null], ConfigStatusMessage [parameterName=config_6_2, type=PENDING, messageKey=null, arguments=null, message=null, statusCode=null], ConfigStatusMessage [parameterName=config_8_1, type=PENDING, messageKey=null, arguments=null, message=null, statusCode=null], ConfigStatusMessage [parameterName=config_9_2, type=PENDING, messageKey=null, arguments=null, message=null, statusCode=null], ConfigStatusMessage [parameterName=config_3_1, type=PENDING, messageKey=null, arguments=null, message=null, statusCode=null], ConfigStatusMessage [parameterName=config_22_2, type=PENDING, messageKey=null, arguments=null, message=null, statusCode=null], ConfigStatusMessage [parameterName=config_4_1, type=PENDING, messageKey=null, arguments=null, message=null, statusCode=null], ConfigStatusMessage [parameterName=config_24_1, type=PENDING, messageKey=null, arguments=null, message=null, statusCode=null], ConfigStatusMessage [parameterName=config_66_2, type=PENDING, messageKey=null, arguments=null, message=null, statusCode=null], ConfigStatusMessage [parameterName=config_26_1, type=PENDING, messageKey=null, arguments=null, message=null, statusCode=null], ConfigStatusMessage [parameterName=config_89_1, type=PENDING, messageKey=null, arguments=null, message=null, statusCode=null]]]
==> /var/log/openhab2/openhab.log <==
2018-10-08 14:47:29.855 [DEBUG] [l.initialization.ZWaveNodeSerializer] - NODE 22: Serializing from file /var/lib/openhab2/zwave/network_ecc5efe4__node_22.xml
2018-10-08 14:47:29.857 [DEBUG] [l.initialization.ZWaveNodeSerializer] - NODE 22: Error serializing from file: file does not exist.
2018-10-08 14:47:29.859 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 22: Starting initialisation from EMPTYNODE
2018-10-08 14:47:29.862 [DEBUG] [ve.internal.protocol.ZWaveController] - NODE 22: Init node thread finished
2018-10-08 14:47:29.862 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 22: Node advancer - advancing to IDENTIFY_NODE
2018-10-08 14:47:29.869 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 22: Node advancer: Initialisation starting
2018-10-08 14:47:29.871 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 255: sendTransaction org.openhab.binding.zwave.internal.protocol.ZWaveSerialPayload@ef6a03
2018-10-08 14:47:29.874 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 255: Added 2457 to queue - size 1
2018-10-08 14:47:29.876 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
2018-10-08 14:47:29.879 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 04 00 41 16 AC 
2018-10-08 14:47:29.882 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 255: Sending REQUEST Message = 01 04 00 41 16 AC 
2018-10-08 14:47:29.884 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Message SENT
2018-10-08 14:47:29.887 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage started: TID 2457: [WAIT_RESPONSE] priority=Controller, requiresResponse=true, callback: 0
2018-10-08 14:47:29.887 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 06
2018-10-08 14:47:29.891 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=null[0], type=ACK[2], dest=255, callback=0, payload=
2018-10-08 14:47:29.894 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=null[0], type=ACK[2], dest=255, callback=0, payload=
2018-10-08 14:47:29.897 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction TID 2457: [WAIT_RESPONSE] priority=Controller, requiresResponse=true, callback: 0
2018-10-08 14:47:29.897 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 09 01 41 53 9C 00 04 20 01 5C 
2018-10-08 14:47:29.899 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg: ACK
2018-10-08 14:47:29.901 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2018-10-08 14:47:29.904 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 1 out at start. Holdoff false.
2018-10-08 14:47:29.903 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=IdentifyNode[65], type=Response[1], dest=255, callback=0, payload=53 9C 00 04 20 01 
2018-10-08 14:47:29.907 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=IdentifyNode[65], type=Response[1], dest=255, callback=0, payload=53 9C 00 04 20 01 
2018-10-08 14:47:29.909 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction TID 2457: [WAIT_RESPONSE] priority=Controller, requiresResponse=true, callback: 0
2018-10-08 14:47:29.911 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Checking outstanding transactions: 1
2018-10-08 14:47:29.913 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Last transaction: TID 2457: [WAIT_RESPONSE] priority=Controller, requiresResponse=true, callback: 0
2018-10-08 14:47:29.916 [DEBUG] [ve.internal.protocol.ZWaveController] - Incoming Message: Message: class=IdentifyNode[65], type=Response[1], dest=255, callback=0, payload=53 9C 00 04 20 01 
2018-10-08 14:47:29.918 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 22: ProtocolInfo
2018-10-08 14:47:29.920 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 22: Listening = false
2018-10-08 14:47:29.923 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 22: Routing   = true
2018-10-08 14:47:29.924 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 22: Beaming   = true
2018-10-08 14:47:29.927 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 22: Version   = 4
2018-10-08 14:47:29.929 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 22: FLIRS     = false
2018-10-08 14:47:29.932 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 22: Security  = false
2018-10-08 14:47:29.934 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 22: Max Baud  = 40000
2018-10-08 14:47:29.937 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 22: Basic    = BASIC_TYPE_ROUTING_SLAVE
2018-10-08 14:47:29.939 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 22: Generic  = GENERIC_TYPE_SENSOR_BINARY
2018-10-08 14:47:29.941 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 22: Specific = SPECIFIC_TYPE_ROUTING_SENSOR_BINARY
2018-10-08 14:47:29.943 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 22: Creating new instance of command class COMMAND_CLASS_NO_OPERATION
2018-10-08 14:47:29.946 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 22: Command class COMMAND_CLASS_NO_OPERATION, endpoint 0 created
2018-10-08 14:47:29.948 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 22: Version = 1, version set. Enabling extra functionality.
2018-10-08 14:47:29.951 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 22: Adding command class COMMAND_CLASS_NO_OPERATION to the list of supported command classes.
2018-10-08 14:47:29.952 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 22: Creating new instance of command class COMMAND_CLASS_BASIC
2018-10-08 14:47:29.955 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 22: Command class COMMAND_CLASS_BASIC, endpoint 0 created
2018-10-08 14:47:29.958 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 22: Adding command class COMMAND_CLASS_BASIC to the list of supported command classes.
2018-10-08 14:47:29.960 [DEBUG] [e.internal.protocol.ZWaveTransaction] - TID 2457: Transaction COMPLETED
2018-10-08 14:47:29.962 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 255: Response processed after 76ms
2018-10-08 14:47:29.965 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 255: TID 2457: Transaction completed
2018-10-08 14:47:29.966 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 255: notifyTransactionResponse TID:2457 DONE
2018-10-08 14:47:29.969 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2018-10-08 14:47:29.969 [DEBUG] [nal.protocol.ZWaveTransactionManager] - TID 2457: Transaction event listener: DONE: DONE -> 
2018-10-08 14:47:29.971 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
2018-10-08 14:47:29.972 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 22: Node Init response (0) org.openhab.binding.zwave.internal.protocol.ZWaveTransactionResponse@170173
2018-10-08 14:47:29.974 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 22: Node Init transaction completed with response COMPLETE
2018-10-08 14:47:29.976 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 22: Node advancer - advancing to REQUEST_NIF
2018-10-08 14:47:29.979 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 22: sendTransaction org.openhab.binding.zwave.internal.protocol.ZWaveSerialPayload@1159615
2018-10-08 14:47:29.981 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 22: Bump transaction 2458 priority from Controller to Immediate
2018-10-08 14:47:29.983 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 22: Adding to device queue
2018-10-08 14:47:29.986 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 22: Added 2458 to queue - size 6
2018-10-08 14:47:29.988 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
2018-10-08 14:49:31.171 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'haus.items'
2018-10-08 14:49:36.451 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'haus.items'
2018-10-08 14:52:21.323 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'haus.items'
2018-10-08 14:52:21.449 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 22: Channel zwave:device:512:node22:alarm_motion unlinked - polling stopped.
2018-10-08 14:52:21.454 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 22: Channel zwave:device:512:node22:alarm_tamper unlinked - polling stopped.
==> /var/log/openhab2/events.log <==
2018-10-08 14:52:21.452 [temChannelLinkRemovedEvent] - Link 'Bewegungsmelder_TE => zwave:device:512:node22:alarm_motion' has been removed.
2018-10-08 14:52:21.459 [temChannelLinkRemovedEvent] - Link 'Bewegungsmelder_TE => zwave:device:512:node22:alarm_tamper' has been removed.
==> /var/log/openhab2/openhab.log <==
2018-10-08 14:52:46.698 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'haus.items'
2018-10-08 14:52:46.739 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 22: Channel zwave:device:512:node22:alarm_motion linked - polling started.
==> /var/log/openhab2/events.log <==
2018-10-08 14:52:46.744 [.ItemChannelLinkAddedEvent] - Link 'Bewegungsmelder_TE-zwave:device:512:node22:alarm_motion' has been added.``

Protocol after changing the channels.

Sorry, but I’m not really sure what you mean?

Hello Chris, thanks, it works now with the alarm_motion channel.

My battery devices, not just the motion sensor, keep falling into REQUEST_NIF mode, even though they’re all “online.”
Also, according to HABmin zwave viewer are all connected and also among neighbors are each connected several.
What does that mean and what can I change?
That’s very unreliable.

Nodes should not revert to REQUEST_NIF unless you restart the binding. During a restart, the binding will request some information from the device to ensure the state is known. This does not impact the operation of the device - hence they are online.

What do you want to change? I don’t think there is a problem?

I don’t understand what is unreliable? None of the above should impact the device operation. If there is a problem that I’m not understanding from your description, please provide a debug log.

Sorry Chris, unfortunately the devices do not work when REQUESTED_NIF is displayed on the devices.
At noon everything worked, but in the evening the motion detector, the door contact and the flood sensors were undefined again.
Should I request a ticket and send the complete LOG file to your homepage?

Then possibly there is another issue as the state should not prevent the device sending events.

If you can provide the log I’ll have a look.

File is available on the homepage at Your tracking ID: Cp8LBrRt4gf

addendum:
Today, the “door sensor sauna” (Node 22) has sent three e-mails: “sauna door open”, although the door was not moved,
9:41, 10:48, 10:57.
I send a newer openhab.log to the homepage

If the device is sending reports, then this is not an issue with the binding, so I’m not sure what you expect I can do?

Das meinte ich mit unzuverlässig.

Auch in den UI`s sind immer wieder falsche oder fehlende Zustände, falsche oder fehlende Temperaturen und fehlende Batteriestände.
Die Fehler sind nur in den Batteriegeräten (Motion Sensor, Flood Sensoren, Tür Sensoren), nie in den 220-Volt Geräten, lösen aber falsche Aktionen in Steckern und Schaltern aus.