Well that was useful. I had almost convinced my self I had a faulty sensor and/or probe. When I switched the wires according to you post everything worked.
It also sounds you have had the same problem resetting the sensor back to factory setting. I followed A YouTube video and had the results were different that that shown. The blue Led flashed once at each step and I never got the two ( or 3?) quick flashes at the last step as shown in the video. If I understand you correctly it sounds my sensor behaved identical to your during the reset process.
Did you ever figure out the right way to reset this???
I am currently using the DH v0.9.7.2, dated 9 July 2017 with a temperature probe. For most part, all is working very well. Thank you for all the effort you have put into this project. I do have a few questions though.
In the event I want to change the wakeup parameter from 60 min to 30] minutes I would change lines 698 and 733 to:
When I first installed this device in my hot tub I got a temp report almost immediately but none there after for well over 12 hours. In all fairness, I do not recall if I was using your DH or the default ST version during this period. I assumed that the sensor was out of range from the hub. When I brought it in it started to work. I played with the two types of DH and finally settled on yours. It appears to be working fine. What concerns me is the possibility of the sensor either going āofflineā of simply stop reporting temperature.
Is there a way to tell if the device is working properly without having to go outside and check to open/close or pressing the switch. I have a Power outlet that at times dropped off and became responsive. The DH for this device however had a function called Heartbeat. For every beat I send a message to my EventGhost Server. If after x minutes/hour the server does not get a heartbeat it notifies me the device is offline. Anything like that possible with you DH??
The way I reset mine to factory settings is as follows:-
If the sensor is paired, make sure the contact sensor shows open/closed in the ST app.
Remove battery.
Put the contact magnet next to the sensor. (Contact sensor closed position).
Press the sensor down on to something flat so that the tamper button on the back of the sensor is pressed in.
Put in the battery.
When blue LED lights up move magnet away from sensor.
Within 2 seconds (before LED dims) remove battery.
Look at the app to see if the sensor has stopped registering open/closed. This is how I know it has reset.
You may have to do this a couple of times to get the timing right.
This seems to work for me.
Those are the steps I follow howeverā¦ In my case, when I re-insert the battery, the LED come on and goes off almost immediately. Unlike on the youtube video which shows the light remaining on until the magnet is removed. Likewise, after removing and replacing the battery the 2nd time, the LED comes on and fades off almost immediately. Unlike the youtube video which shows the LED flashing twice
The temperature reports occur whenever the temperature +/- difference since previous report is >0.3Ā°C or every 4 hours if the temperature remains stable.
Beware that to force a temperature report every 30mn will divide by 8 the battery life.
And to do that, you need to change not only wakeUpIntervalSet (lines 698 & 733) to 30mn but also state.maxEventInterval (line 655) to 25mn
3 years ago, I was so fed up with my Devices going off line because of the unreliable SmartThings cloud that I developed the exact same thing, a SmartApp which notifies me whenever the interval between 2 consecutive temperature reports goes above 8 hours (ie. it missed at least 2 events). I could forward you the code by PM, but honestly I do not want to publicly support that SmartApp tooā¦
Also you would have to check it out but I believe SmartThings implemented something like that in a more standard way (they may have got the idea from me ! ).
Also remember that Z-wave events are way too easily ālostā by the SmartThings cloud, and that you canNOT assume any event is 100% sure to be delivered, even when you are well within the (very short) range of your Z-wave network. About 20% of the code in my Handler is ādefensive programmingā attempting (poorly) to cope with this sad realityā¦
Beware that different versions of the FGK-10x have different reset procedures.
The one you are giving is for pre-ZW5 devices.
The procedure you should apply is the one on the notice coming with your device.
The device is working so well that I see no need to change any reporting times. I am monitoring hot tub temperature and the norm is that the water temp will fluctuate a maximum of 0.8c between heater on/off. I am getting a report at least once per hour. That is good enough for me. I will setup my EG server to notify me if it doesnāt get any temp events within say a 6-8 hour period.
As for the reset procedure, this device came with next to nothing as far as documentation. Only thing it described was how to include. Couldnāt even figure out how to exclude it and discovered it by trial and error only.
check your FGK-10x firmware version , using :
IDE / My Devices / your_FGK-10x / Data.version: x.x
determine what is the actual version of your FGK-10x :
if Data.version exists and x.x <= 2.5, you have a pre-ZW5 FGK-10x
if Data.version is not displayed or x.x >= 3.2, you likely have a ZW5 FGK-10x
Note that the successor of the FGK-10x (with built-in temperature sensor and incompatible with remote DS18B20 temperature sensors) is again different : Fibaro FGDW-002 Operating Manual.
Thank you. That is the one I have. No wonder none of the other reset procedures worked. Wrong manual9s). That is the first time I saw the manual for my device. It is weird that nothing even close came with my sensor.
I just bought a couple of these sensors and got the ZW5 version. Iām using your handler and really like the interface.
Iām wondering, is there a way to calibrate the sensors with this handler? The one that I have setup in my smoker shows a difference of about 30-35 degrees when near my high end/calibrated sensor in the smoker.
I would also like to calibrate the one in my freezer.
+1. I am using the ZW5 version to monitor my hot water heater temperature and it seems to be off by 3-4 degrees compared to an analog thermometer just above it.
Plus, I want to use the door/window sensor for a seperate purpose ( just to notify me if a nearby cabinet is opened) but canāt seem to use it for that purpose with a smartapp. What am I doing wrong?
@striker, @jac6695 : out of the box, the Dallas/Maxim DS18B20 chip is 0.5Ā°C accurate. If you do not get this kind of accuracy, there is something wrong with your chip.
Calibration is not needed unless you aim at better than 0.5Ā°C accuracy.
Note that there has been rumors of defective chips sold on eBay, but I never had such a problem.
??? Connecting the optional DS18B20 chip does not disable the open/close sensor of the FGK-10x, which continues to work as usual.
So I do not understand your question.
Iāve got my sensor hardwired to power and Iād like it to provide near real time temperature updates.
What does the wakeUpIntervalSet do? Does that corespond to the wake up interval advanced param in the manual? So am I correct that you can not set it less than 3600 seconds?
What about Parameter 50 on line 751 and parameter 52 on line 760? If 0x03,0x84 = 15m = 900s = 0x384
would 0x05 = 5s?
Am I correct in understanding that at 1.92 sec the highest time resolution I can home for is just under 10sec?
what about state.maxEventInterval : 13200000
can I set this to 5*1000 for 5 seconds as well?
First I assume that you have properly checked (see above in this thread) that you DO have a ZW5 version of the FGK-101. Parameters involved differ between pre-ZW5 and ZW5 versions.
Second, āto provide near real time temperature updatesā, assuming you donāt care about power consumption, you just need to adjust 2 parameters : #50 [Interval of temperature measurements] and #51 [Temperature reports threshold [1/10th Ā°C]].
Parameter #52 [Interval of temperature reports] is just overkill unless you do have COMPLETELY stable temperature, which is unlikely is you set, for instance, Parameter #51 down to 1.
AFAIU what you try to achieve, I would just set parameter #50 down to 1 mn = 0x003C (line 751 in JJās Fibaro FGK-10x ZW5 Handler v0.9.7.2), and parameter #51 down to 0.1Ā°C = 0x0001 (tempQuantumTenth=1, lines 561 & 741).
Note that I never tested so low values, and that the ZW5 version of the FGK-101 has way too many bizarre bugsā¦
Ok wellā¦ hereās whats sort of working for me for whatever reason:
param 50: 0x05
param 51: 1
param 52: 0x05
set like this I see updates of as little as .1F at time intervals of 4-6 seconds. Kind ofā¦
Whatās interesting is I get a report every 5 seconds or so like this, but not if the temp is changing rapidly. So if the sensor is 80F and I run hot water on it, I donāt get another report until I stop running the hot water, then I get a report for 110, then 109.9, 109.8, etc at 5 sec intervals. The same is true if the sensor is at 110F and I run cold on it. I donāt get a report until after I stop running the water and the sensor is at 75 or whatever, then the every 5 second reports continue 74.9, 74.8ā¦ etc.
I donāt know if this has to do with how the DS1820 works or the fibaro, but it would be a lot more useful to me if I could see rapid run-ups and downs too.
Of course set for this frequency is probably overkill but Iām trying to characterize how the settings work for now.
After some experimentation, hereās what seems to be happening for me.
First off, documentation from Fibaro on params 50-52:
Interval of temperature measurements
This parameter defines how often the temperature will be measured.
The shorter the time, the more frequently the temperature will be
measured, but the battery life will shorten.
Available settings: 0 - temperature measurements disabled
5-32400 - time in seconds
Default setting: 300 (5min) Parameter size: 2 [bytes]
Temperature reports threshold
This parameter defines the change of temperature in comparison with last
reported, resulting in temperature report being sent to the main controller.
Available settings: 0 - temperature reports based on threshold disabled
1-300 - temperature threshold (0.1-30Ā°C, 0.1Ā°C step)
Default setting: 10 (1Ā°C ) Parameter size: 2 [bytes]
Interval of temperature reports
This parameter determines how often the temperature reports will be
sent to the main controller.
Available settings: 0 - periodic temperature reports disabled
5-32400 - time in seconds
Default setting: 0 Parameter size: 2 [bytes]
Given these parameters, it seems like what should be possible is to set 50 to 5 seconds, so that the sensor samples every 5 seconds, set 51 to 1, so that any reading delta over 1/10th of 1C generates an immediate report, and set 52 to 0, turning off reporting at interval together, since we should generate a report on every 1/10th degree C change right?
This doesnāt work. If I set param 52 to 0, disabling periodic reporting I never get anything. I get reports at the interval I set in param 52 and I donāt get any other reports. It seems to me that Iām either misunderstanding what param 51 is supposed to do, or itās broken. I can set 52 to 5 seconds and get a report every 5 seconds no matter what, but this is super spamy.
First, I would suggest you check the EFFECTIVE values of parameters #50, #51, #52 AFTER the handler has (supposedly) set them to your new values.
To do that, insert after line 722 :
It is way too easy to set parameters to the wrong values, especially for 2 bytes valuesā¦
Second, I continue to think parameter #52 should not be used (kept as current handlerās value), since it is there just to force minimal PERIODIC temperature reports, and when set with a too low value likely to interfere with very frequent THRESHOLD reports.
And third, unfortunately, you may just have discovered one or two more bugs with the way too buggy ZW5 FGK-101.
The only thing I can confirm for sure is that parameter #51 works as specified, parameter #50 conditions how frequent temperature measures are taken, and values for parameter #52 are buggy : I had to set it to 0x1D56 = 7510 (instead of theoretical 0x3840 = 14400) to effectively get more or less 4 hours wake-ups.
YMMVā¦
Thanks for the reply. The way I was trying to use this device is as a temp sensor on a hot water recirc loop. Iāve been chatting in a different thread about recirculator loops and ST, and some people are reporting that the threshold report is working for them as it should. I saw that you mentioned in a comment in the DH that some FGK-10x settings are not cleared by a factory reset, and perhaps Iāve done something like that to it, but AFAIK its never worked right for me, even when I was operating it on battery power straight out of the box.
In any event, while Iād like to continue to attempt to debug this for the sake of the community, due to time constraints Iām going to have to punt. Iāve switched the FGK-101 out to IR beam sensor duty using its momentary switch capabilities, and its working flawlessly in that capacity. I have another device, a qbino that Iām going to use for the hot water loop application.
As mentioned in the Handler"s comments, the sensorMultilevelReport() synchronous answer to sensorMultilevelGet() temperature request is buggy on ZW5 FGK-10x for whatever reason (+/-1Ā°C error).
It worked properly on pre-ZW5 FGK-10x.
AFAIK, the threshold-triggered sensorMultilevelReport() is correct for both FGK-10x versions.
Does anybody know how to clear the tampered state on this $%#$& thing?
Nothing like a āfeatureā that makes the device less useful. I can no longer see the state at a glance in the device view of ST, because it shows tampered. Otherwise working fine with an external beam sensor, I just canāt get the damn ātamperedā state cleared.
Could you show a screen copy of what you call āthe tampered stateā ?
AFAIK, there is NO such ātampered stateā in my custom Handler for the FGK-10x, there is only a āis tampered with !ā alert message, which occurs when the tamper switch at the bottom is pressed, then released after a minute or so.
).