Noting my device is reporting temps that are off by several degrees when checked against other temp sensors. Not seeing how to adjust the temp in JJs handler. Anyone know how I can adjust the offset to compensate or maybe even calibrate the device? I how the DS temp probe and its working as it should. Thanks.
Hi Brad, a few questions :
- is your FGK-10x ZW5 or pre-ZW5 ?
- what version of my Handler do you use ?
- are the temperature reports arriving as soon as a temperature difference >= ±0.3°C (±0.5°F) is detected (since last report to Hub), or are all/most temperature reports arriving periodically (multiples of 1 hour) ?
- what Hub (v1, v2 or v3) do you have and what version do you run ?
If your FGK-10x is ZW5, then you may be victim of some bug I detected when porting my original pre-ZW5 Handler to ZW5; unfortunately, I was unable to correct this bug, likely within the ZW5 FGK-10x itself.
See my comments line 79 in the ZW5 version of the Handler : JJ’s Fibaro FGK-10x ZW5 Handler v0.9.7.4 .
The DS18B20 datasheet clearly states it is ±0.5°C accurate from -10°C to +85°C.
So if your have a pre-ZW5 FGK-10x, running my pre-ZW5 version of the Handler v0.9.5.4, then the most likely culprit (99% probability) is a defective DS18B20.
Apparently, there are some defective parts sold on eBay and elsewhere, so if you buy a new one, buy it from a well know electronic components source (Digikey…).
Thanks for the reply. I’m using this sensor purchased from amazon.
FIBARO 857934005119 Door Window Z-Wave Magnetic Opened/Closed Sensor, FGK-101, White
I have V2 hub and the version of your handler I’m running is v0.9.5.4, 3 December 2018 and hub firmware version is 000.030.00005.
My pool pilot is reading 83 degs F but as of writing this the sensor is reading 74.1 which I would say is well beyond an acceptable tolerance. Anyways, unless you have an idea I suppose I will chalk it up as defective. Thanks again for the reply.
Beware that what you call your “pool pilot” (likely similar to my own PoolCop) measures water temperature at a different place from your remote DS18B20. Upper and lower layers of water in a swimming pool may have significant temperature differences , especially when the pump is not working.
Also, I would replace the FGK-101 battery before tinkering with your remote DS18B20 : strange things happen when the battery comes near its end of life.
Anyway, the proper check would be to compare the behavior of the FGK-101 fitted with a NON-remote DS18B20, and a “calibrated” thermometer within 10" of each other.
Then you will know for sure if your remote DS18B20 is defective (which according to some posts in this thread seems to occur even more frequently than for “naked” DS18B20).
And for the sake of completeness, yes, you could customize my custom Handler and “skew” the measured temperature before it is reported by the Hub. But I do not recommend you go this way, since the temperature difference is too big to be only a minor adjustment problem.
My Pool Pilot is a salt chlorinator that has multiple sensors built in. The temp probe is built into the return so as long as the pump is running, water is passing over the probe. The DS sensor is submerged 2 feet into the water from a custom waterproof enclosure I fab’d.
Not sure what a non-remote DS18B20 is so I have some research to do.
The naked DS18B20 is the electronic chip at the end of your black cable (where it is enclosed in resin).
You may want to buy more than one, just in case you are unlucky with the first one.
The eBay link is to a UK seller with a good rating, but I am sure there are plenty too in the States.
The “naked” chip connection is as described in Diagram 2 of the Fibaro FGK-101 Operating Manual. Do not mix connections.
It is worth changing the DS18B20 sensor as they can be bad. I had one.
One thing to mention is you need to exclude and re-include the Fibaro device as the sensors have an embedded serial number that is used during the include.
Thanks for the tip. I will be sure to do that once I get a new one ordered.
Got my FGK-101 sensor working. It’s monitoring my pool temp. Using FGK-101 Temperature & Door/Window Sensor Handler v0.9.5.4, 3 December 2018. I using Smartthings and Alexa. I would like to set a alarm for 84F. Been reading around and didn’t see anything that would work. Thanks
@Mike_Funaro I am sorry Mike, but I stopped adding features to my Handler a long time ago. The little bandwidth I have available yet is fully used for maintenance.
That said, it is certainly possible to modify my handler to achieve your purpose, you just have to be familiar with SmartThings / Device Handlers / Groovy / Java and be ready to spend some (unspecified…) number of hours experimenting with the code to be added.
The good (?) thing is that, since you have a pre-ZW5 FGK-101, you won’t have to play with parameters 54 & 55…
May be somebody has already done that extension and would like to volunteer to publish it ?
I have 3 FGK-101s, each with 1 meter DS18B20 temperature probes. The 2 probes are currently suspended in ice water. The readings I’ve been getting over the last couple of hours are about 46, 47 & 50 deg F.
Could they be all bad? Do I need to wait longer for things to stabilize? (it seems like it can take hours for some changes to take effect.)
For 2 of these I’m using JJ’s Fibaro FGK-10x ZW5 Handler. For the other I’ve modified the Fibaro Door/Window handler to report temperatures, as described in a earlier post here.
I’m pretty new to this. Thanks for your help.
Hi mike, sorry about your problem.
I cannot imagine how any Handler (mine or another) could explain your oddities.
Do you have ever seen those 3 remote DS18B20 correctly working, or is it the first test you perform with them ?
I suppose if you purchased your 3 remote DS18B20 simultaneously from the same seller, they could all be part of the same defective batch.
Thanks. I’m thinking the problem is in my test setup but I’m not sure how.
I’ve been using one of these for a short time to monitor a freezer; the other two are new.
I put the 2 new probes in the freezer alongside the old one to compare the readings. I found a range of about 5 deg F, which should be out of spec. (+/- .5C I believe)
So I moved all three to ice water where I expected they should all stabilize at 32 F, and I’d be able to identify which probes were inaccurate. As you know, they did not.
I allowed the ice to melt and the water to warm to room temperature overnight.
Now the three are relatively consistent at room temperature. (I don’t have an accurate thermometer and still have the ~5 deg spread.)
So either I’ve proven that water does not melt & freeze at 32 F, or there is a 10+ deg temperature variation in a 1 pint container of ice water. Neither seems likely.
And for what it’s worth, the probes came from 2 different purchases (on Amazon. Mfgr is Gikfun. Made in China). No way to tell if they came from the same manufacturing batch.
Once I determine which probes are inaccurate, and by how much, it appears there is a way to do a temperature offset with the device handler starting at line 330.
Am I correct in assuming the device.name refers to “name” on the (attached) SmartThings IDE screen, and not the “Label”?
I confirm ±5°F is way out of specs : absolute precision of DS18B20 is specified as ±0.5°C = ±0.9°F.
But I do not recommend to just hack the handler to overcome your inaccurate DS18B20 : they may be inaccurate in more ways than a simple shift…
What I would do is buy a “naked” DS18B20 from a “reputed” vendor.
I would put it (carefully !) into one of the FGK-101 and compare it at room temperature against a (supposedly) good thermometer. Discrepancies should be below ±1°F if both are a few inches apart.
Then I would replace the naked DS18B20 by one of you remote DS18B20 : again, a few inches apart, both should give about the same result.
Then repeat for the two other DS18B20, keeping the same FGK-101.
As you know, buying from two different sellers does not guarantee you buy from different manufacturers : the Chinese logic seems to be : 1 product = 1 single (huge !) factory.
So unless your 3 remote DS18B20 look quite different, they were very likely made in the same factory, as you seem to imply from your Amazon “Gikfun” purchase.
May be ALL batches from this manufacturer are buggy ? He may have bought a batch of defective or counterfeited DS18B20 to save a few bucks…
And yes, device.name = “Name”, NOT Label (which is “Display Name”).
I got my hands on a good thermometer. And I have more probes than FGK sensors.
I think I’ll compare all the probes to my thermometer at both room temperature and at “freezer” temperature, ~10 F. I do plant to use them in freezers.
I’ll pick the most accurate probes and do the offset if necessary.
I recently installed a FIBARO 857934005119 Door Window Z-Wave Magnetic Opened/Closed Sensor FGK-101, White bought from Amazon with a DS18B20 bought on eBay
I have V2 hub firmware version is 000.030.00005 and I’m running is v0.9.5.4, 3 December 2018 of JJ’s Fibare FGK-1101 Handler
I can get an accurate temperature from my pool, but the frequency is very erratic, even if it is supposed to get it every 4 hours. Below is a recent log:
|2020-06-18 4:29 AM EDT - 1 day ago |temperature |75.0 F |F|
|2020-06-17 11:30 PM EDT - 2 days ago |temperature |75.0 F |F|
|2020-06-17 12:31 AM EDT - 2 days ago |temperature |77.0 F |F|
|2020-06-16 3:33 PM EDT - 3 days ago |temperature |69.5 F |F|
|2020-06-16 11:38 AM EDT - 3 days ago |temperature |69.5 F |F|
|2020-06-16 11:03 AM EDT - 3 days ago |temperature |70.3 F |F|
I am not sure what to do to fix it. I appreciate the insights of this forum.
My custom handler is supposed to report FGK-101 temperatures whenever there is a greater than ± 0.9 °F temperature difference since last report, or when last report was approximately more than 4-5 hours ago (in case of stable temperatures).
If you look at your trace, I agree that 2 reports (the “KO” tagged ones) violate this rule.
The cause could be unreliable transmissions, because your FGK-101 is almost out of range of the Hub. You could check that hypothesis using a Z-Wave repeater, which will need to be mains powered; or replace the battery in case it is somewhat weak (reports become erratic when that happens).
TOD °F ± °F +Hours
18/06/20 04:29 75,0 F° 0,0 F° 5,0 OK
17/06/20 23:30 75,0 F° -2,0 F° 23,0 KO
17/06/20 00:31 77,0 F° +7,5 F° 9,0 KO
16/06/20 15:33 69,5 F° 0,0 F° 3,9 OK
16/06/20 11:38 69,5 F° -0,8 F° 0,6 OK
16/06/20 11:03 70,3 F°
I understand this thread is dying as these sensors fail but I still have a number of them in use. As I only use the temperature function I was wondering if it’s possible to display that on the main tile instead of the open/close state? I have spent hours looking at the code but am unable to grasp what I’d need to do. Thanks in advance.
@briche : Hi Bob, I am not sure what you want to achieve, since my custom handler DOES display latest temperatures on the main tile, NOT the open/close state.
Any way, it is somewhat of a moot point, since thanks to SmartThings repeated efforts, I cannot use anymore either the Classic SmartThings mobile App, nor the new Samsung SmartThings App.
Once more, SmartThings has shown its total disregard for early adopters investments, breaking completely my 6 years old system, with thousands of $ and months of personal time investments.
You should consider yourself lucky yours still runs, probably because you are located in the States and the migration to the new Samsung SmartThings App worked well, when mine in France failed.
Furthermore, I am afraid to be the bringer of more bad news : AFAIU the SmartThings roadmap, they will abandon next year the Groovy language, which will definitively kill all custom Handlers.
I want to thank those who followed and helped me during those 6 years of SmartThings adventures, but it is time to find something else…
…which according to a wise man will likely be dead and need replacement within 4-5 years too, if it is cloud based too .
Those in need of perpetuating Internet temperature measurements and reportings should rather look at something like LoRa connections for the sensor (low power, low bandwidth, long distance connections), with an attached Internet bridge for SmartPhone reporting.
Anything based on a cloud unilaterally controlled by a third party will break as soon as this party finds to its benefit to break upward compatibility .
Sadly I use these for my pool and brewing. I am migrating to a dual Hubitat/ST model so the Groovy shouldn’t disappear under Hubitat.
Baby steps to stability.