Floodsensor water vs tamper

zwave
Tags: #<Tag:0x00007f1e602a3ca0>
(Ben) #1

Hey,

I just bought the new floodsensor of Fibaro FGFS101 (V2_1).
After looking at the logs, it seems that value3=tamper and value2=water detection. And everything is running fine
In my items, I’m having:

Contact Test “Test [%s]” { zwave=“44” }

When I move the sensor:

2016-09-28 16:43:05.759 [DEBUG] [ApplicationCommandMessageClass:40 ]- NODE 44: Application Command Request (ALIVE:DONE)
2016-09-28 16:43:05.759 [DEBUG] [ApplicationCommandMessageClass:58 ]- NODE 44: Incoming command class ALARM
2016-09-28 16:43:05.759 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:82 ]- NODE 44: Received Alarm Request
2016-09-28 16:43:05.759 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:94 ]- NODE 44: Alarm report - Value = 3
2016-09-28 16:43:05.759 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:113 ]- NODE 44: Alarm Type = General (0)
2016-09-28 16:43:05.760 [DEBUG] [.z.internal.ZWaveActiveBinding:466 ]- NODE 44: Got a value event from Z-Wave network, endpoint = 0, command class = ALARM, value = 3

The status changes from CLOSED to OPEN in my GUI (sitemap)


Water on the sensor:

2016-09-28 16:43:30.133 [DEBUG] [ApplicationCommandMessageClass:40 ]- NODE 44: Application Command Request (ALIVE:DONE)
2016-09-28 16:43:30.133 [DEBUG] [ApplicationCommandMessageClass:58 ]- NODE 44: Incoming command class ALARM
2016-09-28 16:43:30.133 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:82 ]- NODE 44: Received Alarm Request
2016-09-28 16:43:30.133 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:94 ]- NODE 44: Alarm report - Value = 0
2016-09-28 16:43:30.133 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:113 ]- NODE 44: Alarm Type = General (0)
2016-09-28 16:43:30.134 [DEBUG] [.z.internal.ZWaveActiveBinding:466 ]- NODE 44: Got a value event from Z-Wave network, endpoint = 0, command class = ALARM, value = 0
2016-09-28 16:44:33.554 [DEBUG] [ApplicationCommandMessageClass:40 ]- NODE 44: Application Command Request (ALIVE:DONE)
2016-09-28 16:44:33.554 [DEBUG] [ApplicationCommandMessageClass:58 ]- NODE 44: Incoming command class ALARM
2016-09-28 16:44:33.554 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:82 ]- NODE 44: Received Alarm Request
2016-09-28 16:44:33.554 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:94 ]- NODE 44: Alarm report - Value = 2
2016-09-28 16:44:33.554 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:113 ]- NODE 44: Alarm Type = Flood (5)
2016-09-28 16:44:33.555 [DEBUG] [.z.internal.ZWaveActiveBinding:466 ]- NODE 44: Got a value event from Z-Wave network, endpoint = 0, command class = ALARM, value = 2

The status changes nicely from CLOSED to OPEN in my GUI (sitemap)


But I would like to split the alerts of ‘water’ and ‘tamper’ detection. I added following in my items, but the status isn’t updated? Any suggestion?

Contact Test1 “Test Move [%s]” { zwave=“44:command=sensor_alarm, alarm_type=3,respond_to_basic=true” }
Contact Test2 “Test Water [%s]” { zwave=“44:command=sensor_alarm, alarm_type=2,respond_to_basic=true” }


Sitemap:

Text item=Test
Text item=Test1
Text item=Test2

0 Likes

(Oliver Stenzel) #2

I’d say the alarm types should be:
Tamper: Alarm Type = General (0)
Water: Alarm Type = Flood (5)
So:

Contact Test1  "Test Move [%s]" { zwave="44:command=sensor_alarm, alarm_type=0,respond_to_basic=true" }
Contact Test2  "Test Water [%s]"    { zwave="44:command=sensor_alarm, alarm_type=5,respond_to_basic=true" }

