Smart Hot Water Recirculation Solution

Ah… here’s what I need:

it’s not straight through. I think this may be my problem. Note the diagram above is not the correct pin out. The correct pinout is in the reply to that diagram.

regarding 3.3v vs 5. Yep, I’m using one of these:

I’ve verified that the fibaro does come up and run with the non-temp sensor DH. It’s flakey to exclude/add but eventually works, and functions properly on the wired power without the temp sensor. Adding in the temp sensor freezes everything, but I’m guessing because I had the pinout wrong.

My dog is driving me crazy and I need to take her to the park, but I’ll tackle this again tonight. I feel like I’m close.

I would try changing one thing at a time from a known good configuration (say, battery powered with DS18B20 TO-92 sensor package).
If you can get the DS18B20 TO-92 to work with your power supply but it fails when switching to the brew-pi sensor package then you probably have the sensor wired wrong – to the detriment of the Fibaro FGK-101.
You might also consider a 3.3VDC wall wart like

Good luck.

Well that would have been cheaper and easier!

I finally got it seeing the temp sensor. The Fibaro is such a finicky little device to pair, and to pair with the correct dh. A factory reset (hold both rear and internal button and power on. Hold for 5 seconds). Then to pair, you first have to have the temp sensor attached, then keep hammering at it with sets of 3x rapid clicks on the rear button. Eventually , sort of, some of the time it pairs with the DH that supports the temp sensor.

I have to say I’m unimpressed with Fibaro. I wouldn’t buy another product from them after this experience. Most z-wave devices are finicky enough, but this is more voodoo than engineering.

For anybody else that wants to do this with the brew pi, their pinout is using an rj-11 so you can wire it to a phone jack as so:

  1. Black - unused
  2. Red - 5v
  3. Green - GND
  4. Yellow - Data

Here are the corresponding pins on the Fibaro FGK-101:

Wired up and ready to install:

1 Like

Still working on trying to get the DH to report temp at a useful time resolution. This device is flakey AF and I’m not sure it’s ever going to support a time resolution that’s high enough for what I want to do.

At best, it looks like you can set param 50 “interval of temperature measurements” and param 52 “interval of reports” to 5 seconds, but according to comments in the jj2014 DH, fibaro seems to think 1 sec = 1.92 seconds, so theoretical max interval is more like 10 seconds?

Hard to say though because I can’t get the MF parameters set to save my life.

I’m about ready to give up on this device. Seems like it would be fine for monitoring a pool or freezer, but its too flakey and ad hoc for something like a hot water loop. I just can’t get the damn thing reporting at anything like a consistent or acceptably small interval.

You are in phase 2 of project life cycle. You may move to phase 3, or efficiently skip to phase 6.

  1. Wild enthusiasm
  2. Disillusionment
  3. Confusion
  4. Panic
  5. Search for the guilty
  6. Punishment of the innocent
  7. Promotion of non-participants

I suggest a simplification - by wireless contact status sensor, you monitor if the pipe is cold/hot (do not bother trying to get a quickly updated temperature reading), and ignore it if there is no motion nearby, or if the mode is unoccupied.

with strap-on aquastat like

he is basically doing that with his in line temperature sensor which measures the water temperature versus waiting for the pipe to heat up which is what the temperature sensor you are suggesting and what I have also done does.
Water temperature would be far more accurate versus the pipe temperature.

@wgmcg I meant to ask you what part number are you using for the T adapter that you put your temperature probe in?
I was thinking about doing that using the same temp probe you did to my Qubino Z-Wave Plus On Off Thermostat Module ZMNHID3 and replacing it’s temperature probe

I have mine configured to report every 4 minutes and it works well. However, I have noticed similar performance issues with my Fibaro motion/light sensor when I start to push its limits (e.g. report motion only when illuminance is very low, less than 4 lux).

The device needs to be awake when you try to set a configuration parameter. Even though you have eliminated the battery, it doesn’t know that and is sleeping to save power. I had good luck by pressing its button to wake it just before trying to set a configuration parameter.

Interesting. I don’t know what’s going on with mine. The parameters are hard coded into the JJ’s Fibaro FGK-10x zw5 handler, and perhaps my attempts to alter them broke it.

I just decided to leave mine up, because I thought it was setup to wake every 6 hours and check for configuration changes by default, but that hasn’t helped. I haven’t gotten a temp report from it since yesterday afternoon, but its still up since open/close events report immediately.

The reason I’m probably going to give up on the Fibaro for this application, is because I have a qbino sitting here. And now that its spring, I also have a reflective beam sensor for the driveway that should work as a momentary switch with the fibaro, so maybe its just easier to use my newly hard-wired fibaro in that role. Worst case, I’ll put it on freezer duty in my basement. Last summer I unwittingly unplugged the freezer to plug in a power tool, and didn’t realize for 2 weeks, so an alarm there wouldn’t hurt, though it’s not exactly a high priority.

How did you get yours down to 4 minute report time? Which DH are you using?

I have a qbino thermostat module sitting here too. That’s why I’m considering ditching the fibaro. I’m hoping the qbino can provide higher time resolution… or work at all at this point.

What I’m unclear about with the qbino is if its temp probe is a ds1820 or not. It sure looks like one…

The stainless tee and the barb fittings I used with the brew pi are further up in the thread I believe, but if not:

my Qubino reports on every temp change as far as I can tell every 0.5 degrees

1 Like

Well I had this working in a similar configuration with a DS1820 thermal glued to the pipe, which was similar to a strap on aquastat.

The problem I had with that solution is that it wasn’t quite fast enough to be useful. Between the report interval with the fibaro, and how long it took the section of copper to heat up, it couldn’t react to shut the pump off in a useful time frame. Also the fibaro just ate through batteries.

