Floodsensor water vs tamper

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.

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?

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 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)

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:

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:

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?

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

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:

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.

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

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).

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:

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 ;).

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.

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 ;).

OK, maybe it’s time to start using OH2 instead of searching for solutions, or adding more ‘complexity’ into the current one.

Kick off: Mirgration OH1 to OH2 :wink:


sorry for beeing late in this issue but I was away from home. My flood sensor is about a year old (no idea which version and did not find it on the device) and doing it’s job as expected. This is my working conf copied from my item file:

Number nuFibFlood_Battery "Water-Sensor: Battery [%s %%]" { zwave="11:command=BATTERY" }
Number nuFibFlood_Temp "Water-Sensor: Temperatur [%.1f °C]" { zwave="11:2:command=SENSOR_MULTILEVEL,sensor_type=1" }
Switch swFibFlood_Tamper "Water-Sensor: Tamper Alarm  [%s]" { zwave="11:command=SENSOR_ALARM, alarm_type=0,respond_to_basic=TRUE" }
Contact coFibFlood_Alarm "Water-Sensor: [MAP(water.map):%s]" { zwave="11:command=SENSOR_ALARM, alarm_type=5,respond_to_basic=TRUE" }

Pretty sure I didn’t changed anything in the z-wave configuration of this device. The response in case of water is instantly and the battery level is 74% now. I created a rule triggering a push notification and a terrible mp3 file.
And I’m still on OH 1.82, too many different devices and less time for a big change. Fighting with enocean in the moment.

Good luck - Klaus

No problem!

I’ve tried this, but no luck. I guess the problem is the little thingy that Chris said. With v2, they changed a bit the way the floodsensor works.

For the moment, I’m migrating to OH2.
Hope that I can give (positive) feedback regarding this sensor by the end of the week…

If you have problems with OH2, please send a log and we’ll sort it out for sure.

You can have a look to the new manual for FGFS-101 Version2 at:
FGFS-101 V2
I read that the floodalarm is BASIC-SET ON/OFF in the association-group 2 - so it may by correct that the above test:

Contact Test6 “Test Clean [%s]” { zwave=“44” }
works right.

With OH2, this device is working as expected. Over here, I’m having following items:

Number  Badkamer_Water_Temperatuur      "Badkamer [%.1f C]"             <temperature>   (ALL_tem,WO_tem)        { channel="zwave:device:1578e7a83ee:node59:sensor_temperature" }
Contact Badkamer_Water1                 "Badkamer Water Optillen [%s]"  <water>         (ALL_water)             { channel="zwave:device:1578e7a83ee:node59:alarm_burglar" }
Contact Badkamer_Water2                 "Badkamer Water [%s]"           <water>         (ALL_water)             { channel="zwave:device:1578e7a83ee:node59:alarm_flood" }
Number  Badkamer_Water_Batterij         "Badkamer [%s %%]"              <socket>        (ALL_bat,WO_bat)        { channel="zwave:device:1578e7a83ee:node59:battery-level" }
Contact Badkamer_Water_Algemeen         "Badkamer Water Algemeen [%s]"  <water>         (ALL_water)             { channel="zwave:device:1578e7a83ee:node59:sensor_binary" }
Contact Badkamer_Water_Alarm            "Badkamer Water Alarm [%s]"     <water>         (ALL_water)             { channel="zwave:device:1578e7a83ee:node59:alarm_general" }

Not clear to me why I would use the ‘sensor_binary’ or ‘alarm_general’. But for the moment, my biggest intrest is the flood_alarm. And it’s working nicely over there.