You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This story proposes to add public starter asset templates to FlexMeasures, so new users can get from an empty system to a first working proof of concept much faster (by using the new asset-copying API and UI).
The basic idea is this: FlexMeasures ships a few well-chosen template assets and template sites, users copy them into their own organisation, either because they want to learn how FlexMeasures works or even to start a (PoC) project.
In particular, this story proposes adding starter templates to FlexMeasures in two layers (and we might split the proposed steps into two PRs, if we choose so, see steps 1-3 and 4-7 below).
First, we provide reusable single assets such as a battery, EV charger, and heat pump, which are useful to any user as clean building blocks.
Second, we provide example sites composed from those same assets, plus simple demo scenario data, so early users can copy a complete setup and quickly understand forecasting and scheduling behavior in practice.
On top of that, we plan a lightweight onboarding flow in the UI: if a user copies one of these example sites, FlexMeasures can recognize that and offer a small wizard-like path to help them explore the scenario and produce a first schedule. The goal is not to hide the real product model, but to shorten the path from “empty system” to “first meaningful result”.
Planned Commits
Add generic_asset.description field
Motivation: lets us explain in the asset-copy UI what a template or normal asset represents. [also useful in general]
Add public single-asset templates and startup config
Motivation: ships reusable building blocks out of the box, still allowing hosts to disable this asset template provisioning.
This actually is the original spirit of Create three initial template assets #2165, so if we split, step 1-3 (which extend this original vision slightly, but for better UX) could go there.
Improve copy-asset dialog for templates
Motivation: makes templates easier to discover and compare in the existing copy flow, including showing more information on asset cards and prefilling the search with Template.
Add site templates built from the single assets
Motivation: gives new users ready-made, realistic example systems instead of only isolated components. A bit similar to toy tutorial probably (battery, prices, PV), or simplified parts from the HEMS script (heat pump / buffer/ SoC usage / prices)
Add scenario structure for site templates
Motivation: lets one site template support multiple simple demo situations (mainly changing some flex-config and using a different 3-day data set) without hardwiring everything into the asset definition itself.
Add wizard markers for copied site templates
Motivation: enables the UI to recognize “play” copies of site templates, and show the user guided next steps only for those, e.g. "Get started by loading a site template", see step 4, "Choose a toy scenario", see step 5, "Run a simple schedule", see step 7).
Add a first Quick Schedule action
Motivation: completes the onboarding loop by letting users produce a first schedule with minimal input. [also useful in general]
Template Structure
Single assets offered as-is
Battery, EV Charger, and Heat Pump templates remain useful as standalone assets for all users.
Example sites offered separately
These are composed from the single assets and enriched with demo beliefs and scenario setup.
Wizard only for copied site templates
The guidance should appear for site-based onboarding flows, not for every copied asset.
Quick Schedule as the first operational step
This gives users an immediate result at the end of a simple startup flow.
Scenarios
The current ideated set of scenarios is:
Battery Site Template
Scenario family: simple price-driven storage.
Sub-scenarios:
Daily arbitrage: charge in low-price hours, discharge in high-price hours.
Constrained capacity: same price pattern, but tighter power or SoC limits.
High final SoC target: user sees the effect of an end target on normal arbitrage.
EV Charging Site Template
Scenario family: small charging site with two spots.
Sub-scenarios:
Normal office day: two cars, predictable arrivals and departures.
Tight overlap: both cars need energy in overlapping windows.
Cheap-late prices: encourages delayed charging while still meeting departure constraints.
Heat Pump Site Template
Scenario family: heat flexibility with buffer.
Sub-scenarios:
Cold evening peak: demand rises later in the day, encouraging preheating.
Cheap midday power: store heat when electricity is cheap.
With sub-scenario, we can let users reuse one structural site template while varying the story through attached demo data and brief UI explanation. That keeps the model cleaner and gives new users a clearer sense of “what changes behavior”.
This story proposes to add public starter asset templates to FlexMeasures, so new users can get from an empty system to a first working proof of concept much faster (by using the new asset-copying API and UI).
The basic idea is this: FlexMeasures ships a few well-chosen template assets and template sites, users copy them into their own organisation, either because they want to learn how FlexMeasures works or even to start a (PoC) project.
In particular, this story proposes adding starter templates to FlexMeasures in two layers (and we might split the proposed steps into two PRs, if we choose so, see steps 1-3 and 4-7 below).
On top of that, we plan a lightweight onboarding flow in the UI: if a user copies one of these example sites, FlexMeasures can recognize that and offer a small wizard-like path to help them explore the scenario and produce a first schedule. The goal is not to hide the real product model, but to shorten the path from “empty system” to “first meaningful result”.
Planned Commits
Add generic_asset.description fieldMotivation: lets us explain in the asset-copy UI what a template or normal asset represents. [also useful in general]
Add public single-asset templates and startup configMotivation: ships reusable building blocks out of the box, still allowing hosts to disable this asset template provisioning.
This actually is the original spirit of Create three initial template assets #2165, so if we split, step 1-3 (which extend this original vision slightly, but for better UX) could go there.
Improve copy-asset dialog for templatesMotivation: makes templates easier to discover and compare in the existing copy flow, including showing more information on asset cards and prefilling the search with
Template.Add site templates built from the single assetsMotivation: gives new users ready-made, realistic example systems instead of only isolated components. A bit similar to toy tutorial probably (battery, prices, PV), or simplified parts from the HEMS script (heat pump / buffer/ SoC usage / prices)
Add scenario structure for site templatesMotivation: lets one site template support multiple simple demo situations (mainly changing some flex-config and using a different 3-day data set) without hardwiring everything into the asset definition itself.
Add wizard markers for copied site templatesMotivation: enables the UI to recognize “play” copies of site templates, and show the user guided next steps only for those, e.g. "Get started by loading a site template", see step 4, "Choose a toy scenario", see step 5, "Run a simple schedule", see step 7).
Add a first Quick Schedule actionMotivation: completes the onboarding loop by letting users produce a first schedule with minimal input. [also useful in general]
Template Structure
Single assets offered as-isBattery, EV Charger, and Heat Pump templates remain useful as standalone assets for all users.
Example sites offered separatelyThese are composed from the single assets and enriched with demo beliefs and scenario setup.
Wizard only for copied site templatesThe guidance should appear for site-based onboarding flows, not for every copied asset.
Quick Schedule as the first operational stepThis gives users an immediate result at the end of a simple startup flow.
Scenarios
The current ideated set of scenarios is:
Battery Site TemplateScenario family: simple price-driven storage.
Sub-scenarios:
Daily arbitrage: charge in low-price hours, discharge in high-price hours.Constrained capacity: same price pattern, but tighter power or SoC limits.High final SoC target: user sees the effect of an end target on normal arbitrage.EV Charging Site TemplateScenario family: small charging site with two spots.
Sub-scenarios:
Normal office day: two cars, predictable arrivals and departures.Tight overlap: both cars need energy in overlapping windows.Cheap-late prices: encourages delayed charging while still meeting departure constraints.Heat Pump Site TemplateScenario family: heat flexibility with buffer.
Sub-scenarios:
Cold evening peak: demand rises later in the day, encouraging preheating.Cheap midday power: store heat when electricity is cheap.Low buffer headroom: demonstrates tighter thermal storage constraints.With sub-scenario, we can let users reuse one structural site template while varying the story through attached demo data and brief UI explanation. That keeps the model cleaner and gives new users a clearer sense of “what changes behavior”.