… over and over and over again! And yet, here I am, doing it all again.

You may be wondering what exactly it is that I have been and continue doing. So, let’s take a little detour back in time.

It was 1984, just a few months after I’d arrived in the U.S. from a place where blackouts were as common as the daily debate over battery-powered versus gasoline-lit lanterns. There I was, settling into my new life, when – bam! – a blackout hit. Suddenly, I was back in the dark, sweating profusely, and wondering if my escape to the U.S. had only been a dream.

Years later, I finally learned about the energy crisis of the 1970s, 80s, and 00s, and demand-side management as an alternative to new power plants, and even the interesting world of FM thermostats. Could it be that the real culprit behind those blackouts was… thermostats not tuned to the right radio station? 😉

And so began my journey into the world of “demand-x” – where “x” could mean management, response, flexibility, or whatever buzzword comes next. With my geeky, slightly antisocial, but thoroughly pro-gadget nature, I found myself captivated by the endless possibilities of intelligently controlling gadgets to prevent future blackouts. I was hooked!

By the time I went all in – only to my great dismay – solar panels seemed to be pushing “demand-x” toward “demand-no-more.” But lo and behold, over generation and GHG reduction goals came to the rescue, and electrification and EVs revived “demand-x” to its former glory! Suddenly, the goal was clear: tame the “duck curve” by shifting, shedding, shimming, and shaping demand through innovations like Fast DR, prices-to-devices, dynamic and time-of-use rates, and transactive energy.

I found myself in a new world where gadgets, the internet, and the grid fused to create the Smart Grid, DERs, DERMS, Microgrids, Virtual Power Plants, V2G, and V2B. It was heaven! Or so I thought… until it turned into Groundhog Day, repeating endlessly as my team and I found ourselves constantly developing, integrating, and dabbling in countless versions of smart grid and gadget communication protocols and standards, such as:

• Grid-side standards: OpenADR 2.0a/b, SunSpec, OCPP, Modbus, SEP 1.1, SEP 2.0, and CTA-2045.
• Behind-the-meter protocols: Z-Wave, a plethora of Zigbee profiles, Thread, KNX, BACnet, Bluetooth Low Energy (BLE) and BLE Mesh, LoRa, and an array of WiFi-based proprietary protocols.

Oh, and let’s not forget the exorbitant costs of joining every alliance under the sun, all while figuring out what to do with service fees from providers like SolarEdge and Enphase. And, of course, there’s the joy of trying to integrate gadgets from manufacturers – like Nest – who decided that offering demand-x for their thermostats require going through a DERMs provider. Because, clearly, what we needed was yet another middleman!

Fast forward to the present, and the endless cycle of developing and integrating competing, overlapping communication standards and protocols continues: OpenADR 3.0 promises infinite flexibility to integrate nearly anything, while Matter aims to become the de-facto protocol for all gadgets. And here we are again – reluctantly diving back into the cycle, feeling a bit nostalgic for those old FM thermostats and wondering why Tesla[1] hasn’t jumped in yet!

Thus, if history’s any guide, creating a standard that covers every feature of every gadget is about as likely as convincing Tesla to ditch its rich APIs for OCPP – good luck with that! Manufacturer-specific features may turn interoperability into a headache, but that’s exactly what makes companies stand out. That’s why, even with Matter-enabled devices, customers still rely on native apps for advanced features beyond the basics.

So, if standards aren’t the answer, what is? Let’s flip it: would we really have a bazillion apps on our phones if all we had were ‘communication standards’ for banking, games, insurance, utilities, streaming, and so on? Not a chance! Standards are great, but when you’re dealing with a chaotic mix of gadgets and services, they can only take you so far. What you need is a platform – something like an ‘iPhone or Android for Energy’ that lets these devices live freely, just as their designers dreamed them up.

So, instead of rolling out yet another standard, let’s create an Open Platform for Energy (OPEn) – one where manufacturers, alliances, and developers can actually develop plugins and apps for their gadgets, services, optimizations, UI, or whatever else they dream up.

The whole purpose? Simple: host, manage, and run these plugins. What these plugins do, how much they cost (if at all), and how they communicate with gadgets or services, or even how they interact with users – that’s all in the hands of manufacturers and developers. 

In the coming weeks, I’ll be sharing more details on my vision for OPEn. For now, I’ll leave you with this:

It must be open to everyone – for development, commercialization, and use without any limitations!

[1] Tesla uses its own proprietary protocol based on J1772 and CCS (Combined Charging System)