'Fibaro Z-Wave FGK-101 Temperature & Door/Window Sensor' Full Support Handler

Ah well…
The problem is that if your mesh network, for whatever reason, misses an “open” (or “closed”) event, then from the Dashboard point of view the sensor will stay “closed” (or “open”) as it was before.
Basically, the Z-wave protocol is of the “fire and forget” philosophy, which makes it a very bad candidate for any “mission critical” tasks, like alarms.

I suppose the custom handler could be modified to explicitly check the current status of the sensor (using BasicGet->BasicReport) every xx minutes, but unless you do that every minute it would be mostly obsolete information, and anyway it would drain the battery way too fast.

[deleted] suggestion of Zwave repair is a good one, in case your lost events come mostly from the local mesh network; but open/closed events could as easily be lost on the Internet between the Hub and the SmartThings cloud, or within the SmartThings cloud itself, and there is no way you could be 100% sure this has not happened at some point.
While writing this post, I completely lost access to SmartThings documentation servers (my Internet was working for other domains), but it could as easily have been a lost access to a Hub or to the SmartThings cloud.

Bottom line : if the functionality you want to build using SmartThings requires a 99% reliability, just forget it.

1 Like

Something very curious is happening with the ZW5 version of the FGK-101 enhanced with the optional DS18B20 thermometer chip.
This chip has a maximum hardware resolution of 12 bits, corresponding to a 0.0625°C granularity.
But this resolution is actually programmable to 9, 10, 11 or 12 bits, giving respectively 0.5, 0.25, 0.125, 0.0625°C increments.
That means that at the maximum 12 bits resolution, the first decimal figure of the °C measurement IS significant : 23.8°C and 23.9°C ARE different.

When using the pre-ZW5 version of the FGK-101, this is exactly what I get, with continuous measures which can be for instance 23.7, 23.8, 23.9 or 24.0°C.
But since I started testing WITH THE SAME HANDLER the ZW5 version of the FGK-101 + DS18B20, I do NOT get continuous temperature readings, but instead DISCONTINUOUS ONES : for instance 22.4, 22.8, 23.1, 23.4, 23.8°C, but NEVER values in between, such as 23.5, 23.6, 23.7°C for instance.
It is completely unlikely that the continuous temperature evolution within a room would change by such quanta that it always miraculously avoids those intermediate values !
On the other hand, that would be only too consistent with a limited 10 bits resolution instead of the previous 12 bits resolution.

Unfortunately, if it is so, there is nothing I can do at the FGK-101 Handler side, since this 10 or 12 bits resolution is set by the internal FGK-101 hardware/firmware.
This would be a VERY bad regression, since one of the utmost reason to use the FGK101+DS18B20 for temperature measurement was the high (relative) accuracy (0.0625°C at 12 bits), although the ABSOLUTE accuracy was not guaranteed better that 0.5°C.
But when you measure continuously temperatures, you need the maximum RELATIVE accuracy.

So my question is : if any of you currently uses my new ZW5 Handler with a new ZW5 FGK-101+ DS18B20, do you see the same discontinuity ?
Note that in °F, the displayed gaps would only be larger.

I am continuing my tests and will try to get some information from the Fibaro own forums, but if it is confirmed that the new ZW5 FGK-101 has only a 10 bits resolution instead of 12 as before, there is nothing I can do at the Handler’s level, and that would be a VERY bad regression :frowning:

I was thinking of buying a couple of these sensors and hooking up microswitches that contact with the door bolt so I can see if door is shut and locked. Would this handler support this?

So can you only use the reed sensor OR the onboard switch? Does this mean I would need 2 of these to accomplish the task I described?

Well, yes and no.
You can use both the reed sensor and a TEMPORARY switch, but you will get only 1 signal (Open/Close), and since both reed sensor and switch are in parallel, the state corresponding to those two will be the OR boolean value of those two states.
Meaning that if you want to report on open+unlocked, you can, but you will be unable to separate the other 3 states [open+locked, closed+unlocked, closed+locked].
On the other hand, you could use ONLY the switch input, with 2 switches AND-connected serially for open/close and locked/unlocked : closed+locked would be detected, but closed+unlocked would be undistinguishable from open+unlocked (and open+locked).

	           OR  AND
Open+Unlocked	0	0
Open+Locked 	1	0
Closed+Unlocked	1	0
Closed+Locked	1	1

Bottom line : if you really want 2 completely independent state detections, yes you will have to use 2 FGK-101.

LIVE NEWS : the SmartThings platform/cloud is broken since 4 days ago, see : the Recent Platform Update Broke Parse Method Response/Result thread.

This bug had been making me crazy since the last 4 days, when none of my Handler modifications worked, whatever I did.
Sadly, at that time, SmartThings has not even aknowledged the problem, and the SmartThings Status is, erroneously, “all green”.

So stop any test with any Handler / Device until that one is solved.
This may also explain any behavioral oddity you may discover with other Devices, since basically it broke all/most STANDARD handlers for all/most Devices :rage:

UPDATE : the Parse Method Response/Result bug has been solved.

It took 4 days, during which the SmartThings Status never acknowledged this major problem.
Although the SmartThings platform stability has greatly improved those last 6 months, there is obviously still a long way to go…

1 Like

Interesting… Thanks for the updates :slight_smile:

FYI there were a few changes made to those ZW5 handlers on the SmartThingsPublic repository in the past couple of months, such as Health Check added.

