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

Any chance you can also shiw me how?

Thank you 


strange
 i can’t seem to find the line you mentioned
 i’ve looked on the RAW code as well as on the Device Handler code as well
 any trick/s i should use to find the line?

ive been using CTRL+F to search for the line and i do not get any hits for the search

thanks


@macombweare : very curious.
As you can see on my own “Things” screen copy below, all my FGK-101 (old ones as well as the newer JJ’s ZW5 one) display properly the temperature, as I required.
The only one displaying such “–” is a different Fibaro FGMS sensor, unrelated to the FGK-101 custom handler.

And I also checked within my handler’s code, there is NO such line as
attributeState("open", label:'--',

Did you add your own customization on top of the handler I posted on github ?

Please make sure you use my latest v0.9.6.3, 16 April 2017 version of the FGK-101 ZW5 handler.

Note that this version should also work with pre-ZW5 versions of the FGK-101 hardware.
Beware that TWO consecutive wakeups (using the bottom Tamper switch), separated by 5 seconds, are needed for the Handler to dynamically recognize to which hardware version it is connected.

1 Like

Yes, this is the default FGK-101 ZW5 handler, made by Fibaro, not mine.
It is simpler but had too many limitations for me : wake-up time, temperature accuracy, etc


1 Like

no i did not
.[quote=“geeji, post:170, topic:5483”]
Please make sure you use my latest v0.9.6.3, 16 April 2017 version of the FGK-101 ZW5 handler.
[/quote]

i made it sure i have the correct handler by going to your provided link. but still get “–” as Status for my sensor.

took a i screenshot of my sensor as well just to make sure im working on the correct sensor.

You are NOT using my Custom Handler, it is just not possible to get the kind of screen output you get with any code present in mine.
And I confirm you DO have the Z-wave+ version of the FGK-101, aka ZW5, with FGK-101 firmware >=3.2 (applicationVersion.applicationSubVersion).

im assuming this is for me? i just double checked. grabbed the code from the recent link you gave me and installed it.

this is what it shows up on my device list

that is how it should show up as right?

@macombweare : curiouser and curiouser

You do have my custom handler, I apologize for doubting, and if you did not modify its code, I do not understand at all the “–” display : no code in my handler would explain that.
Could you please :

  1. On your computer/IDE :
  • activate Live Logging for your Location
  1. On your mobile phone :
  • go to the “Right Now” page for your “Front door” device
  • take a screen copy of it
  • go to the “Recently” page for same
  • activate a close/open/close (or open/close/open) transition
  • wait a few seconds
  • take a screen copy of it
  1. On your computer/IDE :
  • post a copy of your Live Logging for “Front door”

I have discovered so many odd things in the SmartThings environment, I suppose this one will be have to be added to the (long) list


What the heck!

All of did was open and close the door!

Im thinkIng im good now?

I shouldn’t be getting temp readings because that needs an add-on chip((?)

Thanks

i did
 but i had problems using it too
 it was erratic and slow to indicate close or open status and at times would be stuck at open when the door is closed


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.