thomastu
commented
3 years ago A literature review on different gas schedules should be done, but as a first pass, the following structure should be supported:
- Fixed daily or monthly meter charges ($/time)
- Flat procurement charges ($/Therm)
- Tiered transportation charges ($/Therm up to X therms, after which another rate is effective),
Motivation
Utility bills are typically composed of three sections - electricity, gas and water. The scope of this project is to capture energy costs. Gas costs are omitted due to a lack of data access.
Implementation
Below is a high level description of a proposed implementation.
Create an interface for user-input gas rates. A separate module should be responsible for implementing bill prices for different gas billing structures. Rates should specify a structure upon instantiation. Finally, on bill calculation, a timeseries of "energy" inputs should be taken in to calculate different bill components.
Challenges
There is no equivalent service for gas rates to the utility-rate-database by OpenEI. While national commercial gas rates are not expected to differ drastically, some kind of justification needs to inform the rate API design for gas. To create manual gas rates would also require manually pulling in rate sheets at an individual utility level. For a single-site application, this is probably fine, but in a usecase where energy or utility bill prices are being compared across utility regions, the lack of a central data service will start to become a challenge.