But I admit it’s an educated guess :wink:

0 Likes

(Ben) #3

No luck when I change the values to 0 and 5.

But since I see in the logs 2 and 3, should it be these values in the items?
I don’t know if the v2_1 of the floodsensor has something to do with it?

0 Likes

(Oliver Stenzel) #4

Just checked the Examples; your device is listed: https://github.com/openhab/openhab/wiki/Z-wave-Binding-Examples#sensors
Items:

Contact coFibFlood_Alarm    "Water-Sensor:Water [:%s]"   { zwave="44:command=SENSOR_ALARM, alarm_type=5,respond_to_basic=TRUE" }
Number nuFibFlood_Battery   "Water-Sensor: Batterie [%s %%]"      { zwave="44:command=BATTERY" }
Number nuFibFlood_Temp      "Water-Sensor: Temperatur [%.1f °C]" { zwave="44:2:command=sensor_multilevel" }
Switch swFibFlood_Tamper    "Water-Sensor: Tamper"                { zwave="44:command=sensor_alarm, alarm_type=0,respond_to_basic=true" }

According to this, you also need to change the types of your items, but 0 and 5 should be right.

0 Likes

(Ben) #5

I’ve got now:

Switch Test1 “T1 [%s]” { zwave=“44:command=sensor_alarm, alarm_type=0,respond_to_basic=TRUE” }
Contact Test2 “T2 [%s]” { zwave=“44:command=sensor_alarm, alarm_type=5,respond_to_basic=TRUE” }
Contact Test3 “T3 [%s]” { zwave=“44” }

And only Test3 is showing CLOSED > OPEN > CLOSED when I tamper the sensor.

0 Likes

(Oliver Stenzel) #6

Having an Item with only { zwave=“44” } can not be healthy and I assume this is causing your issues.
Use the example config 1:1 and then edit the Labels to your liking.
I use 3 different Fibaro Products (Wall plug, Switch and Motion Sensor) and I’ve used the given examples with great success.

0 Likes

(Ben) #7

When I remove Test3, it’s not changing a lot. Same result: none.

I’ve tried it with following items list, but I’m not getting any info/data shown. Just the labels.

Contact Test1 “Water-Sensor: Water [%s]” { zwave=“44:command=SENSOR_ALARM, alarm_type=5,respond_to_basic=TRUE” }
Number Test3 “Water-Sensor: Batterie [%s %%]” { zwave=“44:command=BATTERY” }
Number Test4 “Water-Sensor: Temperatur [%.1f °C]” { zwave=“44::command=sensor_multilevel” }
Switch Test2 “Water-Sensor: Tamper” { zwave=“44:command=sensor_alarm, alarm_type=0,respond_to_basic=true” }

Also the temperature isn’t working with the example above.
In my case, I was having “44:command=SENSOR_MULTILEVEL,sensor_type=1” for a working temperature.

0 Likes

(Oliver Stenzel) #8

So you have a way to get temperatur. That’s a start. For Battery, you might need to wait a while until the sensor first reports the level.
For Tamper, i noticed that the example is missing the “%s”! maybe adding this could get you one step further (“Water-Sensor: Tamper [%s]”)
Then the actual flood alarm would remain. Being the main purpose of the device it would be a killer if it didn’t work. Maybe reading through this: Zwave binding / FGFS101 Flood Sensor issues an this: Collection of working z-wave configs
could help you finding the right settings…
By the way: What OH Version /ZWave binding version are you using?

0 Likes

(Ben) #9

For the moment, i’m having following test items:

Number Test1 "Test Water [%s]"     { zwave="44:command=SENSOR_ALARM,alarm_type=5,respond_to_basic=true" }
Number Test2 "Test Tamper [%s]"    { zwave="44:command=sensor_alarm,alarm_type=0,respond_to_basic=true" }
Number Test3 "Test Battery [%s %%]"{ zwave="44:command=BATTERY" }
Number Test4 "Test Tempe [%.1f C]" { zwave="44::command=sensor_multilevel,sensor_type=1" }
Contact Test5 "Test watermap [%s]" { zwave="44:command=SENSOR_ALARM, alarm_type=5,respond_to_basic=TRUE"}
Contact Test6 "Test Clean [%s]"    { zwave="44" }

