I’m comfortable to go with the DS modules readings and have dialed down the heat source pump. I’m going to add another DS to act as a general temp monitor for the deck area and see how that goes.
What zwave device do you all recommend since the Fibaro FGK10X is not longer being manufactured?
I saw someone else say the Fibaro RGBW would work, but it didnt look like it was battery powered.
Any suggestions?
You can still buy them; I just got one for my pool.
It’s in CDN dollars so bonus for US customers.
https://www.aartech.ca/search?sortBy=part_number_asc&limit=24&termsFilters[manufacturer][Fibaro]=1&controls[1]=fibaro
I had ordered three more of these FGK-10x for my pool project from Aartech: https://www.aartech.ca/fibaro-fgk-107.html a few days back (June 27th).
and these Gikfun DS18B20 sensors from Amazon: https://www.amazon.com/Gikfun-DS18B20-Temperature-Waterproof-EK1083x3/dp/B012C597T0
I spent at least three hours installing, resetting, rejoining, excluding and getting frustrated. I packed them up for return but read through this thread again and figured I’d give them one more go tonight.
The FGK-10x sensors that Aartech have still in stock are older as they are colours that didn’t sell well. So these three had older firmware: zw:S type:2001 mfr:010F prod:0700 model:2000 ver:2.05 zwv:3.67 lib:03
What worked was to install the DS18B20, and include the FGK-10x to the V2 hub. As others have mentioned the door sensor cover must be installed before you can join. Then I changed the device driver to JJ’s Fibaro FGK-10x ZW5 Handler (v0.9.7.4, 29 November 2018), pulled the battery for a few seconds, then reinstalled, placed the FGK cover back on. Finally, I clicked the tamper button on the base of the unit three times rapidly, and kept doing this 3-4 times until the temp suddenly showed up viewing the device via the SmartThings iOS app. Success…finally!
Thanks all for the information in this thread, and particularly JJ for the driver!
My pool automation project is working great BTW…just adding these for more accuracy.
@denwood : Glad it finally worked for you !
Sadly, you will probably be one of the last to enjoy my driver, since the latest Fibaro sensors removed the nice capability of using a remote DS18B20. But I suppose, when they introduced the first FGK-10x, they did not expect any people to use them as pool temperature remote sensors 
Congratulations for your swimming pool set-up. I inherited my own swimming pool when I bought the house, but I got so many problems with it afterwards that I almost wished I had to build it up from scratch 
.
Here in the south of France, the air temperature reached 113°F, and the “hot” water at “only” 88°F was quite refreshing 
1 Like
Agreed, however perhaps the more cost effective approach if you don’t mind powering from a wall wart is the Fibaro Universal Binary sensor (supports 4 temp sensors):
Or using the Qubino: https://www.thesmartesthouse.com/collections/qubino/products/qubino-z-wave-plus-on-off-thermostat-module-zmnhid3
Both of those would require a case and external power…but have the benefit of serving as zWave repeaters. That’s not a bad idea really as the pool sensors likely need a repeater anyway.
Our climate is not so different from yours in summer. You can view my “live” pool data here compliments of another SmartThings app developer
I had a lot of frustration as well getting the temp to work but it was related to the myriad of incomplete instructions and driver options. I finally found a sheet that touted the temp doesn’t work unless you pre-wire it (temp probe) and then reset the device. That info was not on the sheet that came with the package or another online pdf I found.
I ordered a 3-pack of probes so maybe I will have to grab 2 more FGK’s before they disappear into obscurity.
Even if you pre-wire a brand new sensor, it will behave differently depending on firmware. With the latest 3 FGK-10x sensors I received, the firmware was older than the first one I bought last year:
older firmware: zw:S type:2001 mfr:010F prod:0700 model:2000 ver:2.05 zwv:3.67 lib:03
I had to use JJ’s FGK-101 Handler for these older firmware sensors: https://github.com/geejii/JJG2014/blob/master/JJ’s%20Fibaro%20FGK-101%20Handler
What finally worked: Pre-wire temp probe, replace FGK cover, join to the hub, replace driver with JJ’s FGK 101 hander in the ST IDE, then triple click the base tamper button -> wait 10 seconds -> triple click -> wait ten seconds -> triple click etc. Once I had done the triple click sequence for about a minute, temperature final showed up.
and for the “newer” firmware sensor: zw:Ss type:0701 mfr:010F prod:0701 model:2001 ver:3.02 zwv:4.05 lib:03
I am able to use JJ’s ZW5, or the SmartThings “Fibaro Door/Window with Temperature” device driver
JJ’s ZW5 Handler: https://github.com/geejii/JJ-s-ZW5/blob/master/JJ’s%20Fibaro%20FGK-10x%20ZW5%20Handler
So the most recent 3 FGK-10x with older firmware were definitely a pain in the butt to get working with the DS18B20 external temperature probes.
I was searching this thread for how to code in small temp adjustments as I have four of the DS18B20 and four FGK-10x sensors.
The three sensors in question are pre 2.5 firmware ( ver:2.05), and the process is different for the newer > 2.5 (which has parameter 53 to play with). I found that JJ has already incorporated some code from posts a year back or so:
Find line 342 of the FGK-101 device handler: https://github.com/geejii/JJG2014/blob/master/JJ’s%20Fibaro%20FGK-101%20Handler
Modify as many lines there as you have sensors to calibrate…I had to change my device names as they were all set the same. Device names are case sensitive. My three new sensors are called:
Z-Wave Door/Window Sensor
Z-Wave Door/Window Sensor 2
Z-Wave Door/Window Sensor 3
At line 342:
// Adjust measured temperature based on previous manual calibration; FGK-101 is natively °C
switch (device.name) {
case 'Z-Wave Door/Window Sensor' : //JJG
scaledSensorValue = scaledSensorValue + 0.8333
log.debug "Temp Adjust for : ${device.name}"
break;
case 'Z-Wave Door/Window Sensor 2' : //MLE
scaledSensorValue = scaledSensorValue + 0.7778
log.debug "Temp Adjust for : ${device.name}"
break;
case 'Z-Wave Door/Window Sensor 3' : //MPT
scaledSensorValue = scaledSensorValue - 0.5000
log.debug "Temp Adjust for : ${device.name}"
break;
Save and Publish for you. You can wake up the sensors via a base tamper button triple click to see the adjusted values.
Hope that helps anyone looking to calibrate pre 2.5 firmware FGK-10x sensors. Those adjustment values are in C, so you may need to do some calculations to get where you want.
I apologize for leaving “dead code” in the Custom Handler I published : it was easier for me to publish the exact same code I am using myself.
Let me clarify why I included this “calibration sequence” in the handler : by itself, the DS18B20 is supposed to be ±0.5°C accurate from –10°C to +85°C.
±0.5°C (i.e. ±0.9°F) is quite accurate enough for most usages. Note that a ±0.5°C difference is undetectable by most humans, although ±1°C is.
But I suppose 5 years ago I went somewhat overboard, since the application I was aiming at (parallel temperature sampling in a dozen of flats within the same community) could only be improved with better accuracy. Also I was somewhat worried (I bought a few faulty ones on eBay) that some DS18B20 you can buy for cheap on the web may be subpar, with erroneous readings.
Since a reference thermometer would cost a bunch, I did not aim at better absolute accuracy, only at better RELATIVE accuracy : I connected a dozen FGK-10x (w/ DS18B20) in parallel, set them at the exact same physical location, and forced simultaneous temperature reports (pushing the tamper switch at the back of each of them) every 3-4 hours over a day or so.
I entered all the measurements into an Excel spreadsheet, and computed :
- for each measurement time, the average of the dozen reports (considered as the “true value”)
- for any given FGK/10x, its set of individual temperature variations, obtained by subtracting from its own temperature report the averaged “true” value at the same time.
Thus a pair of sensors reporting 20.5°C and 19.5°C at the same time and the same place would have variations (at that time) of +0.5°C and -0.5°C, with an averaged “true” value of 20°C.
Then I would average all variations over the 24 hours of measurements, and consider the average values for each sensor as “corrections”.
Honestly, this is a lot of work for very little benefit, especially since the nominal ±0.5°C accuracy is good enough for 99% of applications.
The real benefit was to throw away some dubious “out of accuracy range” DS18B20, which I believe happened 3 times over 20 DS18B20 I bought (which is way too much, unless out-of-specs DS18B20 are bought on eBay or elsewhere).
Bottom line : don’t bother with it unless you have multiple FGK/10x + DS18B20 and are in doubt about some possible faulty DS18B20 bought for multiple sources. And preferably buy your DS18B20 from some reputed first line reseller, like Digikey.
1 Like
I’m glad you left the code in
I have the four sensors which were reading a bit eratic. The data from one of the sensors (from last year) jumps around 2F or so, but the new ones on our 101 handler seem more consistent. Regardless, I have four bundled together in the pool water (which changes temp very slowly) so I can match them up for relative consistency.
Right now I’m using two pumps in series, and a total of 5 amps to run the filter/solar system together as system head is about 20ft. My end goal is to measure the temp delta between solar supply and return and regulate flow (will require a variable speed pump) to keep the delta temp around 4F. I have a few dry wells for the DS18B20 sensors that I will install into the 1 1/2" PVC pipes to do this more accurately. In the long run (aside from being a fun science project) we should be able to cut power use a fair bit.
Is the temp offset adjust the same for the ZW5 version code or do I need to program that somewhere for pararmeter 53?
Gee, I see now that the older firmware FGK-10x (pre 2.5) actually reports temps more consistently. I didn’t realise that the newer ZW5 had the reporting “bug” that you had reported where temps bounce around a bit. Go figure.
You might get a kick out of this. I wanted to sort a solar charged wireless “data” station which will soon incorporate DS18B20 sensors mounted into drywells mounted directly into the return/supply solar pipes. I’m using 3 low discharge NiMH cells charged with a small solar cell. They deliver 4 volts or so, which the sensors seem fine with. It’s mounted with few bits of composite deck and an adjustable mount for the solar cell.
The three fibaro FGK-10x sensors and 3 AA cells are shielded from water using a standard outdoor electrical box. The lithium cells in the sensor are removed, and + - leads soldered to the battery connectors inside each FGK-10x.
Temporary mount until the drywell bits arrive:
We’re hitting 82-84C in the mostly shaded pool with six collectors on the roof.
Regarding your older sensor with slightly different measurements from the last ones, I very much doubt it is a firmware issue, much more like an out-of-specs DS18B20.
Easy to test, since you do not need to re-pair the sensor when you change the DS18B20 (take the LS14250 battery out before).
Regarding the FGK-10x temperature reports discrepancies : I suspect the ZW5 firmware initializes the DS18B20 with a lower precision setting, like 9 bits instead of 12 (the default at power on, and with pre-ZW5 firmware); this makes the DS18B20 respond faster, but you loose precision : ±0.5°C, 0.25°C, 0.125°C, and 0.0625°C with 9, 10, 11, or 12 bits respectively.
I have only indirect proof of that, and I found no ZW5 parameter to correct it (parameter #51 is only supposed to set the temperature difference generating a new temperature report).
Sad that a newer version actually degrades the performance of the sensor, but unfortunately not unheard of…
Regarding your solar power supply, I would suggest you protect your FGK-10x from overvoltage with a zener diode : when charging, 3x NiMh batteries can rise up to 4.5V, which is MUCH higher than the original 3.6V original LS14250 battery.
Regarding the temperature offset correction, if is at the same place for the ZW5 and pre-ZW5 versions of my Custom Handler.
Note that the ZW5 version of my handler is supposed to be ALSO backward compatible with pre-ZW5 FGK-10x sensors (although I did not do extensive testing of that).
Have fun with your nice pool projects (and still enjoy the pool 
)
1 Like
Hey man, been a long time since I reached out on this handler but I wanted to let you know that while it was working well before, it stopped about a year ago and I just figured it wasn’t going to get better due to Smartthings changes.
Last night I updated my device handler using your latest Nov 18 at Github and everything works perfectly. So no complaints just sincere thanks for you doing all this for free. It’s really appreciated.
Now if someone could figure out how to get a hold of fully charged 1/2AA batteries, that would be great.
Thanks man,
Woo (Fred)
@Woo : Hi Fred, long time no see. It is thanks to people like you who do appreciate the work involved in maintaining such a handler, that I have been enough motivated to keep it operational up to now.
Unfortunately, as you mentioned, SmartThings seem to have some difficulties compiling “upward compatible” in Groovy; but Fibaro is even worse, and this handler will soon die just because no Fibaro hardware will continue the FGK-x01 lineage.
Note that had I anticipated the ZW5 version of the FGK-x01 would require a complete rewrite of the handler, I would probably have let it die peacefully…
Not sure I understand your question about “a hold of fully charged 1/2AA batteries” unless it was a joke : has eBay stopped working during the night without me noticing ?
Half joke, have frustrated venting to the universe. It seems I can’t get 1/2AA batteries with any sort of quality. But as long as this thing still works, I’ll keep picking them up.
If Fibaro ends this product line, are there any other options out there that would be a good replacement?
Fred
I have always been happy with SAFT LS14250, plenty to buy by 1 or 10 on eBay, mostly from Europe but also from Canada.
Beware from “SAFT-like” products from Chinese sellers, although they are likely all made in China.
Up to now, I had not realized LS14250 was more a european format than a US one, but considering Fibaro is from Poland there is some logic there.
Depends if you need a remote DS18B20 or not. The current Fibaro FGDW-002 sensor is mostly a FGK-x01 with a built-in temperature sensor. There are less than 5% chances that my Handler would work with this one without (major ?) adaptations.
If you need the remote DS18B20, for a swimming pool for instance, you can use the Fibaro FGBS-222 (which replaces the previous FGBS-001) but I have no idea about its native SmartThings support level.
Interesting choices. I’ll have to start checking them out. Thanks.
Hi. I’ve been onboard with this discussion for years now. I had this sensor working for quite some time, then all of a sudden things stopped working. After my usual crazy hand-wavy method of trying this, trying that, and after a new device handler, removing and adding it a couple hundred times, it does seem to kinda-sorta work again. I can triple-click this thing and see events and what seems to be a correct temperature reading.
What i see now is the LED blinking like crazy. All the time. I would say it’s fading in and out about once every 1/2 second, or twice a second. I don’t remember this happening before. I am guessing this will be draining the battery.
Anyone got any ideas as to why this is happening? The manual/instructions on the site don’t really clue me in with what the blinking codes mean.
This is definitely abnormal.
May be after changing the battery multiple times you now have a faulty oxidized contact, either for the battery or for the anti-tampering switch at the bottom.
I would try some contact cleaner like this one, but if it does not work, it is likely a hardware defect of the FGK-x01, unless you have around you a new device which pollutes the Z-wave network.
For once, I would bet on the SmartThings cloud and the Device Handler being innocent with 99% probability.