Fibaro flood sensor: tamper alarm not reported

Add-ons Bindings
, ,
1

Hi,

I have a problem with Fibaro FGFS-101 flood sensor. So far I was able to get working with OpenHAB 2.3.0-1 all its features except for tamper alarm. When tilting/shaking the device it beeps, but thing’s item is not notified on this event. Here is my item definition:

Switch   Kitchen_Flood_TamperAlarm  "Alarm sabotażowy"      <alarm>         (Kitchen)                    {channel="zwave:device:dbf5d9be:node4:alarm_tamper2"}

And here are debug logs taken when tamper alarm was raised:

2018-11-18 16:36:28.362 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 0F 00 04 04 04 07 9C 02 04 00 FF 00 00 D5 00 43 
2018-11-18 16:36:28.368 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
2018-11-18 16:36:28.374 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 0F 00 04 04 04 07 9C 02 04 00 FF 00 00 D5 00 43 
2018-11-18 16:36:28.379 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 0F 00 04 04 04 07 9C 02 04 00 FF 00 00 D5 00 43 
2018-11-18 16:36:28.383 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 0F 00 04 00 04 07 9C 02 04 00 FF 00 00 C6 00 54 
2018-11-18 16:36:28.385 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=04 04 07 9C 02 04 00 FF 00 00 D5 00 
2018-11-18 16:36:28.390 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 4: Application Command Request (ALIVE:DONE)
2018-11-18 16:36:28.393 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 4: Starting initialisation from DONE
2018-11-18 16:36:28.396 [DEBUG] [ve.internal.protocol.ZWaveController] - Event Listener org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer@524f74 already registered
2018-11-18 16:36:28.399 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 4: Incoming command class SENSOR_ALARM
2018-11-18 16:36:28.402 [DEBUG] [ndclass.ZWaveAlarmSensorCommandClass] - NODE 4: Received SENSOR_ALARM command V1
2018-11-18 16:36:28.405 [DEBUG] [ndclass.ZWaveAlarmSensorCommandClass] - NODE 4: Alarm Report: Source=4, Type=General(0), Value=255
2018-11-18 16:36:28.408 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveAlarmSensorValueEvent
2018-11-18 16:36:28.411 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 4: Got an event from Z-Wave network: ZWaveAlarmSensorValueEvent
2018-11-18 16:36:28.415 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 4: Got a value event from Z-Wave network, endpoint = 0, command class = SENSOR_ALARM, value = 255

It seems that tamper alarm reaches my controller, but related item is not informed. Do you know what could be wrong here?

2

Your item above is a switch. Is the tamper alarm a switch item, ON/OFF type or Number?

Also in PaperUI, for the thing, check to see if there are more channels by clicking the “show more” button. Sometimes not all channels are shown until this is clicked.

3

PaperUI reports alarm_tamper2 as a switch.

As for this “show more” button (or rather “show properties”, I believe), this did not change anything in channels list.

4

Show more button on the left side like this example:

Screenshot%20at%202018-11-18%2012-16-22
Screenshot at 2018-11-18 12-16-22.png1023×522 21.9 KB

You may or may not have more channels, just a suggestion to try.

5

Interesting, I don’t have such option in UI. May be related to the thing itself…

image
image.png1047×651 39.8 KB

Anyway, thanks for suggestion.

6

What are you using to see the sensor, BasicUI, ClassicUI, etc…?

7

It’s Paper UI.

8

PaperUI is for setting up and configuring. Create a sitemap file, add your items and use BasicUI. Looking at the log above you should see the switch change state when using something other than PaperUI.

9

True, but of course it can also be used to see the state of items and control things as well :wink:

It is probably worth considering changing to a more recent version of the binding (2.4M5 for example). 2.3 is quite old now and there have been a lot of changes since it was released.

10

Updating may solve the issue but I have seen this before, where PaperUI doesn’t show or allow control of things. Using BasicUI or other has been successful in these cases.

Can’t answer why, though.:thinking:

11

What’s the firmware version of your device? The reason I ask is because there are three different entries in the database covering different firmware versions. The alarm_tamper channel is handled differently in each of the database entries, so it’s important to know the firmware version.

12

FTR, here are the three DB entries.

https://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/127

https://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/392

https://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/408

13

The problem is that tamper alarm is not reported as item state change even in logs. It looks as if alarm reached OpenHAB, but is not translated to thing/item model. Maybe it is due to the fact that tamper alarm is for this thing a generic alarm and there is no match?

2018-11-18 16:36:28.405 [DEBUG] [ndclass.ZWaveAlarmSensorCommandClass] - NODE 4: Alarm Report: Source=4, Type=General(0), Value=255

On the other hand, flood alarm is reported as specific one:

2018-11-18 16:36:29.835 [DEBUG] [ndclass.ZWaveAlarmSensorCommandClass] - NODE 4: Alarm Report: Source=4, Type=Flood(5), Value=1

and is correctly followed by item state update:

2018-11-18 16:36:29.860 [vent.ItemStateChangedEvent] - Kitchen_Flood_FloodAlarm changed from OFF to ON

I’ll try latest OpenHAB version at some point, as Chris suggested…

14

How to check FW version? Would it be through thing properties in PaperUI?

15

Yes, but there’s no line in the log indicating that the state was updated, which is usually a sign that the mapping in the database doesn’t align with what the device is sending (or that there’s no item mapped to the channel, which doesn’t appear to be the case here).

Yes, would highly recommend getting on the latest version of the binding before debugging too deeply.

16

In HABmin, on the Attributes panel for the node in question.

Like this.
version

17

In Paper UI it would be the field named zwave_version.

18

It’s 25.25:
image

19

Agreed - as stated earlier, please use the latest version of the binding.

20

Yep, for v25.25, alarm type GENERAL is mapped to the tamper alarm channel. Upgrading should fix it.