Fibaro FGK-101 reports state change in debug but otherwise nothing

🛎️ Get Help
1

This one has me stumped. After some help from fellow Hubitater @njanda, I managed to pair my two Fibaro FGK-101 contact sensors. When I choose the inbuilt Fibaro Door/Window Sensor 2 driver, I can't for the life of me get it to show change of state but turning on debug logging shows:

dev:2062020-01-21 05:09:20.337 pm debugignore: BasicSet(value:255)

dev:2062020-01-21 05:09:17.974 pm debugignore: BasicSet(value:0)

dev:2062020-01-21 05:09:16.652 pm debugignore: BasicSet(value:255)

dev:2062020-01-21 05:09:14.667 pm debugignore: BasicSet(value:0)

dev:2062020-01-21 05:09:13.214 pm debugignore: BasicSet(value:255)

dev:2062020-01-21 05:09:12.978 pm debugignore: BasicSet(value:0)

So it recognises the change of state in debug but not under normal reporting. I tried the generic z-wave contact driver and nothing. But if I change it to something like the Fibaro water sensor, it reports the change of state but obviously shows wet/dry. Also works with the generic z-wave motion sensor driver but again, show active/inactive.

What gives? Anyone have any suggestions? I have two of the Fibaros and the same issue with both. I unpaired and re-paired one and still the same thing.

2

That built-in driver is meant for the FGWD-002.

There isn't a dedicated driver for the FGK-101 so the generic z-wave contact sensor driver should work, but I just noticed that you said it didn't...

There was an issue that could cause the behavior you're seeing, but I believe it was fixed in 2.1.8 so have you performed the latest hub update?

Update: Although that driver is meant for the latest model it apparently works with the 101, but the behavior you're seeing is an issue with the command class version which should have been fixed in in the latest hub update.

3

I have 10 of these and have been working fine for a year now with the Fibaro Door/Window Sensor 2 driver.

After you changed to this driver did you hit the "configure" button on the device page?

4

Yes, I'm on the latest hub firmware. Bizarre others haven't seen this behaviour.

1 Like
5

Wow, odd that mine are misbehaving if you have 10 working with that driver. I did hit configure but not sure it did anything as I got a log msg saying it'll be sent the next time the device is awake but it was definitely awake.

6

I have the same problem, I think it may be old firmware on the device.

2 Likes
7

Interesting. @njanda shares your view on it being old firmware. He too seems to have one behaving similarly. You guys could be right.

1 Like
8

First open a separate window with your logs running, then try excluding the device, then re-including. As soon as you get it paired change the driver to the Fibaro Door/Window Sensor 2 and hit configure. The battery and temp should auto populate on the device page within a few seconds. The tamper you will need to manually press the button on the back to populate it. The open/close you will need to bring it near the magnet to populate it.

Those last two won't happen automatically they require user interaction. You should be able to verify each of those actions happening by the logs.

1 Like
9

A agree that the problem is most likely caused by older firmware, but it could be a couple of other things too.

I was wrong about it being a command class version issue because I looked at my ST handler and the "door/window sensor 2" device doesn't support the BasicSet command at all. That's the same device that the Hubitat driver was written for so it makes sense that the logs are showing that those commands are being ignored.

The device the driver was written for uses the alarm/notification command class and if the device isn't sending them then that explains why the contact and tamper states aren't changing.

This probably doesn't apply to your situation because the devices sound similar, but I usually highly recommend against using a dedicated driver with a different device because dedicated drivers change configuration parameters.

If the parameter numbers overlap with your device's then your device can get really screwed up so the only way to safely use a dedicated driver with a different device is to first compare the parameters in the manuals to make sure that none of the overlapping parameter numbers have values that could break something.

You might want to try removing the device and factory resetting it just in case there's some parameter related to the reporting options that somehow got changed.

