@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
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.
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
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
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 :
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.
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.
Yes, you are correct, my bad for not being clearer. The comment was about the standard pairing prior to the manual activation of your excellent device handler.
Well, I finally found a workaround for forcing a periodic Temperature Report every 4 hours, even with constant temperature. Handler v0.9.7.1 corrects this problem.
For the curious ones : it appears that you must divide Parameter #52 target value by 1.92 to get the correct behavior. So instead of 14400 seconds (=4h) as I originally programmed, I set it up to 7510 instead… and it now works !
Don’t ask me why…
AFAIK, that was the last ZW5-related bug.
If you find some other odd behavior, please let me know.
Great news on the update bug. I’ve never updated a handler before. Presume I just cut and past it in, save and then publish to myself. I am not getting a value of 1 for configured after 10 minutes, is there a step I missed?
Thanks and I apologize for the noobie question!
Edit: Never mind, it eventually refreshed and updated the configured value to 1.
@bturcotte : Well, sadly, the outside pool is definitely too cold for me…
Note that the latest ZW5 version of the FGK-10x could be programmed to generate a “High Temperature Alert” whenever your Hot Tub temperature goes above some value (parameters #54 & #55) : that could avoid you being overcooked like a lobster if your water heater goes wrong…
