I'm assuming you added PV via the OpenStudio SketchUp Plugin user script, which generates a basic PV setup, inverter & electric load distribution.

I don't believe the OpenStudio Application supports PV editing. I also haven't found published measures that could support similar editing, or extend a basic PV setup to include Li-ion batteries. Hopefully someone more active in this area can prove me wrong. Otherwise, you're left with 3 options, IMO:

1. Adapt an SDK-based script (like this one), so it opens your model and adds/links the required PV-related objects (OpenStudio-resources tests are awesome demos).

2. Hack your generated .osm to add/edit the required PV-related objects described here. It's quicker than option #1, yet riskier (e.g. improvising OS Object handles). It may take a few tries - hit (hit & miss.miss).

3. Similar to option #2: hack your generated .idf so it reflects PV-related additions/edits here. Fewer steps than #2, yet reverse translation (from IDF to OSM) would no longer be possible.

Option #1 is definitely safer, reusable. It does require an SDK-environment, and it's definitely a learning curve for beginners. But if you plan to do similar additions/edits in the future, it may be worth the time investment. You can take it a step further: develop a measure (with a few options) and share.

I'm assuming you added PV via the OpenStudio SketchUp Plugin user script, which generates a basic PV setup, inverter & electric load distribution.

I don't believe the OpenStudio Application supports PV editing. I also haven't found published measures that could support similar editing, or extend a basic PV setup to include Li-ion batteries. Hopefully someone more active in this area can prove me wrong. Otherwise, you're left with 3 options, IMO:

1. Adapt an SDK-based script (like this one), so it opens your model and adds/links the required PV-related objects (OpenStudio-resources tests are awesome demos).

2. Hack your generated .osm to add/edit reflect the required PV-related objects described changes and additions here. It's quicker than option #1, yet riskier (e.g. improvising OS Object handles). It may take a few tries (hit & miss).

3. Similar to option #2: hack your generated .idf so it reflects to reflect the required PV-related additions/edits changes and additions here. Fewer steps than #2, yet reverse translation (from IDF to OSM) would no longer be possible.

Option #1 is definitely safer, reusable. It does require an SDK-environment, and it's definitely a learning curve for beginners. But if you plan to do similar additions/edits in the future, it may be worth the time investment. You can take it a step further: develop a measure (with a few options) and share.