openadr

, , , , , , , , , 0 comments

OpenADR 3.0 in Action!

As one of the contributors to OpenADR 2.0 – and considering our products are the only off-the-shelf OpenADR 2.0a/b VEN you can buy (yes, we’re that exclusive) and the gold standard for OpenADR 2.0 VEN – it only made sense for me to dive back into OpenADR. After all, why stop at being the best when you can aim to be the besterest? Yeah, I know… English isn’t my first language, but innovation speaks for itself!

This is not a diary, so I’ll spare you the dramatic tales of frustration, the “aha!” moments that made me feel like Einstein – only to realize that I’m not, the occasional jumping for joy (and the inevitable fall), and all the other highs and lows of developing something new. You’re welcome! Instead, let me cut to the chase and tell you about the grand finale: the culmination of it all in the OpenADR 3.0 Hackathon. (Many many thanks to Frank Sandoval and his team).

The objective was to demonstrate how OpenADR 3.0 can retrieve hourly prices from a VTN (server) and optimize gadgets based on those prices. And, well, we didn’t just make it work—we made it shine. Here’s how it all unfolded:

Step 1: Develop a Business Logic Client

This client pulls hourly price and GHG signals from LBNL servers and publishes them to the VTN (OpenADR server). It’s slick, efficient, and ready to rock. Here’s the GitHub link. Use it, remix it, commercialize it—heck, turn it into a movie plot if you like.

Step 2: Develop a VEN

The VEN authenticates with the VTN, creates a VEN entity, reads events, and schedules them. Same GitHub link. It’s like the Swiss Army knife OpenADR 3.0 tools, but cooler.

Step 3: Develop an IoX Plugin for the VEN

This plugin sends price and GHG events to our platform. And yes, we clocked it—just 36.13 minutes flat to develop and test. 🏎️ (No speeding tickets, I promise.)

Step 4: Make It Work (and Show Off)

To really flex what OpenADR 3.0 can do, we connected it to both local and internet-based exotic gadgets. Behold the lineup:

  • Philips Hue (via Zigbee) – Smart lights that not only vibe with price signals but look good doing it.
  • Ecobee at the Office in Encino (via Internet) – A thermostat so gorgeous it could trade HVAC for the runway.
  • Plugin Module (via Z-Wave) – Small but mighty, proving optimization doesn’t discriminate by load size.
  • Tesla somewhere in CA (via Internet) – The showstopper. Because optimizing the electric car elevates this from “cool” to “legendary.”

Optimization was pretty straightforward: use price signals to dim or brighten the Hue bulbs, adjust thermostat set points, cycle the smart plug, and pause Tesla charging. Nice, riggghhhttttt???

Step 5: Go to the Hackathon

It was a looooonnnnggg drive, but totally worth it. Between the demo, the buzz of meeting your zoom-only colleagues in person, and the sheer joy of pulling this off, it was the perfect finish to an incredible journey.

And here’s the link to the picture gallery of the team, colleagues, and fellow geeks. Thank you, Alfredo!

 

, , , , , , ,

Been There, Done That …

 … 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:

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)