And only test 6 (Test Clean) is showing changes when I tamper/flood the sensor. :blush:

I’m using openhab 1, zwave binding 1.9.0.201609250101. I’ve updated the binding already in the hope it would solve the issue.

(not sure what I’ve done, but guess the sensor / openhab doens’t like me anymore. Nothing is being communicated anymore for that node. I’ve opened/closed the sensor to restart all data. So I guess an exclude/include will be in place)

0 Likes

(Ben) #10

Just tried again a lot of different sequence and so after re-including the sensor.
But only Test6 is being triggered (without any command options).

For now:
Working:

Number  test1   "tst temp [%.1f C]"     <temperature>   { zwave="56:command=SENSOR_MULTILEVEL,sensor_type=1" }
Number  test2   "tst batterij [%s %%]"  <socket>        { zwave="56:command=BATTERY" }
Contact test6   "tst global [%s]"       <water>         { zwave="56" }

Not working: (tamper nor water alert)

Contact test3   "tst 3 [%s]"            <water>         { zwave="56:command=SENSOR_ALARM, alarm_type=5,respond_to_basic=TRUE" }
Contact test4   "tst 4 [%s]"            <water>         { zwave="56:command=sensor_alarm, alarm_type=0,respond_to_basic=true" }
Contact test3   "tst 3a [%s]"            <water>         { zwave="56:command=SENSOR_ALARM, alarm_type=2,respond_to_basic=TRUE" }
Contact test4   "tst 4b [%s]"            <water>         { zwave="56:command=sensor_alarm, alarm_type=3,respond_to_basic=true" }
Contact test3   "tst 3c [%s]"            <water>         { zwave="56:0command=SENSOR_ALARM, alarm_type=5,respond_to_basic=TRUE" }
Contact test4   "tst 4c [%s]"            <water>         { zwave="56:0:command=sensor_alarm, alarm_type=0,respond_to_basic=true" }

If other suggestion, I’m open for them. I’m lost… :blush:

0 Likes

(Oliver Stenzel) #11

According to the config posted by @stegemannk this should give you a working flood sensor:
{ zwave=“11:command=SENSOR_ALARM, alarm_type=5,respond_to_basic=TRUE” }
so i would change Contact test6 from your working config and try again.
Maybe if he’s reading this he can give further advice?

0 Likes

(Ben) #12

No luck with that config in my case.
I see a lot of movement in my logs, but the item/sitemap is not reacting…

The log when the floodsensor moves:

2016-09-30 19:41:04.900 [DEBUG] [ApplicationCommandMessageClass:40  ]- NODE 56: Application Command Request (ALIVE:DONE)
2016-09-30 19:41:04.900 [DEBUG] [ApplicationCommandMessageClass:58  ]- NODE 56: Incoming command class ALARM
2016-09-30 19:41:04.900 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:82  ]- NODE 56: Received Alarm Request
2016-09-30 19:41:04.900 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:94  ]- NODE 56: Alarm report - Value = 3
2016-09-30 19:41:04.900 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:113 ]- NODE 56: Alarm Type = General (0)
2016-09-30 19:41:04.901 [DEBUG] [.z.internal.ZWaveActiveBinding:466 ]- NODE 56: Got a value event from Z-Wave network, endpoint = 0, command class = ALARM, value = 3

The log when the floodsensor returns to normal state:

