Case study: FlexMeasures in the meter cabinet

"FlexMeasures does the part that is hard to get right and easy to get wrong without noticing. That left us free to spend our time on the part customers actually see."

Sam Aerts, co-founder, Luo (Belgium).

Luo builds an energy management system, Helios, for European households and SMEs. FlexMeasures is the optimisation engine inside it, running on the device in the meter cabinet rather than in a data centre.

Helios at a glance: 200+ sites live. On the market since April 2026. One instance per site, on-premise. Plan resolution 15 minutes. PV, battery and EV charger per site.

The product: Every brand wants to be the brain

Most sites have solar, a battery and, increasingly often, an EV charger. Almost never all from the same maker. Each one comes with its own EMS that handles its own gear and ignores the rest. So when a customer adds something, you get two systems pulling in different directions, or you rip out what is already on the wall. Either way the payback gets worse.

Helios sits above all of it and belongs to none of them. The installer can fit whichever brand they like next to what is already there. We do the commissioning and the support for the EMS ourselves, so their electricians can stay on electrical work instead of on network settings, integrations and the phone calls that come after.

Our partners each put in around eight new sites a day. An electrician sets one up in an afternoon and then walks away. So nothing here can need an engineer to tune it per site, and nothing can need weeks of data before it starts doing something sensible.

Deployment: Where FlexMeasures runs

Not in our cloud. Each site gets a small computer in the meter cabinet, wired into the installation, and FlexMeasures runs on it. One instance per site, sitting next to the drivers that talk to the inverter and the charge point. Decisions get made in seconds, not in a round trip to a data centre.

Having our own hardware on site is what lets us promise things we could not promise otherwise. The logic that steers the assets is on the same side of the connection as the assets, which is what electrical safety needs. Site data and credentials never have to leave the building. And when the internet drops, nothing stops: the site keeps measuring, planning and steering until the line comes back.

What we pay for that is room. The whole optimisation has to run on that little computer, and it has to come up with something sensible on the day the electrician leaves, with no history to go on.

What FlexMeasures does for us

The data model. Assets, sensors and beliefs that know where a value came from and how far ahead it was made. We would have had to build something like it anyway: a way to keep "this is what the meter read", "this is what we predicted at 10:00" and "this is what we intend to do" next to each other, and to know which one wins when they disagree. Get that wrong and an EMS quietly stops making sense. It was already there.

The scheduler. We describe a site as a tree. Grid connection at the top, with the battery, the charge point and the PV array underneath, each with its own flex model. Anything we cannot steer goes in as an inflexible device sensor. FlexMeasures turns that into a linear program and hands back a plan in 15-minute steps, as far ahead as our price data reaches.

• Costs that are not the grid price. A battery wears out a little every cycle. An EV charging at the office may be paid for by the employer. We hand those over as commitments and the solver weighs them against the grid price. We did not write a line of asset-specific code for it.
• Curtailment as a storage problem. We gave the array a production capacity that points at its own forecast sensor, and that was enough to make negative prices behave. When Belgian prices hit -0.50 EUR/kWh, sites curtailed by themselves. Nobody touched anything.
• One limit for the whole site. The connection limit and the capacity tariff are the same constraint as far as the solver is concerned. It holds both while the assets underneath fight over what is left.

What it doesn't do

If you are weighing up FlexMeasures for your own product, this is the part to read. It gives you a well-posed optimisation problem. It does not give you good numbers to put into it, and the numbers are where the money is.

• A Belgian bill is not the market price. It is the market price plus network tariffs, excise, VAT and a capacity tariff, and the order you stack them in decides which quarter hour is actually the cheapest. Software written for another market gets this slightly wrong and then steers with great confidence on a wrong number. Working out what a kilowatt-hour really costs at 14:15 is our job. Once it is a sensor, FlexMeasures optimises against it.
• The forecasts. Consumption, PV production and the price curve ahead all come out of our own pipeline, on the same small computer. A time-series foundation model that looks at the site's own history and the weather, with a plain empirical fallback for a site that was switched on yesterday and has nothing to look back on. A new install has to behave on day one, so the cold start is not a research nicety, it is a requirement. FlexMeasures is the database underneath it. The models are ours.
• Everything between the plan and the hardware. Drivers for every brand of inverter and charge point, because we tell customers they are not locked in and that promise gets paid for in driver work. The control loop that turns a 15-minute plan into setpoints. And what happens when a site does something nobody predicted: someone puts the oven on, the plan from ten minutes ago is wrong, we notice and ask for a new one, handing the error back as a sensor so the solver can see it. That part is ours. The solver stays FlexMeasures.

Would we do it again

Yes. Open source got FlexMeasures onto our list; what decided it was no licence on hardware we own, and that it already handled many sites.

When we started we knew EMHASS, and went looking for what else was out there. What we could not find was anyone who had already put FlexMeasures inside a product they sell, and who would say plainly where the joins are: what it does for you, what you still have to build yourself, and what it takes to run it on real hardware in someone's meter cabinet.

That is what this case study is for. We stay close to upstream and extend the storage scheduler by sub-classing it instead of forking, which keeps upgrades cheap. If you are making the same call now, come and ask us.