@dzhimc: thanks for the information, unfortunately Health Check works only with a v2 Hub (I have v1).
Actually, I developed a “watchdog” SmartApp 2 years ago, for the same purpose SmartThings developed Health Check; may be they got the idea from me and a few others :wink:

Some progress information : my latest version of the FGK-101 Handler works pretty well, except that I am stuck with a last bug I cannot eradicate. It is nasty enough that it generates random spikes about 1°C in excess of or below the correct temperatures, so it makes all reported measurements “noisy”.
This happens only with the latest Z-wave+ / ZW5 version of the FGK-101.

I posted on github my latest (final) version of my custom handler, compatible with both pre-ZW5 and ZW5 versions of the Fibaro FGK-10x Temperature & Door/Window Sensor.

This handler works with both pre-ZW5 older versions of FGK-10x hardware and newer ZW5 ones.
Wait about 1 minute AFTER manual or automatic Device wake-up for the handler to self-configure, based on applicationVersion.applicationSubVersion value : if >=3.2, then it is a ZW5 version of the FGK-10x hardware.
IMPORTANT : for pre-ZW5 FGK-10x (with applicationVersion.applicationSubVersion <= 2.5), you will need to wake-up TWICE the Device, using the Tamper switch, keeping those 2 wake-ups about 30s apart.

AFAIK, the behavior is 99% identical for both hardware versions, except for a persistent bug which I could not eradicate, described there.
I spent a ridiculous amount of time trying to correct or workaround this irritating bug, but at this moment I suspect it is either a firmware bug within the FGK-10x ZW5 hardware, or a parse bug within the SmartThings cloud.
If anybody has a solution, I would be more than glad to incorporate it within my handler :smile:
Note that the impact should be minor, except with possibly less frequent Temperature Reports on ZW5 hardware.

Let me know if you find any bug or bizarre behavior, especially if you have a v2 Hub (mine is v1).

I have a v2 hub. Right now I’m just trying to get a temperature value. Temperature probe was added prior to pairing. If everything is working properly should the Current States field on web graph.api have a temperature field?

I would love to find out how to validate that the switch physically recognizes that the temp ds18b20

This is what is showing up for me…

battery: 100 %
contact: closed
tamper: active
reportASAP: 1
forcedWakeUp: 1
ZW5set: 1
ZW5: 1
Configured: 1


Well, it looks like your ZW5 FGK-101 did not recognize the DS18B20.
Below is what I get on mine :

At that point I would recommend that you :

  • unpair your Device
  • reset it at factory defaults (see FGK-101 notice)
  • remove the FGK-101 battery
  • check/correct the proper connection of the DS18B20
  • insert again the battery
  • pair again your Device
  • activate my “JJ’s Fibaro FGK-10x ZW5 Handler”
  • wake up your FGK-101 up and wait about 60s

By then, you SHOULD see the “• temperature : xx.xx C” line above your “• battery:” line

And BTW I can confirm my custom handler did recognize your FGK-101 as a ZW5 one : “• ZW5: 1”

Thanks for the quick response! Still no go. I’ve tried 4 sensors so far. Un-pair from hub, remove battery, attach new probe (red=power, blue=data, black=ground) verified that connected to correct pins. At this point I’m concluding that I either have a partially bad Fibaro switch or bad probes. Ordered new of each from different source than originals now working with. This for a freezer alarm so willing to spend a few extra $$$ to get this working.

I am sorry it did not work. From your post I deduce you did not buy a “raw” DS18B20 chip, but a “packaged” one (I have seen some such sold at aliexpress.com).

At that point, here are the only things I can suggest :

  1. get a RAW DS18B20 TO92 chip from a reputable source (beware from ebay.com, although they did work for me); triple check the way you connect this DS18B20, using the pictures in the FGK-10x Operating Manual : it is only too easy to reverse the connections, or have a bad connection for one of the 3 wires;

if it does not work, then :
2) switch the FGK-10x handler to the Fibaro-made “Fibaro Door/Window Sensor ZW5 with Temperature” handler : if that “standard” handler does not work either, with a “raw” DS18B20 chip, you will then be able to submit a ticket with SmartThings support (they reject any Support Request related to custom handlers).

I suppose this could also be a subtle incompatibility between my custom handler and a v2 Hub, but at that point I would rate this probability to 1% or less.

Let me know if I can do any more to help you.

Is it possible to have in the ‘my home’ menu open/closed like the samsung sensors instead of the temperature?

Well, I suppose you could “mix and match” the metadata {tiles {…}…} part of the Samsung driver you like with this driver : lines 119-183.

Sweet, i changed it and it works TNX!!

Good news, it was the temperature probes. Using your device handler I now have 2 functioning units properly registering temperature. Bought the probes from a different vendor.

For reference to those that follow, if the temperature probe is connected correctly SmartThings will recognize the unit as a “Fibaro Door/Window Sensor ZW5 with Temperature” when paired to the SmartThings hub

Easiest to install the sensor before activating the unit for the first time (pulling the cardboard battery tab) otherwise, you can do a firmware reset by following these instructions.

Congratulations Ben !
I suppose it is implicit in your reply, but the “Fibaro Door/Window Sensor ZW5 with Temperature” handler which is automatically activated by SmartThings after pairing is the “standard”, Fibaro-written one, which is buggy and less precise.
To activate mine, named “JJ’s Fibaro FGK-10x ZW5 Handler” and located on github here, you need to do it manually from the IDE, AFTER this first initial pairing.

Enjoy :smile: