Change from :
state.maxEventInterval = (long) (4*60-20)*60*1000 // 13 200 000 : at least 1 Temperature Report event every 3:40 hours (4 hours at most)
to:
state.maxEventInterval = (long) (1*60-5)*60*1000 // 3 300 000 : at least 1 Temperature Report event every 55mn (1 hour at most)
Remember however that if your temperature changes more than +/-0.3°C at any time, you will get an immediate temperature update, regardless of state.maxEventInterval value.
The maxEventInterval is there just so you can differentiate between a VERY stable temperature (less than +/-0.3°C variation) and a dead temperature probe.
Thank you. Exactly what I want to test for. I will run it this way till my battery runs below 50% and see if I once again start losing updates. I can live with having to replace a battery at 50% if I know that is the problem.
So what DH function(s) is called when maxEventInterval expires???
I have been playing around with you DH by adding log.debug statement in many of the functions to see what happens when this maxEventInterval (or 4 hours) expires and cant seem to find any pattern. While most of the time I see some activity (via log.debug) well before 4 hours, there have been times well over 4 hours before anything happens. That said…
I use this sensor inside my hottub which, even under very cold conditions, maintains temperature within a 0.8F range. I started to log the temperatures and found that sometimes, well over the 4 hour range, the temperature discrepancy is smaller than 0.3 and (so I believe) ST ignores (or does not log) any update even the forced 4 hour update. Does that make sense??
Well, it SHOULD produce a temperature update event at least every 4 hours, and it definitely does with the pre-ZW5 FGK-10x version.
With the ZW5 version, there are multiple bugs and incompatibilities, and I suppose you could be a victim of one of those.
Sorry, but debugging remotely is way too complicated…
…but if you find the source of the problem, I will gladly incorporate your correction in my DH.
I do not believe there is a problem with you DH or at least I have not found it. What I did find however…
If the battery is low (mine was at 48% when problems started) it almost appears like the sensor is losing connection. Out of the blue (so it seemed) my sensor stopped responding at an acceptable interval. Sometimes it was 24 hours before I (ST) would get an update. Replaced the battery with anew one and all was well. Put the old one back in and problems once again.
I am suspicious that the ST Recent Events log does not always reflect reality. I modified the DH to include an EventGhost (EG) event for each Temperature update event. My EG log, at times, contains more update event entries (at the very least, one each every 4 hours) than what ST shows.
Bottom line, I know now to replace the battery before it drops below 50%. As well, with EG providing an extra level of security, I am pretty confident I will be warned well in advance should my hot tub heater fail during the cold winter days
That is extremely curious since by definition any event seen by the Device Handler HAS to have reached the cloud. But I have many times suspected SmartThings cloud of being unreliable, randomly losing events, likely due to “race conditions” and peak overloads of servers.
When attempting to debug my Device Handler, I discovered to my dismay that the ST trace log would miss as many as 3 out of 4 debug entries pushed by my DH.
It has been worst in the past, has improved recently, but I suspect it will never disappear due to the SmartThings distributed “fire and forget” architecture (startups go fast because they do not overburden themselves with “minor” issues like 99.999% reliability ).
That is one of the reason why I would strongly advocate AGAINST any “mission critical” application based on SmartThings.
Nothing too surprising that a transmitter without sufficient power does not transmit so well…
Note also that I have observed a reverse cause : when the Z-wave network connections are of poor quality between the battery powered sensor and the ST Hub, the battery of the sensor seems to deplete faster, probably due to too many (mostly unsuccessful) retries.
As an update, I purchased a second sensor, but now it’s still 3c off, so I decided to go with the code mod. Unfortunately it doesn’t seem to offset the final reading as per your instructions.
My device name is POND TEMPERATURE. I’ve also tried the device ID but still get the same results.
Is there something I’m missing?
.
.
// Adjust measured temperature based on previous manual calibration; FGK-101 is natively °C
switch (device.name) {
case 'Pond Temperature' : //Francis
scaledSensorValue = scaledSensorValue + 3
log.debug "Temp Adjust for : ${device.name}"
break;
case 'T005' : //JJG
scaledSensorValue = scaledSensorValue + 0.0554
log.debug "Temp Adjust for : ${device.name}"
break;
case 'T006' : //MLE
scaledSensorValue = scaledSensorValue + 0.0297
First, log to the IDE and go to Devices / Show Device _your_actual_device_name_, and check the first line ‘Name’ : it should show EXACTLY your actual device name (++CASE SENSITIVE++).
Second, go to ‘My Device Handlers’ and check your FGK-101 is actually running ‘JJG2014 : JJ’s Fibaro FGK-101 Handler’.
The only discrepancy I noticed in your post is that you say your Device Name is ‘POND TEMPERATURE’ while you coded ‘Pond Temperature’ in your modified Handler, WHICH Is NOT THE SAME.
I am a bit confused there : did you purchase an other FGK-101, or an other DS18B20 ?
The most likely suspect is your DS18B20, but I find incredibly difficult to believe a second one, BOUGHT FROM A DIFFERENT VENDOR, exhibits the same extremely rare problem.
I am sorry I cannot help you more, but again there is something very fishy there, and modifying the Handler to workaround this problem is not the right way to go. This is likely a hardware problem, most likely in the DS18B20 probe, or in the FGK-101 sensor or (extremely unlikely) both.
You say you used 2 different reference thermometers and both agree.
But did you try to insert a “naked DS18B20” into your FGK-101 and check if you still have the problem ?
The naked DS18B20 chip sells on ebay for about $2, but if you are paranoid you can buy it from reputable sellers like digikey.com or mouser.com.
Well… guess what I discovered. Your code mod worked… it was my device name that was wrong. Turned out “Pond Temperature” was the LABEL and not the actual device name. Smartthings assigned it’s own device name which is why your code didn’t work. I renamed the device to match the lable name and voila… code worked.
Bad idea : if the manufacturer himself bought a whole batch of faulty DS18B20 chips, any replacement he sends to you will may be faulty too.
At that point, you should ask for a full refund from Amazon, which will have the additional benefit of alerting your DROK seller on the fact that he has a whole batch of defective probes (if he does not know already…).
FYI, buying from a different seller WHO IS NOT THE MANUFACTURER may not be a good enough protection either, if the original manufacturer of the faulty probe sold it to multiple sellers…
A different picture (zooming in) of the probe may or may not be some indication of a different manufacturer.
Sorry I cannot help more, but I never used such a remote DS18B20 probe, only the chip itself.
A number of people in this thread have successfully used remote DS18B20 probes, you may try to send a personal mail to them, hoping their own seller is still active.
Have fun in your outdoor pond (or is it only fun for fishes ? ).
I have never tried it, but considering the DS18B20 interface is fully digital, I would assume it would either work correctly, or not at all. No reason any new offset would appear, unless there is a problem at the DS18B20 chip level.
Just wondering if anything changed with the fibaro handler? Its been working for a while, since Jan for me. And 4 days ago it stopped reading the temperature. I tried pressing the button on the back and nothing happens. More strange however, the interface on the smartthings for the fibaro has changed. I can see buttons for a strobe, siren, off, configure.
Unfortunately, I can only confirm what you found.
All of the 11 FGK-101 running with my custom Device Handler stopped reporting temperatures last Thursday (September 6th, some time after 21:00 CEST).
NONE of that came from any action on my part, I have not changed ANYTHING for months.
And about the same time, the watchdog SmartApp I put in place to check that all my 11 FGK-101 were well and alive also stopped reporting.
And I do not really know how to get those temperature reports back, since SmartThings support will immediately dismiss any bug report as soon as they realize it is a custom handler…
To tell the truth, I am fed up with SmartThings unilateral changes, with zero advanced warning, and zero support whenever they break your Custom Handler.
At that time, the only suggestion I can make is for you to try to switch to the SmartThings STANDARD Handler for the FGK-101, and see what happens.
I will also submit a support ticket, with little hope…
Sorry I cannot do more.
Same here. Last report was 3:03 PM Thursday Sep 6th. It appears ST is making changes that is impacting some DH and Smartapps. As of 18 hours ago from the time of this post, the app “Simple Device Viewer” stopped reporting device status. As well, I am unable to load the setting screen for this Smartapp. Worst case, I can live without this Smartapp but not your DH. Winter is coming and I need to be able to monitor hot tub temp.
I know this will be an uphill battle but I hope St admits they broke something and fix it.
It appears there was a FW update last Thursday, however, the version # doesn’t match what my hub says
I replaced your DH with the STANDARD handler but temperature shown is that of the last update on Thur Sept 6th. The temperature is never updated.
When I try to assign your DH back to this device I get a server error. In other words. if you replace your DH with something else it appears you can not go back.
Do you have a v1 or v2 Hub ?
I have a v1 Hub, and AFAIK there has not been any firmware change for that one for YEARS (Firmware Version : 000.013.00013).
Note however that the v1 Hub forces “Cloud Execution”, as well as my custom Device Handler likely does (the rules for v2 Hub local execution were never clear for me).
Thank you very much, that may help a lot with SmartThings support ! Could you please submit a Support Request (at support@smartthings.com), NOT mentioning any custom Support Handler !
Well, I do not know if it is related, but when I use “Live Logging”, I get one or the other of those 2 messages for my FGK-101s :
09:13:43: error groovy.lang.MissingMethodException: No signature of method: static java.lang.Long.toHexString() is applicable for argument types: (java.math.BigDecimal) values: [3.90625]`
Possible solutions: toHexString(long), toString(), toString(), toString(), toString(long), toString(long, int) @line 103 (doCall)
or
09:17:33: error groovy.lang.MissingMethodException: No signature of method: static java.lang.Long.toHexString() is applicable for argument types: (java.math.BigDecimal) values: [3.90625]
Possible solutions: toHexString(long), toString(), toString(), toString(), toString(long), toString(long, int) @line 115 (doCall)
As far as I can tell, lines 103 or 115 are NOT related to my Device Handler (part of simulator).
I will do a bit more testing but I do have it (sort of) working. I ended up removing the device from ST and adding to my Aeon z-wave USB stick. This stick is the z-wave devices “source” for my Home Assistant (HA) software running on a Raspberry Pi 3. It is also a secondary hub within ST. What ever I add to HA will “magically” appear within ST
Anyway, after adding this device to HA it showed up in ST as an AEON Door/Window sensor. I tried change the DH to yours but I got the same error as before. I ended up using the STANDARD DH and… Voila… it worked.
Before I shout at ST support I will try one more thing. Remove the device from the USB stick, re-include it in ST and use the STANDARD DH but this time I will give it a few hours before I decide this DH does not work either.
What kind of error do you get exactly ?
Anything shows up in IDE 's “Live Logging” ?
Note that you may have to reset the FIBARO FGK-101 to be sure the binding is clean; I have had problems in the past where some of past binding history reappeared between 2 Device Handlers changes.
