Yes, that's the most straightforward way to use the models. Also keep in mind that both the Results models and the model those reference have json/predict methods, so you may be able to consider that as well, although the Results models have some status fields that may or may not be relevant for you.

Thanks for taking a pass at it. The de-serialization methods could stand on their own, probably taking in json and returning a model, or, if there's a nice way to integrate them into the model classes then we can consider that as well. When you're ready, the best way to do a review and continue the discussion will be to make a GitHub pull request.

Thanks for sharing your plans! Looks like a good fit for the OpenEEmeter, and I'm glad to see you are also making use of EEweather.

Phil

On Fri, Nov 1, 2019 at 4:22 PM Si Chen <sichen@...> wrote:

Hello Phil,

Thanks for getting back to me.

It seems that eemeter.fit_caltrack_usage_per_day_model returns eemeter.CalTRACKUsagePerDayModelResults, which then has eemeter.CalTRACKUsagePerDayCandidateModel  as the model.  Similarly, eemeter.fit_caltrack_hourly_model returns CalTRACKHourlyModelResults, which has eemeter.CalTRACKHourlyModel.  

So in both cases, we should look in the Results and look for the model.  Is that correct?

Sure, we'd be happy to make methods to de-serialize the models and contribute them back.  Do you have any suggestions on you'd like it done?

BTW if you're interested, this Google doc is a draft of how we're planning to integrate OpenEEMeter into an overall system for M&V and financing.  If anybody else is interested, just let me know -- I'm happy to share.

-----

Si Chen
Open SoHellource Strategies, Inc.

opentaps and open source business models

at the VOLTTRON conference: https://youtu.be/2jnyIOBHrkU

On Thu, Oct 31, 2019 at 8:01 PM <ngo.phil@...> wrote:

For hourly, you are correct. For billing/daily, you'll want to make sure you are using the correct candidate model - the one chosen by the balance point grid search. See the model attribute of eemeter.CalTRACKUsagePerDayModelResults, returned by eemeter.fit_caltrack_usage_per_day_model.

The .json() methods are indeed intended for model serialization if you'd like to store the models and use them for prediction at a later point. The .json() method should give you all the data you need to be able to recreate the model. I don't think we currently have a method in the library for de-serializing the model back into its original state, but we certainly should! So if you find it's not readily doable in the context of your code, would you mind making an issue on GitHub openeemeter/eemeter and we can work together to add a de-serialization method to the library?

Phil

On Wed, Oct 30, 2019 at 4:09 PM Si Chen <sichen@...> wrote:

Hello,

I'm looking at integrating OpenEEMeter with opentaps some more, and I have a couple of questions about how to save and re-use the models from OpenEEMeter.

Are these the classes with the hourly and daily models?

eemeter.CalTRACKHourlyModel

eemeter.CalTRACKUsagePerDayCandidateModel

They both have .json() methods to return the model as a JSON.  Should we save those JSON strings in our database?  

Is there a method for bringing those models back from JSON string?

Thanks.

-----

Si Chen
Open Source Strategies, Inc.

opentaps and open source business models

at the VOLTTRON conference: https://youtu.be/2jnyIOBHrkU