Thanks to visit codestin.com
Credit goes to github.com

Skip to content

ReportUtilityBills: remove electric storage from electricity produced#1554

Closed
joseph-robertson wants to merge 13 commits into
masterfrom
fix-bills-scheduled-battery
Closed

ReportUtilityBills: remove electric storage from electricity produced#1554
joseph-robertson wants to merge 13 commits into
masterfrom
fix-bills-scheduled-battery

Conversation

@joseph-robertson

@joseph-robertson joseph-robertson commented Nov 15, 2023

Copy link
Copy Markdown
Collaborator

Pull Request Description

For homes with a battery and PV, utility bill calculations based on detailed electric rates should not include electric storage. Additionally, for homes with a battery and no PV (i.e., a scheduled battery), having nonzero electricity production leads to a bug.

Checklist

PR Author: Check these when they're done. Not all may apply. strikethrough and check any that do not apply.

PR Reviewer: Verify each has been completed.

  • Schematron validator (EPvalidator.xml) has been updated
  • Sample files have been added/updated (openstudio tasks.rb update_hpxmls)
  • Tests have been added/updated (e.g., HPXMLtoOpenStudio/tests/test*.rb and/or workflow/tests/test*.rb)
  • Documentation has been updated
  • Changelog has been updated
  • openstudio tasks.rb update_measures has been run
  • No unexpected changes to simulation results of sample files

@jmaguire1

Copy link
Copy Markdown
Collaborator

In terms of how to treat battery discharge for billing: Any discharge ought to be treated as PV production, from the meter's perspective it would look the same. So if a home has no battery but does have PV, we'd need to treat the battery discharge as production.

The one caveat to this is I don't think you'd want to apply a feed in tariff if you have no PV but a scheduled battery. I've never seen a case where a utility offers a FIT for homes with a battery, just those with PV. In practice I'm not even sure these homes would be able to backfeed, but all of our other assumptions are consistent with assuming backfeeding is allowed. I'd suggest we throw an error in the case of a FIT, battery, and no PV

@joseph-robertson

Copy link
Copy Markdown
Collaborator Author

Seems like for sure the easier (perhaps short-term) solution is to only compensate for PV production. This would:

(A) maintain consistency in our current HPXML schema,
(B) be consistent with our reporting in ReportSimulationOutput, and
(C) be much easier to code up.

Maybe we leave PVCompensation -> ProductionCompensation as a future TODO?

@jmaguire1

jmaguire1 commented Nov 15, 2023

Copy link
Copy Markdown
Collaborator

I think then we wouldn't be able to calculate bills for scenarios where a battery is used for energy arbitrage, which was the thought behind allowing scheduled batteries. I still don't think we should allow the combination of feed in tariff, no PV, and battery. More generally we could just error out for FIT and no PV regardless of the battery, the FIT wouldn't change anything and if someone is supplying one they probably expect it to matter.

I also think the combination of FIT + battery with no PV is incredibly unlikely to happen in practice: if you're buying a battery for energy arbitrage, that arbitrage almost certainly won't pay for itself if net metering isn't allowed. If you have the battery following PV generation, then you're using the battery specifically to avoid backfeeding (compensated at the FIT) because that's either more valuable or backfeeding isn't allowed (as in HI).

You can get into this same situation if you have a generator as well. I think if we can the best thing to do here is to error out in any case with a FIT and no PV. Totally fine with leaving the "PVCompensation" name as is, at least for now.

@joseph-robertson

Copy link
Copy Markdown
Collaborator Author

Superseded by #1555.

@joseph-robertson joseph-robertson deleted the fix-bills-scheduled-battery branch June 12, 2024 18:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

Archived in project

Development

Successfully merging this pull request may close these issues.

3 participants