In Episode 174 of the IoT Use Case Podcast, host Ing. Madeleine Mickeleit speaks with Jochen Marwede, CEO of Wendeware AG, and Boris Crismancich, Business Development Manager at KUNBUS, about the real-world deployment of industrial-grade IoT hardware and software in energy management projects. At the heart of the discussion is AMPERIX – a platform for intelligently managing battery storage systems, EV chargers, heat pumps, and other energy consumers – combined with the rugged IIoT hardware Revolution Pi by KUNBUS.
Episode 174 at a glance (and click):

Podcast episode summary
In the industrial energy transition, every kilowatt-hour – and every reliable data point – counts. But distributed sites, incompatible devices, and lack of maintenance strategies make it hard to scale IoT solutions efficiently.
In this episode, Jochen Marwede (Wendeware) and Boris Crismancich (KUNBUS) share how they tackle these challenges: with a well-architected system design, robust industrial hardware, and a flexible platform that integrates seamlessly into existing IT/OT environments.
The core of the solution is the AMPERIX IoT platform, which connects and controls large electrical assets like EV chargers, heat pumps, and hydrogen systems in real time – with secure remote updates. It’s already being used in modular battery storage projects, including those by TESVOLT.
The hardware foundation is the Revolution Pi by KUNBUS: open, robust, and equipped with features such as containerization, secure boot via TPM, and OTA rollback – making it ideal for transitioning from prototype to full-scale industrial deployment.
This episode offers actionable best practices on architecture, integration, and maintenance – and reveals how to avoid costly second iterations. It also covers upcoming regulatory requirements such as the Cyber Resilience Act.
👉 Tune in now to learn how scalable, secure, and future-ready IIoT energy systems are being built in practice.
Podcast interview
Many companies are developing controllable devices and components made in Europe or made in Germany—maybe your company too. But in practice, that’s often no longer enough in 2025. Customers now expect more: access to operational data and easy integration into their own IT systems—or into those of their customers. And this is where a common challenge arises. What we keep seeing in the IoT Use Case network is that companies lose time and money at this very point—twice over.
First: the time trap of individual device integration. Today, we’re discussing why containerized architectures are essential here, especially in light of the Cyber Resilience Act, and how missing standardization, for example with drivers and protocols, eats up valuable resources.
Second: the cost trap of missing scalability and maintenance strategies. How can a system be made maintainable and efficient in the long term—especially at scale?
To answer these questions, I’m joined today by two experts from the field: Jochen Marwede, CEO of Wendeware. They develop the IoT platform AMPERIX, a spin-off from the Fraunhofer Institute—which we’ll learn more about shortly. Also joining us is Boris Crismancich from KUNBUS. The company provides robust industrial hardware with Revolution Pi—a holistic solution for reliably capturing and processing IoT data in the field.
As always, we’ve included a real customer reference. We’ll illustrate the topic using the example of TESVOLT, a leading provider of modular energy storage systems made in Germany. Especially interesting: how TESVOLT offers both hardware and software as a white-label solution for their customers.
So tune in, take away what you need for your own projects, and move forward. All the details for implementing this and similar projects can be found, as always, at iotusecase.com and in the show notes. Let’s go! Let’s go!
Hi Boris, hi Jochen – welcome to the IoT Use Case Podcast. I’m really glad to have you both here today!
Boris, where are you calling in from right now?
Boris
You’ve reached me in our Revolution Pi trailer. It’s a small mobile unit on wheels – you might hear it creak when I move around. I like using it to stay close to wherever interesting things are happening, since I’m on the road a lot. I live in Hamburg, and our company is based in Stuttgart – so staying mobile is key.
Very cool!
Maybe we can upload a photo later of what your studio looks like.
Jochen, how about you? Are you near Boris right now, or where are you based?
Jochen
I’m sitting in our office in Kaiserslautern, in the Business Innovation Center – it’s a startup hub. We’ve rented out half a floor by now, and we’re continuing to grow. The setup is very flexible here. It’s not far from KUNBUS’s headquarters, but it’s quite a distance from Hamburg.
Nice! And what exactly are you doing in the startup center – did you recently move in, or have you been there from the start?
Jochen
We’ve been here since we were founded in 2019. With a bit of convincing, we’re allowed to stay for up to eight years. But we’re slowly starting to explore new options for where we might move next.
Great. We’ll talk more in depth about you and, of course, your company in a moment. But I’d like to kick things off with a quick introduction—Boris, so everyone knows who you are.
We’ve known each other for a while now—and for me, you’re the go-to tech expert when it comes to Industrial IoT. Officially, you’re Business Development Manager at KUNBUS, where you lead development efforts around the Revolution Pi. It’s your open, industrial-grade edge platform that’s become indispensable in many IIoT projects—and that’s exactly what we’ll be talking about today.
You bring more than 20 years of experience in tech, over six of which are in Industrial IoT—correct me if I’m wrong. You know the market inside out and you connect partners like Wendeware, Cumulocity, and many others.
The Revolution Pi is being used in countless industrial applications. From your perspective, how has the role of your IoT hardware—and software—changed in recent years, particularly around energy management?
Boris
It’s actually changed quite a lot. When we launched the Revolution Pi in 2016, energy management wasn’t really on our radar. Back then, it was more about classic automation topics.
The energy management side developed later—especially with the expansion of solar and other renewable energies. At first, the focus in the market was simply on sourcing solar panels and inverters. But once those systems were up and running, the next big question quickly emerged: “We’ve got the electricity—but what are we going to do with it?”
And that’s when energy management became a major topic. There are lots of specialists in this field—whether it’s for SCADA systems, DMS platforms, real-time processing, or handling grid commands. That’s the infrastructure layer. Then there are others focused on charging infrastructure. And now, one of the biggest questions is: What happens once the electricity is in the system?
That’s where energy storage comes in—solutions like those from TESVOLT, Voltfang, and others. These providers often come from a very specific niche and need a reliable hardware platform—but they don’t want to worry about hardware themselves.
That’s also the case with Wendeware. They’re excellent at managing energy flows between producers and consumers, and even at predicting what’s going to happen next. But for that, you need a platform.
If you look at trade fairs like smarter E Europe—Intersolar or EM-Power—you’ll see Revolution Pi solutions everywhere. Many start off using a Raspberry Pi, so the leap to the Revolution Pi is an obvious one.
Right, and we’ll talk more about TESVOLT and battery storage in detail later. But before that—how did today’s podcast session actually come about? Did you just think, “I’ll bring Wendeware along because this is such a great showcase project”?
Boris
This episode came together because we have quite a few companies using the Revolution Pi for their applications—like Doepke, which is active in energy measurement, or Eunice, which is implementing large-scale projects in Greece.
But I think Wendeware is a particularly great example because they cover both industrial and home systems. They act like the glue in the middle—the central layer that holds everything together and, more importantly, orchestrates it.
That’s why I said: this is a perfect fit. And honestly, working together is just fun. It’s not only the technical solution that works, but the chemistry, too. That’s what makes it all so smooth.
That sounds fantastic. Jochen, maybe a quick word about you and your company: You’re the CEO of Wendeware and bring many years of experience in the energy sector. I believe you worked in oil and gas before, but today your full focus is on driving the energy transition.
With Wendeware, you’ve developed the energy management system AMPERIX—an IoT-based solution that intelligently connects and controls energy producers, consumers, and storage systems.
We’ll get into that in more detail in a moment. As Boris mentioned, you work closely with KUNBUS. So let me ask you: What’s currently happening in your market? What have been your biggest learnings in recent years, especially in the context of IoT?
Jochen
The energy market has evolved very dynamically in recent years. At first, renewables were just added to the grid and somehow made to fit. But now they’ve grown to a scale where bottlenecks are becoming more frequent. We need smarter systems to manage surpluses, resolve constraints, and coordinate the various assets connected to our energy management platform.
The clear trend is moving away from optimizing individual components—like just the battery or just the EV charger—and toward holistic optimization of an entire household or commercial site. That means weighing the battery against the charging needs, energy consumption, or when to charge an EV.
The big challenge now—and in the coming years—will be: How do I optimize the entire property in the context of the overall energy system?
That raises a lot of interesting questions: Where do the signals come from? Who decides what should happen? And how do we align this highly decentralized development in renewables with centralized players like grid operators?
These are developments we’re actively shaping. The project originally started at the Fraunhofer Institute for Industrial Mathematics back in 2011. We’ve been operational as Wendeware since 2019.
Very interesting—I’d love to dive deeper into those signals you just mentioned and how all this works in practice.
Just to clarify: You’re using industrial-grade hardware—and in part, software—from KUNBUS, specifically the Revolution Pi, and combining it with your own energy management platform. Is that right?
Jochen
Yes, exactly. When we started expanding more into the commercial sector, we realized that the hardware we had been using no longer met our standards—especially in terms of reliability, availability, and the manufacturer behind it. As Boris mentioned earlier, our first tests were done with a standard Raspberry Pi, and then with a Raspberry-based system from another vendor.
When it came time to move forward professionally, choosing an industrial-grade Raspberry Pi—the Revolution Pi—was an important step for us. It allowed us to continue using our software as-is.
In fact, we mostly use the hardware from KUNBUS, and only very little of the software. We’ve built our entire software stack ourselves, starting from the bootloader (U-Boot) and up.
We can go into that more when we talk about future developments— it’s possible some things might evolve there.
Very interesting! I’d also love to know what ultimately led you to choose the Revolution Pi—what were the key decision factors?
But before we get into that, you mentioned the Fraunhofer Institute earlier. So your roots are really in software. Could you share a bit more about your background—and especially: Who are your typical customers? Who uses your solution?
Jochen
Our journey really started back in 2009 with the MySmartGrid project at the Fraunhofer ITWM. Back then, it was all about analyzing energy usage in the household—just observing and understanding what’s happening.
In 2011, we launched a project called myPowerGrid. That was the first time we looked at controlling many small, distributed batteries toward a common goal—what we called swarm batteries. That concept was quite new at the time. While it’s more well-known today, very few have actually implemented it.
The next logical step was: If you’re managing batteries, you’ll want to integrate photovoltaics, charge electric vehicles, and control heat pumps—basically, all the major electric generators and consumers. That includes things like CHP units and many other devices we support today.
At some point, it became clear: Fraunhofer does applied research and runs many projects, but it can only do so within funded initiatives. That created the need for a spin-off, and in 2019 we founded Wendeware—software for the energy transition. Since then, we’ve been commercially active on the market.
One major boost came from TESVOLT joining us early on. They’re a mid-sized manufacturer of high-quality commercial and industrial battery storage systems. That led us to focus heavily on the commercial and industrial space.
To circle back to the hardware question: For that kind of professional application, we needed the right hardware platform. We evaluated many options—and with KUNBUS, we found a partner already proven in industrial automation. They have ISO 9001-certified production, and when you—as we did—open up the device and compare it to others, you can clearly see: the quality is outstanding.
Our customers need something they can rely on—we’re sometimes controlling battery systems in the megawatt range. Downtime is not an option. If the controller fails, you’ve got a real problem.
So that’s how we ended up with KUNBUS and the Revolution Pi. The collaboration has been positive from the start—and it still is.
We’ve now been working with KUNBUS and the Revolution Pi for several years, and we plan to continue building on that partnership.
So TESVOLT isn’t just a user of your solution—they’ve also invested in Wendeware, right? Could you explain a bit more about TESVOLT’s interest? What kind of sensors or data are they looking to integrate—and why?
Jochen
TESVOLT is very strong when it comes to developing battery management systems—that’s the electronics that monitor things at the cell and module level—and in linking those systems with inverters that convert DC from the battery into AC for the grid.
What they were missing until now was the application layer—how to implement actual energy use cases, like optimizing self-consumption, peak shaving, or other energy-related scenarios at the customer site.
Strategically, their goal was to connect these two “black boxes”—battery and inverter—with intelligence, to create a complete energy management system for the market.
Got it. And the data you capture—or rather, that you connect to the Revolution Pi—what kind of sensors are those typically? Could you give a few examples from your projects, if you’re allowed to?
Jochen
Typically, we capture electrical power and energy values—like meter readings. We also collect temperature data to monitor device functionality, as well as error messages, which we consolidate on a central platform.
Additionally, we gather operational data like switch positions or sensor states—for example, whether a sensor has been triggered or not.
One example: If a system can run both grid-connected (on-grid) and in island mode (off-grid), there’s a sensor on the grid disconnect switch. That sensor gets triggered when the grid fails and the system switches to island mode. Our energy management system can then respond accordingly and adjust the battery operation.
Very interesting. You’re obviously working on a wide range of projects. Beyond power, temperature, and error messages—there must be other types of data as well, right? I’m thinking of utility meters—electricity, gas, maybe even water. Especially in industrial settings, there are often pumps or similar systems. Are you limited in any way, or are those typical use cases for you?
Jochen
Our core focus is definitely electrical—we specialize in large-scale electric producers and consumers.
But by now, we’re also integrating heat meters via M-Bus gateways, to capture flow rates, temperatures, and heat energy values.
In some specific cases, we’ve also connected gas meters—for instance, to evaluate the efficiency of a combined heat and power (CHP) unit: How much gas is used, and how much heat and electricity does it produce?
That kind of data is critical to assess whether a system is operating efficiently and to identify potential for optimization.
[16:23] Challenges, potentials and status quo – This is what the use case looks like in practice
Earlier you mentioned that hardware reliability is a key factor in your collaboration with KUNBUS.
What are the typical challenges you face in your projects—both on your side and for your customers?
Are we talking mostly about classic reliability issues, or are there infrastructure challenges too, like difficulties in getting data into your software or a cloud solution? Could you elaborate on the main stumbling blocks?
Jochen
A huge challenge is device communication. In the energy sector, this often still happens via Modbus protocols—essentially register lists that define variables and allow setting target values.
The problem is: every manufacturer does it a bit differently.
Even though there are standards like SunSpec, the SunSpec implementation from Company A often looks quite different from that of Company B.
So, there’s hardly any true standardization, and for every new device we connect, we basically have to write a new driver—similar to printer drivers.
Once that driver is in place, the inverter, for instance, simply shows up as a PV system or battery—just like in Windows, where it doesn’t matter if you’re printing to a Canon or an Epson.
But getting that driver ready involves a lot of effort—and delays the overall project.
That’s why we maintain a compatibility list: if all the devices being used are on that list, integration is quick. If not, it takes longer to bring new devices on board.
So the issue isn’t so much the hardware itself, but rather the software inside those devices.
And on top of that: not only does every manufacturer have their own system—sometimes even individual product lines differ. And with each new firmware version, something can change again.
It’s a multi-dimensional problem—you have to stay on top of it all the time to remain compatible and ensure you’re pulling the right data at the right time reliably.
Got it. Boris, I’ll get back to you in a moment—I’d love to hear whether you see similar challenges from your side or if there are other common issues you come across.
But first, one more follow-up for you, Jochen: Modbus sounds like a wired infrastructure—so more of a traditional cabling setup.
Are wireless options relevant for you too? Do you use LPWAN technologies like LoRa or mioty, or other cellular standards? Or is that not really a concern since you typically already have access to the data via the existing infrastructure?
Jochen
We typically work in environments where basic infrastructure is already in place. However, many of our customers have scenarios where, say, a Wi-Fi bridge, a Powerline connection, or even a fiber link is used between two switches. In such cases, converters are used to ensure a stable network connection on both ends.
The two main types of connections we work with are network-based—so Modbus TCP—and serial connections via RS485 using Modbus RTU.
In the past, we also experimented with one-wire systems, but we generally rely on wired solutions—simply for reasons of reliability. Our experience with Wi-Fi or Powerline is quite limited.
And the use cases you’re dealing with don’t sound like the kind where you just need a few data points every hour. These scenarios typically require higher frequency and stable communication, where a reliable line is essential.
[19:53] Lösungen, Angebote und Services – Ein Blick auf die eingesetzten Technologien
Boris, let me bring you in here: you’ve seen countless projects with customers and partners. Do you run into similar challenges to the ones Jochen just described—like reliability concerns? Or are there other common pitfalls?
Boris
Industrial-grade quality and long-term availability are absolutely essential—those are the baseline requirements.
But just as important, and maybe even more critical in practice, is versatility.
You never know what you’re going to encounter in a project. Every project is different—and I’m sure Jochen would agree.
Every customer has unique requirements, and every system needs to integrate something different. Especially in energy management, you’re likely to run into all sorts of scenarios.
Modbus RTU is widespread—your classic cabled connection. Modbus TCP is more convenient because it runs over Ethernet.
But then you’ll also encounter things like CAN bus, wireless M-Bus, or signals from various meters, like Jochen mentioned.
Or you have to deal with building automation using BACnet, PROFINET, EtherCAT—you’re hit with a wide array of technologies.
If you’re not prepared for that, it can quickly become a hardware issue. You end up with a system that simply can’t support all those demands.
That’s exactly why many customers come to us: the Revolution Pi, based on the Raspberry Pi, is the kind of system that lets them tackle whatever challenges the project throws at them. It’s modular, easily expandable, and can be adapted even down the road. And that’s key, because we’re still in a transitional and learning phase: A lot of protocols are evolving, and many devices aren’t yet “smart”—they’re controlled through simple digital inputs and outputs.
In such environments, you need a platform that’s truly versatile—and I think that’s exactly what we bring to the table.
Excellent. Are there any specific opportunities you’re currently exploring together— Particularly when it comes to the synergy between hardware, edge-based preprocessing, and your IoT backend software?
Boris
What we’re seeing more and more through our close collaboration with customers are truly integrated solutions. One great example is a photo we often share: it shows a TESVOLT battery storage unit with a Revolution Pi inside—one in TESVOLT branding, sitting right next to one from Wendeware.
I’ve seen similar setups in energy solutions from Doepke. The Revolution Pi acts as the central link that brings intelligence into the system, enabling all components to communicate with each other.
The real power, though, comes when there’s an energy management platform—like Jochen described—that sits in the middle and brings all these signals together using a wide range of drivers. Because, as he said, there are no truly standardized protocols—not with Modbus, and not with wireless meter interfaces either. Each implementation is different. That’s why it’s so important to have a platform that can standardize and process all this data—and also interact dynamically with the energy market. Like knowing: When is electricity cheap? When should I charge? When does it make sense to feed power back into the grid—and at what price? These are exactly the kinds of questions that are becoming increasingly relevant under new energy regulations here in Germany.
Absolutely. I’ll make sure to link that photo in the show notes if you send it over—along with your websites: wendeware.com and revolutionpi.com.
So if you’re listening and thinking, “This sounds like my use case”—go check it out!
And what I find really interesting is the customization: Jochen, if I understood correctly, you’re using a hardware version that carries your own branding. On your website it says “Wendeware AG,” not Revolution Pi. So you’re using the system in a kind of white-label approach?
Jochen
Exactly. We even have a version that’s branded “TESVOLT” for their systems. And right now we’re in discussions with other customers who are also interested in this option.
It’s a two-step process: visual branding—like customizing the UI for energy data dashboards—is fairly quick and easy to do. But when it comes to branding the hardware itself, there are of course minimum order quantities you have to meet to make it viable.
That’s exactly the path we’re on right now. And we really value that KUNBUS actively supports us in both customizing and branding. This enables us to build out several product lines: one under our own name, one for TESVOLT, and others for customers who want to go to market with our hardware and software under their own label.
And how do you handle integration with existing IT systems?
Do your customers want to feed their own data into AMPERIX or your IoT platform—and is that something you support?
Jochen
Yes, definitely. Our solution goes far beyond just connecting a single battery—it’s not just about that one device.
We integrate all major electrical consumers and generators that are worth it: heat pumps, heating elements, EV charging stations—including 400 kW DC chargers. We’ve even integrated three hydrogen systems and several combined heat and power (CHP) plants into our control system.
If customers already have their own systems or devices in use, we try to integrate those as far as possible as well.
The challenge is often that older equipment isn’t on our compatibility list. In that case, we either have to develop a custom protocol or, if that’s not feasible, the device may need to be replaced.
Our clear focus is on large, controllable electrical components. We’re not looking to integrate every household device—no dishwashers or washing machines—but rather the central, energy-intensive systems.
How do you ensure your solution stays low-maintenance in the field? You mentioned reliability earlier— especially with larger, decentralized systems, I’m wondering: How do you handle service and maintenance?
Is there a strategy for keeping systems stable and low-maintenance long-term?
Jochen
Definitely. Our software undergoes thorough testing on the hardware.
Right now, we’ve set up a small AMPERIX test farm so the devices aren’t just sitting on our developers’ desks or installed in their homes, but are tested centrally and systematically.
We also support remote maintenance and remote upgrades.
And our customers can log into their devices themselves, check if a new version is available, and install it independently.
Thanks to the Revolution Pi, we’ve got a solid technical foundation: it supports multiple partitions.
That means we can load a new version into a secondary partition, test it—and if anything goes wrong, just roll back to the stable version.
If everything checks out, you can finalize the update and copy it to both partitions.
This is a huge advantage: updates can be tested risk-free. And if a device malfunctions after an update, the system keeps running until the issue is resolved.
That’s how we ensure stable operation while also enabling uninterrupted troubleshooting in the field.
[28:09] Übertragbarkeit, Skalierung und nächste Schritte – So könnt ihr diesen Use Case nutzen
Have you gathered any best practices or lessons learned from your projects that you’d like to share with the community? What can we actually save by getting it right the first time – and avoiding a second iteration?
In other words: What common pitfalls should be addressed early on? What would you recommend doing differently right from the start?
Many teams are currently tackling projects similar to yours – what advice would you give them?
Jochen
Looking back, I’d say: We integrated our software quite deeply into the system.
Currently, we’re exploring more containerized approaches—like Docker—where we can leverage the underlying operating system more effectively and focus fully on the application layer.
My advice: Make architecture decisions like that as early as possible—and take the time to do it properly.
Boris
From my perspective, the Revolution Pi is made to offload things you don’t want to deal with unnecessarily.
There are countless hardware platforms in the industrial space, but a Raspberry-Pi-based solution is something most developers are already familiar with.
There are now over 80 million Raspberry Pis in use globally. Nearly every university and many research projects rely on them. The Raspberry Pi has long moved beyond the tinkering scene.
For almost any cloud connection, mathematical processing, or machine learning application, there’s ready-made software that runs perfectly well on the Revolution Pi.
That’s where we come in: we make it easy to integrate your own developments—on a platform that also provides a stable, maintained OS.
And on top of that, we offer industrial-grade hardware with features like a Trusted Platform Module (TPM), enabling secure boot and other hardware-level security mechanisms.
This creates a scalable platform for professional use cases. You can prototype on a Raspberry Pi and then scale up to industrial use with the Revolution Pi.
With the upcoming Cyber Resilience Act taking effect in 2027, it’s crucial to start thinking now about containerized architectures.
A container-based approach allows you to work with a flexible build cycle and develop your OS environment in a controlled way. That’s my clear recommendation.
Thank you very much! I’d like to invite our listeners to get in touch with Boris or Jochen if you’d like to exchange best practices or discuss your own projects. I’ll include links to their LinkedIn profiles and the websites of Wendeware and Revolution Pi in the show notes.
If you’re interested in scalability, be sure to check out Episode 169—we talk about MQTT brokers and scalable backend systems.
Also worth a listen: our episode with Portainer, a platform for Docker management, featuring projects by WAGO and others.
And if energy is your focus, tune into Episode 167 with GELSENWASSER AG—a leading infrastructure provider for water, energy, and municipal networks.
So:
follow the podcast, save your favorite episodes if you haven’t already—and stay tuned.
A big thank you to both of you for your time, your insights, and a very hands-on discussion! I found this episode incredibly valuable.
I’ll hand over the last word to you—perhaps you’d like to share something about what’s ahead or just a note of thanks for the partnership. Thanks again from my side!
Jochen
It was really great to be back with you again so soon. Thank you for the partnership – I truly mean that.
I believe the work we’re doing together – contributing to the energy transition – is incredibly important. It’s about the future: for us, for our children and grandchildren.
And with intelligent control systems, there’s so much we can achieve – more efficiently, more cost-effectively, and more reliably.
So let’s keep pushing forward together.
Boris
I think it’s fantastic. A huge thank you to you – for making this kind of format possible.
There were so many doubters at the beginning: “The energy transition will never work,” “We’ll end up with blackouts.”
But today we can see: Especially here in Germany, we’ve already transitioned a huge part of our power generation to renewables – and that’s an incredible achievement!
Madeleine, I’ve been a fan of your podcast since day one – so another big thank you from my side.
And personally, this was special: I actually joined today as a backup – and now I got to be a guest myself. I really enjoyed it.
Looking forward to the next episodes – and please keep doing what you’re doing. It’s great that both you and this podcast exist.
Thank you both!
Wishing you a great rest of the week – take care and goodbye!
Boris
Bye!
Jochen
Bye!