Before joining the device again make sure that the secure join option in the z-wave settings screen is NOT set to all devices. That probably doesn't matter, but the device the handler was written for has some association related parameters specific to when joined secure so another possibility for why it's working for some users is that yours is joined secure and there's isn't or visa-versa. (It's much more likely an older firmware issue, but you never know...)

2 Likes
10

If it helps any, I have 2 of these and I've had them for quite some time. I had them working perfectly on smartthings, then overnight they both stopped working(contact, temp) at the same time. When I got HE, I experienced much the same. I don't think there z wave plus so I'm not that bothered about them.

11

Thanks. I'll give it a try this weekend.

12

Really odd they just stopped working. I'll try the other suggestions and if no change, I'll bin them.

13

I followed your instruction exactly and sadly, no change to my situation. I get the following int the logs when I hit 'configure'.

dev:2892020-01-25 12:35:08.840 pm warn There are 9 pending changes that will be sent to the device the next time it wakes up. You can force the device to wake up immediately by keeping the cover of the device on and pressing the TMP button on the bottom of the device.

dev:2892020-01-25 12:35:08.750 pm warn configure...

dev:2892020-01-25 12:34:58.896 pm warn All the settings will be sent to the device the next time it wakes up.

dev:2892020-01-25 12:34:58.893 pm warn There are 9 pending changes that will be sent to the device the next time it wakes up. You can force the device to wake up immediately by keeping the cover of the device on and pressing the TMP button on the bottom of the device.

dev:2892020-01-25 12:34:58.794 pm warn configure...

dev:2892020-01-25 12:34:10.556 pm info fingerprint mfr:"010F", prod:"0700", deviceId:"3000", inClusters:"0x30,0x9C,0x85,0x72,0x70,0x86,0x80,0x84,0x7A", outClusters:"0x2B"

dev:2892020-01-25 12:34:10.531 pm debug building fingerprint for unknown Z-Wave device...

dev:2892020-01-25 12:34:08.479 pm debug configure() called...

14

I excluded the device, disabled secure join and no change. I think I'm retiring these little guys. I'm not seeing the light at the end of the tunnel. I need to learn when to cut my losses and stop sinking hours of my life where there is little hope of a return.

1 Like
15

Does this in anyway resemble your device page for that device?

fibaro
fibaro.PNG1341×196 11.8 KB

fibaro1
fibaro1.PNG1470×609 24.6 KB

16

Just bloody frustrating, right.
Issues like this just eat away at me.
Pull the batteries, Then chuck the sensors and batteries in a bottom draw and forget about them for a couple of months.
:grimacing::+1:t3:

1 Like
17

Nope. Looks like this:

2020-01-25%2014_40_44-Window
2020-01-25 14_40_44-Window.png1982×364 14.9 KB

18

I know you are about done messing with these but there is one other thing you can try (if you want to).

I never had to do this on Hubitat but I did on another platform in order to get these to report temperature (with the DS18b820 attached). Which would be exclude it back out. There is a little black button under the cover by the battery. Then select "include" on hubitat then use something like a paperclip/toothpick to hold that black button by the battery down while you are pressing the tmp button on the back of the device 3 times to send the device into inclusion mode.

Other than that I'm out of ideas.

19

Just tried what you suggested. I excluded it then included while holding down the little black button next to the battery. I then set up as Fibaro Door/Window Sensor 2 and hit configure. This time for the first time, the config seemed to take but alas, still not reporting state. It's still ignored. Log as follows. I think the fat lady has sung on this one. Thanks for persevering with your suggestions. I appreciate it.

dev:2902020-01-25 03:05:23.538 pm warnThere are 6 pending changes that will be sent to the device the next time it wakes up. You can force the device to wake up immediately by keeping the cover of the device on and pressing the TMP button on the bottom of the device.

dev:2902020-01-25 03:05:23.464 pm warnTemperature and Battery will be requested the next time the device wakes up.

dev:2902020-01-25 03:04:55.662 pm warnThere are 6 pending changes that will be sent to the device the next time it wakes up. You can force the device to wake up immediately by keeping the cover of the device on and pressing the TMP button on the bottom of the device.

dev:2902020-01-25 03:04:55.585 pm warndescription logging is: true

dev:2902020-01-25 03:04:55.582 pm warndebug logging is: false

dev:2902020-01-25 03:04:55.580 pm infoupdated...

dev:2902020-01-25 03:04:45.938 pm debugignore: BasicSet(value:255)

dev:2902020-01-25 03:04:42.144 pm debugignore: BasicSet(value:0)

dev:2902020-01-25 03:03:11.234 pm infoFibaro Sensor 2: battery is 94%

dev:2902020-01-25 03:03:11.231 pm debugBatteryReport(batteryLevel:94)

dev:2902020-01-25 03:03:04.617 pm warnThere are 6 pending changes that will be sent to the device the next time it wakes up. You can force the device to wake up immediately by keeping the cover of the device on and pressing the TMP button on the bottom of the device.

dev:2902020-01-25 03:03:00.566 pm debugOpen/Close LED Indicator (Param #2) = 6

dev:2902020-01-25 03:02:59.233 pm debugReport Closed when magnet is (Param #1) = 0

dev:2902020-01-25 03:02:57.467 pm debugWake Up Interval = 43200 Seconds

dev:2902020-01-25 03:02:56.494 pm debugRequesting Battery Report

dev:2902020-01-25 03:02:56.422 pm debugRequesting Temperature Report

dev:2902020-01-25 03:02:56.221 pm debugChanging Temperature Offset (Param #53) to "0" (None)

dev:2902020-01-25 03:02:56.213 pm debugChanging Temperature Reporting Threshold (Param #51) to "10" (1.0°C / 1.8°F)

dev:2902020-01-25 03:02:56.208 pm debugChanging Temperature Reporting Interval (Param #52) to "0" (Disabled)

dev:2902020-01-25 03:02:56.202 pm debugChanging Temperature Measurement Interval (Param #50) to "300" (5 Minutes)

dev:2902020-01-25 03:02:56.192 pm debugChanging Tamper Alarm Cancellation Delay (Param #30) to "5" (5 Seconds)

dev:2902020-01-25 03:02:56.187 pm debugChanging Tamper Alarm Cancellation? (Param #31) to "1" (Enabled)

dev:2902020-01-25 03:02:56.182 pm debugChanging Open/Close LED Indicator (Param #2) to "6" (Wake Up / Tampering)

dev:2902020-01-25 03:02:56.118 pm debugChanging Report Closed when magnet is (Param #1) to "0" (Closed)

dev:2902020-01-25 03:02:55.953 pm debugChanging Wake Up Interval to 43200 Seconds

dev:2902020-01-25 03:02:55.947 pm debugsyncDevice()...

dev:2902020-01-25 03:02:49.887 pm warnAll the settings will be sent to the device the next time it wakes up.

dev:2902020-01-25 03:02:49.884 pm warnThere are 9 pending changes that will be sent to the device the next time it wakes up. You can force the device to wake up immediately by keeping the cover of the device on and pressing the TMP button on the bottom of the device.

dev:2902020-01-25 03:02:49.792 pm warnconfigure...

dev:2902020-01-25 03:02:46.461 pm warnThere are 9 pending changes that will be sent to the device the next time it wakes up. You can force the device to wake up immediately by keeping the cover of the device on and pressing the TMP button on the bottom of the device.

dev:2902020-01-25 03:02:46.340 pm warndescription logging is: true

dev:2902020-01-25 03:02:46.337 pm warndebug logging is: true

dev:2902020-01-25 03:02:46.334 pm infoupdated...

dev:2902020-01-25 03:02:13.057 pm infofingerprint mfr:"010F", prod:"0700", deviceId:"3000", inClusters:"0x30,0x9C,0x60,0x85,0x72,0x70,0x86,0x80,0x84,0x7A", outClusters:"0x2B"

dev:2902020-01-25 03:02:13.047 pm debugbuilding fingerprint for unknown Z-Wave device...

dev:2902020-01-25 03:02:10.997 pm debugconfigure() called...

20

Wise words, my friend. TOC. :laughing: