Modeling a battery without PV

[phgupta]

I'm currently using the latest version of ResStock (v3.1.0), and I'm having trouble modeling a battery without PV. The OpenStudio-HPXML documentation states that "A battery in a home without PV or charging/discharging schedules is assumed to operate as backup and is not modeled.".

The documentation also states "A battery can alternatively be controlled using Detailed Schedule Inputs, where charging and discharging schedules are defined." I have the HPXMLtoOpenStudio/resources/schedule_files/battery.csv file locally and despite that I get the above error. I also looked into the BuildResidentialScheduleFile measure and the schedules.rb in there is doing a bunch of probability based calculations to generate the schedules.

How can I easily add a battery charging/discharging schedule without having to modify the schedules.rb file? And is there any documentation that I'm missing that clearly defines the steps for it?

Any help would be greatly appreciated!

[joseph-robertson]

On the OS-HPXML repository, there is a sample file that points to example battery detailed schedule inputs. On the ResStock side, we have yet to set up a way for users to create HPXML files where the SchedulesFilePath field gets populated (with anything other than stochastic schedules).

Ultimately the schedules_filepaths argument of the BuildResidentialHPXML measure would need to be assigned, but this is currently not officially supported. It's possible you could use options_lookup.tsv to make the assignment, but again, this is untested at this point in time...

[phgupta]

Thanks for your response @joseph-robertson. Is there a timeline for when this feature would be officially supported or is it not on your roadmap currently?

[joseph-robertson]

I don't believe it's currently on our roadmap.

One of the problems with directly including schedules_filepaths in the options_lookup.tsv is that there are several components that can optionally have detailed schedules assigned (e.g., battery charging/discharging, thermostat heating/cooling setpoints, water heater setpoints). So it's probably more appropriate to expose separate schedule arguments in ResStockArguments, and then use them to assign the single schedules_filepaths argument. Let me see if I can take at least a crack at this in a separate PR, and perhaps test it using project_testing...

Edit: here is what I had in mind.