My dream scenario for the temp sensor is it should fulfill 2 functions:

A. Don’t turn on the pump on a motion event in the bathroom, when the water is already hot enough, > 90F for example.

B. Turn off the pump when hot water has arrived at the temp sensor location.

For the time being I have both functions faked with timers. For requirement A, I more or less know how long it takes for the water to cool in the pipe so I don’t let the pump run at a more frequent interval than that. For requirement B, I know roughly how long it takes to make and deliver hot water to that length of pipe, so only run the pump for that long.

This is a little less elegant, but it may end up being the good enough long term solution. I’m going to try once more with the qbino sensor and we’ll see. I really want to put that brew pi sensor in action, it’s too cool!

awesome. Is that report delta configurable? What about the sensor check interval and the report interval? I guess I have the manual here somewhere. No need to answer, I can just check myself!

just make sure your Qubino has the temp probe installed before pairing.
I just checked and it appears to be real time reporting everytime a 0.5 C occurs I would have to go through the DH and see if the 0.5 is changeable
but as you said for me the delay in waiting for the piping to heat up is to much to control the stopping but is alright for not allowing the routine to run if it sees it as already hot.

I use the default ST DTH. This doesn’t muck with any of the configuration parameters. To set these, I use the ST IDE to temporarily replace the DTH with Z-Wave tweaker …

… to set these once.

IMO, using the standard DTH is a better practice because you don’t have to maintain it. Chances are small that future versions would tromp on such settings

Oh wow, I’d completely forgotten about zwave tweaker. I had it installed so that must have been what I used for this thing previously.

So I got this message from geeji in another thread:

from geeji:
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 753 in JJ’s Fibaro FGK-10x ZW5 Handler v0.9.7.21), 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…

Using this as a guideline, here’s what’s working for me. I’m using the JJ FGK-10x DH with the following params set in the code on lines 751-755 or so:

parameter 50: 0x05
parameter 51: 1
parameter 52: 0x05

I’m now seeing updates of as little as .1F at intervals as low as 4 seconds. That’s basically what I’m looking for from the z-wave device. I’m not sure the sensor itself is sensitive enough however. It seems to take far longer to detect rising temps than falling.

so for example it takes nearly a minute to register this change from 86.7 to 112 when I’m running hot water on the sensor:

2018-03-30 2:38:38.547 PM PDT
moments ago DEVICE temperature 112.0 Hot Water Loop Temp temperature is 112.0°F
2018-03-30 2:37:44.180 PM PDT
moments ago DEVICE temperature 86.7 Hot Water Loop Temp temperature is 86.7°F

whereas this change from 105.0 to 104.6 takes only 7 seconds as it cools:
2018-03-30 2:39:27.167 PM PDT
moments ago DEVICE temperature 104.6 Hot Water Loop Temp temperature is 104.6°F
2018-03-30 2:39:20.829 PM PDT
moments ago DEVICE temperature 105.0 Hot Water Loop Temp temperature is 105.0°F

Either this has to do with the limitations of the sensor itself, or I’m reporting at TOO HIGH of an interval such that as new reports come in they’re cancelling older ones and it doesn’t report the higher state until it stabilizes? It would be so much more useful if you could see the temp run up like you can see it run down.

After some more experimentation, what appears to be happening is this.

Documentation from Fibaro on params 50-52:

  1. 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]

  2. 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]

  3. 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.

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 param 51, the report threshold is broken. I can set 52 to 5 seconds and get a report every 5 seconds, but this is super spamy.

This begs the question of how the qbino behaves in a similar scenario. Does it report when the threshold is tripped, or does it only report at a set interval?

I set only 50 and 51 to measure temperature every four minutes but only report if there was at least a 0.5c degree change from the last report. See referenced post above. This works exactly as I expect.

I just tested my theory again. I thought that perhaps setting param 52 to 0 might have shut off all reporting inadvertently, so I set it to 0x78, or 120 seconds. I then ran the thermostat under hot water and sure enough, it reported the new temp 2 min later. If it were working as expected I would have expected an instant report when it crossed the threshold set in param 51, and then regular 2m reports after that. As you can see I get 2m reports no matter what the delta T is.

Date Source Type Name Value User Displayed Text
2018-03-30 10:57:51.495 PM PDT
moments ago DEVICE temperature 91.40 Hot Water Loop Temp temperature is 91.40°F
2018-03-30 10:55:50.888 PM PDT
moments ago DEVICE temperature 91.72 Hot Water Loop Temp temperature is 91.72°F
2018-03-30 10:53:50.262 PM PDT
moments ago DEVICE temperature 94.77 Hot Water Loop Temp temperature is 94.77°F
2018-03-30 10:51:47.801 PM PDT
7 minutes ago DEVICE temperature 70.6 Hot Water Loop Temp temperature is 70.6°F

I kept the default. I get no periodic reports. I only get a report when a periodic measurement is taken (50) that is different from the previous report by an amount over the threshold (51).

Are you sure you are setting what you think you are? I encourage you to use z-wave tweaker and live logging in the IDE to see.

There’s an extended manual on the qbino webesite. Pg 58:

Parameter no. 120 – Temperature Sensor Reporting Threshold
If an external digital temperature sensor (sold separately) is connected to the device, it reports temperature readings based on the threshold defined in this parameter. This parameter only applies to the Celsius temperature unit (the Fahrenheit unit is currently not supported).
Values (size is 1 byte dec):
 Default value 5 = 0.5°C
 0 – Reporting disabled
1 - 127 = Where 1 stands for 0.1°C and 127 stands for 12.7°C

.5C seems about right to me though.