Scaling Load Management with HARMON-E Headless

Glossary, Robert Brehm Good morning everybody, welcome to this new product masterclass webinar by FlexiCharge. We'll be with you in 30 seconds. We'll be right back. FlexiCharge Good morning everybody. Welcome to this new product masterclass by FlexiCharge. FlexiCharge after this small music introduction by Maribu State if you liked it. Thank you for joining us today from all across Europe. I can see we have people that have signed up from Italy to Norway, including major CPU names. We're happy to see FastNet and Early OnDrive to just mention a few. Thank you for being with us today. It's a big day for us at FlexiCharge. We announced this morning that Circle K has become the first Harmony Headless customer. And this is what we're going to talk about today. FlexiCharge. So Robert is going to walk you through why we created Harmony Headless and how it works in practical terms, how you can build on top of Harmony instead of having to log into Harmony. And of course, after the masterclass, please write down all your questions and we'll have a session of Q and A's, which I hope will be lively and animated. So get your questions ready. And without further delay, Robert, the stage is yours. Yes. Thank you, Chris. Welcome, everybody. Look forward to very, very exciting masterclass today on Harmony Headless, something which we have been working on for the last months. Yeah, and it's actually also quite a nice session because, yeah, we just announced our partnership with Circle K, where actually Circle K is using Harmony Headless. So there weren't any discussions about UI. There weren't only discussions with Circle K, how to operate load and energy management at scale using Harmony Headless. And that's what our masterclass is about today. Let me just fish out my slides and then we can also get it started. Just have to get around with my two screens here. So. Share. All right, Chris, just give me an OK if you can see it. Yes, you're good to go. Yeah, perfect. Yeah, as I said, welcome to, yeah, the masterclass, a new masterclass after a bit of a summer break we had. So I look forward to our new series of masterclasses, which we kick off now for the second half of 2026 and which we also going to continue in 27. Topic, the power of Harmony Headless. I quickly said a few words about it already to myself. I'm Robert. I'm the CTO and co-founder of FlexiCharge. FlexiCharge. Yeah, I've been working with load energy management systems and platforms for the last 15 years. The PhD in energy management and yeah, as I said, working as CTO for FlexiCharge since 2019. So what is it with headless? First of all, headless means in the IT world or in also embedded systems controller world, whatever, headless means that you don't have a user interface. Right. So that's the technical IT definition of headless. And this is why we call it Harmony Headless, because it's about the core capabilities of our platform. So the core load energy management engines, everything which you which you already know what Harmony can deliver, but without a user interface. And this is with respect to cover not only the trend, but basically it's a it's a huge eruption in software development, of course, now with AI coming into play. So is it the end of classic user interfaces? I think it is. So we are talking less and less about user experience and we talk more and more about artificial agents experience to operate and integrate with enterprise software applications. So there's some some Gardner research and an outlook for 2028, which is only in two years. Right. That 33 percent of enterprise software applications will include agentic AI. And that was like two years ago, only one percent. Right. And it's not only to include agentic AI. It is also to operate and integrate into enterprise software platforms. It is predicted that 15 percent of the daily day to day work decisions will be made autonomously, either by agents or by programmatically built logic, business logic, whatever. And one third of the user experience will shift from native applications like user interface, like front ends to agentic AI agent front ends. And I think we can all feel and see that already in our daily business, daily life or daily professional life, that there is no way around agentic AI agents and that the interactions with platforms are steadily decreasing. And if you if you if you look for information from a particular platform that you actually get and access that information, for example, through to an agent and you have the agent actually integrated into the different operational systems and platforms you use. And dashboards and dashboards and dashboards and dashboards and dashboards and dashboards and dashboards and user interfaces will become relevant for audit logs, of course, for for compliance reasons. As I said, design changes from user central to agent central design. So it's all about agent experience and not so much about user experience anymore. And then, of course, you have APIs and systems and interfaces like what we'll be talking about today and what we're offering with Harmony headless underneath. Right. Which are completely reachable without user interface and more importantly, also which can be operated completely independent of user interfaces. So and this is not only a trend with respect to to AI agents or autonomous systems operating platforms, but we can also see that obviously for top tier CPOs like Circuit K and others that there's actually no no way around it. Right. Right. That software and platforms and specifically load energy management systems and to to to to. Yeah, of course, also charge point management systems and all the systems around operating charging infrastructures, which is of not only the CPMS or the load management. There's, of course, also the chargers, this predictive maintenance. There's other assets around transformer substations, whatever. Right. Right. That that these systems are run by by automated software and that these systems need to seamlessly integrate into the the the the the platforms of of a CPO. Right. So that for a CPO, it's their own stack, which is the truth. And the vendor user interface is only the second source of truth or it's actually being used for for compliance reasons. And then, as I said, originally, that was a bit provocative. And the first slide and increasingly what we see also is that actually agents run the show that business intelligence tools, power BI, Grafana and so on and so forth get get get more increasingly more important, of course, and get more advanced and also obviously have some some some some agent interfaces. So that's the first thing that they're going to do. One is the real time event push. So any fault, any load signals, any important information needs to arrive at the CPO, at their systems in real time. So then rollout and operations, updates, upgrades, whatever needs to be able to be done by an API. It doesn't make sense to have hundreds, thousands of sites and have operators basically clicking through through different different settings and different configurations. And to first of all, to maintain or to update configurations. Right. Then another important requirement is, of course, data straight into business intelligence in one way or the other, rather use standard BI tools or you use AI or you build your own dashboards. But there needs to be a simple way to access your data, which is stored for you in in harmony. So the whole access to data needs to be simple and needs to be standardized and needs to be standardized. So you can use standard tools and you have standard protocols to actually seamlessly plug into into your data and get the data out of harmony. And then, of course, when you scale from 50 to 500 to 1000 sites, you want to you want to have your operations stay flat. And that comes with all these agents and automation automations operating your your fleet. And in our case, specifically operating your load management. Right. Because that obviously needs to be needs to be operated as well. So based on that, we have designed Harmony Headless and it's based or it's built on three major blocks. And you will I mean, based on the requirements I just I just introduced. The first one is a notification system. So that's a real time event push notifications. I'll introduce in a second in detail how that works, because it's it's it's it's a beautiful architecture, which which is an event bridge based on. Yeah, an event based architecture we have built right from the first day when we when we build Harmony, then we have the data lake or the data transfer. So what I said, easy integration into order easy access of your data through different interface. So I will introduce them as well. And last but not least, the configuration API where you can configure and bulk on board and maintain sites and your load management fully automated. So as first step, we're going to look into the notification system. Then I'm going to have a look into the bulk data transfer, what what options we have. And then at the end, we'll we'll have a quick look into the configuration API. So for the notification system, it's based on, as I said, and I introduce in a second that you are or your systems are actually informed at the time when an event occurs. And this is a proactive system. So it's it's doesn't need polling. So you don't need to ask every minute. OK, you ask Harmony, everything. OK, everything. OK, everything. OK, or anything changes. It's the opposite. So there's an internal event, load energy management event, for example, charger drops offline or charging profile is rejected or any other event. And we can talk about that in a second, which Harmony pushes to an endpoint you define. So you have to give us an endpoint and which you call technically in it, what you call that the web hook. And so our event bridge will route all relevant internal events to your endpoint and then your system can actually react on it. Right. Open a ticket, inform your operations team, act automatically, whatever. That's up to you to decide what to do with the event or maybe just store them for. Yeah, to to to to have the history for audit logs or whatever. So you connect via a web book. So events go to an endpoint. You can subscribe to specific events. Yeah. And specific channels, those events which are which are relevant for you to receive and might not be any. Some they want all some only want a few. And then you can fit it to your to your operation stack for ticketing, monitoring or agents or operations. Some examples for the event. And it will get a bit more clear when I explain the architecture underneath it is, for example, if any of the assets are offline, if you have a charger offline, you can also add a rule engine here where you say, OK, I only want to be informed if the charger is offline longer than 30 seconds or or one minute. And if assets are malfunctioning, for example, the charging profiles rejected or a battery is not following a specific set point. But you can also get just relevant information for energy flow, like what is the maximum charge power allocation? If that is relevant for for customers to see in an app or somewhere that they have been curtailed or other customers, they get more power because they have a gold membership card or whatever. You can see DSO or BSP events, right? So if a DSO curtailed the grid limit, see that can see if if if you're participating in in ancillary services or or trading or whatever. And any BSP event, if your battery is charged, discharged because of, you know, an ancillary service delivery. And for example, the reason for curtailment. So why at a particular point in time, for example, the charging session has been curtailed because of whatever residual load or because of a of a DSO event or whatever. So that's that's a general concept of the push notification system, how it works. And so you get the understanding why it's so powerful. I quickly dive into our architecture, just a quick recap. So internally, we operate charging sites or the load and energy management system for charging site and the charging site is a group of chargers behind the grid connection point. And we are using what we call a microservice stack to do that. So this is different. Yeah, applications, different services, which each have a specific purpose and they work together. Right. For example, a load, the load management for site is a service. The interfacing to a charger via Modbus is a service. The interfacing to a battery via Modbus is a service to read out power meter values at the grid connection point is a specific service. And all these services, they are completely independent, self-contained. Right. They can run by by by by themselves without. They don't need the other services. They just consume information and they publish information right to the other services, which will then react on it. And when I say consume and publish, this already implies that the whole architecture is basically built around an event based architecture. So what we are using internally into one of these stacks which operates a site is MQTT, which is an IoT protocol event based protocol. So it's completely based on events. So down to like our core communication between services, which as a whole provide load energy management for a site. We are really using events. Right. So they that the whole system is reactive based on event. If an interface, the charger interface, for example, Modbus charger interface publishes that the charger has been in available state and it's now in preparing state. Then the load management, for example, can react on it and say, OK, there's somebody who wants to charge and I have to allocate charge power to this one. And at the same time, it will consume from the grid power meter. What is the current total load on the on the side and how much can I actually allocate the charger? So in simple terms. So all this is what is happening inside this load management stack. And what we have been building from the also right from the beginning is to have a central back end system and provide. Yeah, to have the option to not only run these micro service stacks for a site completely isolated, but actually also have some communicating across sites on portfolio level. Right. Or have the possibility to to to to to group sites into virtual power plants and so on and so forth. And the backbone communication layer there is our central MQTT broker, which you can see here in red. So every site, every local broker, which is basically the brokerage for events, right, for publishing and subscribing to events. So any information, any information, which is relevant per site is going through that green broker and is distributed within the local stack. But at the same time, we are able to bridge all the information in real time towards our central MQTT broker. Right. So everything which goes on in the green broker can be mirrored to the central red MQTT broker. And that's, again, event based. So whenever something happens, a charging station changes state or the charging station goes offline for whatever reason, then this information is not only available locally at this green broker, but it's also centrally available in the in the broker. And it's not it's available in real time. So it's not like we update every 15 minutes or something. It's at the point in time when it happens, maybe a few hundred milliseconds later because of latency in the network. And then in our in our central back end, we have event based data processing. So that's a classic serverless architecture where you have scripts. They come up, they process an event and then they die again. Right. And an event could, for example, be if the charging if we are we are logging, of course, in our databases, in our data lake, the complete history of states of chargers or the power meter values, the allocations charge discharge power of batteries and so on and so forth. And all these information are events, they are processed and then stored into into the databases in our data lake. And of course, they are. Made available also in the user interface, so you can see what is actually going on, whereas in the user interface, it's not real time. And that's important because in the in the user interface, providing something real time would be technically possible, but commercially, economically and also from user interest in the user experience a bit tricky. And therefore, what is possible is now to have these events not only being delivered to our databases, but also to a rules engine and the push notification system. Right. Which you can see here on the right hand side. So. So. And so now we just looked into, let's say, one one one site here, but obviously, when you run hundreds or thousands of sites, you have hundreds or thousands of these MQTT brokers, the green ones. Right. And hundreds of thousands of these stacks operating sites. And they are obviously all connected to the central MQTT broker and they can all basically transport events to the webhook endpoint you provide from your IT system. So if you have 500 sites, you can get all these 500 events. And trust me, this is a lot happening per site. Or you can select which which are relevant for you and get them to your to your webhook endpoint. But and that interplays also what when we talk about the next topic is about our data lake. Of course, all the events, all the information and events is data are stored in our database. So even if you decide to not have every single event being delivered to your webhook endpoint, they will still be in our data lake and you can actually pick them up whenever you want them. Right. So, for example, as I said, you have a charging station that goes offline or it's being curtailed or there's a specific charge power allocated to it. So that whole red line here travels from the charger or the interfacing service from the charger through the green MQTT broker, through the red one, through the event based data processing, through the rules engine and then actually to your endpoint. And this is how our push notification system works. And I think it is important to understand that you can how powerful that is because our whole architecture is actually event based. And with that, basically, let's say there's almost no limits of events being delivered to your to your platform. And the next thing, as I said, is you can see it here in the in the middle, Harmony Central Backend with the databases is to talk about the Harmony data lake because it's not just a database. It's actually a data lake. And every, as I said, every data point, every event that your fleet, your network produces is actually put into this data lake. And this data lake, something we have been we have developed the last half year is is is is is is a you're using AWS. So it's a it's an Amazon Web Service data lake. And it obviously provides a standard interfaces to plug in and ready to plug in your your business intelligence, your AI or your own IT. We'll have a look how how that works in a second. So and everything, everything, what happens, as I just explained in the notification event based architecture is put into the database. So you have a complete history of your data for every site, for every charging session, for every charger. Everything is there, every power allocation, every DSO containment, whatever, every peak shaving event. It's all in there. And you can directly plug in your tools. And we we offer basically we have an SQL query engine so you can use SQL, which has been used, for example, by Power BI to query the raw data. There's no export jobs, nothing. You just query SQL queries and then you get the data. Or there's also an API where you can get the data by API to plug in, for example, into into Grafana. And everything is basically there's a security layer, of course. So there's proper authentication and so on mechanisms. So the data is, of course, clear. Sorry, secure. So you can plug in your agents. There's one source of truth, no CSV exports or whatever crazy stuff. Right. So direct access to the data. You can see energy utilization analytics, all the energy flows can make forecast with that utilization forecast. You can you see all the charging curves, everything. And obviously, you can determine additional revenue streams and you can identify flexibility, for example, by for batteries. How high is actually my battery utilized? Can I use it to participate in ancillary services? Can I do trading with a BSP? And by that, of course, identify savings as well by, you know, looking at the peaks per month. Can I add the peak shaving limit and so on and so forth? Or can I can I charge my battery with a with a day ahead price? So that's a that's a power of a data lake. Right. Everything in one place, all the data, all the history of the data. And as I said, it's based on a data lake. There's an SQL query engine on top. And as I said, direct access to the data lake via the SQL query engine via, for example, Power BI, Grafana or AI tools. And on the other side, there's also a classic generic REST API. And that's a classic way to assess your data. But typically we talk big data here. So if you have hundreds, if not thousands of sites, then it's quite quite an amount of data being produced per day or even per hour with all the energy flow data, which we also store in high resolution. And in that respect, the data API is maybe not the best tool or method or interface anymore to pull bulk data, big data from from from from hundreds or thousands of sites. And that's why we make this on the right hand side direct access via via SQL and these interfaces. There's also specific names for these protocols to pull data from the data lake. So the third thing is what we often see is that customers also sometimes because they are IT systems built in a specific way. Maybe there's also some legacy things in there because the systems have been built five, 10 years ago, not yet ready for more than big data transfer. So what we can also do is basically have customer specific retrieval patterns of data. For example, we have one customer where they actually they send us a request via an API and to get the data, but they not getting the data in the response. They actually want us to deliver also to a webhook the data from our site and then transfer it over a certain amount of time. So there's different ways of how to how you can structure basically data retrieval or data access. And important is there's a there's a solid nice data lake underneath. And the last thing I want to talk about is basically the configuration API. And that's relatively straightforward. So there's not too much to say about it. Of course, the key message here is that at some point when you have a certain scale, you don't want to click through your eyes anymore because it's error prone. Right. So if you have users manual people, humans clicking user interfaces and with more features and more options, it also you need to get more and more an expert on how to operate these systems, load and energy management systems. And in that respect, it needs to be full programmatic configurable, for example, by by scripts or services or even by by by agents. So you can bulk on board sites, hundreds of sites with basically one click configured. It's, as I said, scriptable and repeatable. So you can use the same script, you have the same results all the time. And yeah, one configuration, single source of truth. But what we also see more and more and what we also use internally in our own operations team is, of course, you plug in AI agents, right? You plug in AI agents to a configuration API and you ask the agent, OK, can you give me the configurations for whatever my my 500 sites? And can you check if there's any differences or if you if you want to apply a new feature or you want to do automatic? So if, for example, you use peak shaving rights and you have to set the peak shaving limit always right, which should not be exceeded. And you say, OK, but that peak shaving limit for 500 sites, I cannot I cannot do that manual. Right. So then you can programmatically use the data access. So the data lake gets a data, see how often has peak shaving be activated. What has been the limit? What is my utilization? Do I maybe need to change for one side the limit up because I got too much containment and these sort of information? Right. And then, of course, to to change the limit, you need to reconfigure the the the peak shaving limit. And that's why you need an API to do that to that configuration. Or let's say you have we see a lot is, of course, with the firmware versions for a charger from IPtronic or from Campower that often in major releases, there are significant changes, of course, which will also affect settings on the load management, which when you roll out a new firmware, a major release for a charger, you at the same time need and want to change for hundreds of sites and some settings in the load management. Right. Right. So this is all why, of course, the API configuration API matters. I'm just simply again, you see the architecture here is a set earlier already. So you have the data lake in the central of our our back end. Back end. And it's I didn't say that earlier, but it's not only the information. It's not only the historic data and events and the power meter values and so on and so forth being stored in the data lake, but also, of course, the configuration for each of these sites. Right. So the central back end, the data lake is also always the central single source of truth for configuration, and that will never change. The whole system is designed around that. Right. So that's what happens when you have a load management stack at the site and you're running it, for example, on our gateway and you have a power cycle. Right. So you have the gateway going offline or it's powered down and then it comes up again. The first thing it will actually do is to try to connect to the central MQTT broker to the red one here in order to first of all, transmit data which have not been synchronized yet, but also secondly to check if there have been configuration changes. Right. If there have been configuration changes, it will pick pick them up from the from the data lake. And it will, of course, store a local copy of that configuration always locally. So in case it doesn't have network connection, it will always apply the latest configuration it has received from the central MQTT broker. So in that respect, the configuration API, what it's doing is actually writing into the data lake. And when the data lake sees configuration change for a particular site or many sites, it will publish that on the MQTT broker on the red one and the green brokers, they will pick it up. They are subscribed to this event and will apply the configuration that in simple. There's a bit more behind it to also ensure that the configuration has been applied and so on and so forth. But that is in principle how that works internally in the system. So now 40 minutes already almost. And so wrap up. So. What is the goal or what we'll see in the next years is that headless is a constant. So it's a constant. So it's a fundamental core logic in the system, which is a constant and the interface is variable, right? What we will see is user interfaces will get less and less. In power, let's say static user interfaces like we see them today. They become less and less important. And then, of course, for high scale rollout, top tier CPOs, headless programmable interface is there is not a matter of a choice. It's mandatory and it's a must have. Right. And what we have been doing is we built our headless offering on three basic building blocks, push notification system, the data lake and the configuration API. What you get is automation. So no user user interface logins, no requirements on, you know, some feature has not been brought up to the user interface. So you can completely build it and integrate it into your own IT system. You get live uptime and monitoring of your platform and direct access to your data. And it's actually ready to plug in AI agents through one API surface. So I hope you liked it. And thanks for listening. And I'm happy to answer questions if there are any. Thank you, Robert, for this extensive walkthrough. I see one question that popped up for now from Julian. No, that wasn't a question. Sorry. He excused for popping out. Yes, we will share, of course, the video afterwards. Everybody will get access to the recording of the webinar. No, no, no. Don't be shy. You got a, we can wait a minute. Maybe it was just all clear. I think it's also not so. I think, I think it was. Yeah, exactly. I think it is pretty clear. You can anyway reflect and send questions afterwards. You can reach out to hello at FlexiCharge. FlexiCharge. If you have any direct access, but you probably have all of you, any contact already at FlexiCharge. We're looking forward to receiving your question. And of course, organizing demos if, if that was the interest. So yeah, we'll wrap up for today. Thank you very much for joining across Europe. And wishing everybody a great day. Thank you, Robert, for the masterclass. Thank you. Bye everybody. Yeah. Bye. Bye.