2016-09-30 19:41:28.959 [DEBUG] [ApplicationCommandMessageClass:40  ]- NODE 56: Application Command Request (ALIVE:DONE)
2016-09-30 19:41:28.959 [DEBUG] [ApplicationCommandMessageClass:58  ]- NODE 56: Incoming command class ALARM
2016-09-30 19:41:28.959 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:82  ]- NODE 56: Received Alarm Request
2016-09-30 19:41:28.959 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:94  ]- NODE 56: Alarm report - Value = 0
2016-09-30 19:41:28.959 [DEBUG] [z.i.p.c.ZWaveAlarmCommandClass:113 ]- NODE 56: Alarm Type = General (0)
2016-09-30 19:41:28.959 [DEBUG] [.z.internal.ZWaveActiveBinding:466 ]- NODE 56: Got a value event from Z-Wave network, endpoint = 0, command class = ALARM, value = 0
0 Likes

(Oliver Stenzel) #13

OK, so it says:
Alarm Type = General (0)
So i would change “alarm_type=5” to “alarm_type=0” and retry.
then your item should change to 3 if flooded and to 0 when dry again,if i interpret “Alarm report - Value = 3” and “Alarm report - Value = 0” correct.
And maybe try both with and without the respond_to_basic=true ??
Try and error to the rescue… :wink:

0 Likes

(Ben) #14

Same result… Going nuts,
Only without any command options, it’s reacting on my GUI (sitemap). But then, it’s all the same (tamper, flood…).

Is there way that we can compare the FGFS101 and FGFS101 v2_1? Maybe they did change it somewhere? :blush:

ps My battery is already at 62%, and the thing didn’t do anything, beside sitting here for a few weeks, and my triggering it. Hope that the battery will last last longer then that.

0 Likes

(Oliver Stenzel) #15

Sorry but that’s beyond my knowledge. Maybe @chris can help concerning possible changes in firmware versions of Fibaro FGFS101?

0 Likes

(Chris Jackson) #16

I’m not sure without checking, but the thing I would look at is the version of the ALARM/NOTIFICATION command class being used in these devices. Many devices are moving to the later NOTIFICATION version which isn’t well supported in OH1 so it might be that. If you can provide a debug log showing the different notifications I’ll take a look (don’t filter the log to only show lines with node 44 though as this removes the information I need to see).

0 Likes

(Ben) #17

Hey Chris,

The log file can be found on: www.oniria.be/tijdelijk/zwave.txt

I’ve tampered the sensor, triggerd a flood alert, and open/close the sensor.
The current NODE ID is 56.

ps i’ve used your logviewer tool. But honestly, I’m not sure what I’m looking for. I can see that there’s been a flood alarm, but that’s it. :blush:

0 Likes

(Chris Jackson) #18

It’s a little difficult to correlate exactly what’s happening as there are lots of events, however this is using the new NOTIFICATION alerts which aren’t processed fully in OH1. So, it is sending events for the flood and tamper - I’m not sure what the “open/close the sensor” does - I would have thought that was also the same as tamper (I see lots of “Tampering, Product cover removed” events throughout).

I’ve not looked through the manual, but I know on other Fibaro devices they have an option to configure the device to send the alerts as SENSOR_BINARY (I think) commands. I gather you’ve probably tried lots of things already though since you’ve been looking at this for a while…

I’m trying to avoid doing too much work on OH1 binding - my suggestion therefore is to use the OH2 binding if possible and I’d be more than happy to ensure this works there. The NOTIFICATION class has just been added there so I’m not 100% sure that every event works correctly (there are a LOT of events listed in the spec) but we we have examples I will make them work ;).

0 Likes

(Ben) #19

When you write ‘use the OH2 binding’, I suppose that this mean ‘start using the whole OH2 version’?

ps I love the stability of OH1 for the moment, and the other persons in my house even more.
So I would like to avoid migrating to OH2. But if it’s necessary, it’s necessary of course.

0 Likes

(Chris Jackson) #20

Yes… Although I suspect that OH2 is pretty stable - especially if you’re mostly using the OH1 bindings. Certainly I don’t have any real stability issues with the core system… I can understand your hesitation though - an unhappy family isn’t something anyone wants ;).

0 Likes

Migration OH1 -> OH2, especially z-wave related