Temperature-initiated shower flow restriction valve

[nmerket]

From Torsten Glidden at Energy Upgrade California:

---

Here's what we're trying to capture:

• Number of installed low-flow showerheads with integrated Temperature-initiated Shower Flow Restriction Valve (Evolve "Roadrunner")
• Number of installed Temperature-initiated Shower Flow Restriction Valve adapters (Evolve "Ladybug")

At the moment there's only one manufacturer in the 'finish trim' market in CA
http://www.evolveshowerheads.com/evolve_products.html

Data capture would require:

• Manufacturer
• Model Number (or Name?)
• Quantity Installed

Optional data capture might include:

• Model Year
• Number of Showers (existing)
• Fuel
• Deemed Savings

---

[nmerket]

This seems like it would fit best under the new WaterFixture element.

There would be another sub element in there called TemperatureInitiatedShowerFlowRestrictionValve with the following sub-elements:

• SystemIdentifier
• Manufacturer
• Model
• extension

Since a WaterFixture describes one showerhead or faucet, there should be one for each considered in the house. There the number of TISFRVs could just be counted.

[nmerket]

Alternatively we could just have a boolean element that says whether it's there or not if we don't need all that additional info.

[nmerket]

@andybardwell @GamalielL
I know Optimiser had some issues with this proposal. What do you think would be a good way to include these?

[andybardwell]

Supporting a new SystemIdentifier is burdensome, and if it is used to specify measures, requires separating savings from low volume fixtures and the TemperatureInitiatedShowerFlowRestrictionValve.

Removing the SystemIdentifier would leave:

TemperatureInitiatedShowerFlowRestrictionValve
with subelements:
Manufacturer
Model
extension

[GamalielL]

Andy and I just talked and we have revised our position. We now feel that we should only add a single Boolean element for TemperatureInitiatedShowerFlowRestrictionValve. From an energy savings and modelling perspective it is really irrelevant whether the device is integrated or add-on. The only reason that EUC cares is that the integrated device is part of a low-flow shower head and so their deemed savings calculation includes savings for the low-flow improvement. There is already a FlowRate element that will adequately capture a change in flow rate of the shower head, so they will be able to use that to distinguish between the two upgrades.

[nmerket]

That sounds reasonable to me. Much more than a boolean sounds like overkill. I'll reach out to Torsten and see if that works for them.

[nmerket]

from Torsten:

I will pose this potential solution to the CA implementers group in our meeting this afternoon and let you know. It seems to me to be a reasonable solution, but I want to make sure the other implementers feel similarly before we pull the trigger on anything.

[nmerket]

Torsten says we're good to go here. I'll make it happen.

[nmerket]

Added the element:

If I don't hear anything I'll close this ticket and assume we're all good.

[GamalielL]

Looks good!

On Tue, Dec 16, 2014 at 6:30 PM, Noel Merket notifications@github.com
wrote:

Added the element:
[image: baseelements_waterfixture]
https://cloud.githubusercontent.com/assets/5325034/5464080/c535d132-8540-11e4-8941-e6088d242208.png
If I don't hear anything I'll close this ticket and assume we're all good.

—
Reply to this email directly or view it on GitHub
#15 (comment).