openadr

, , , , , , , , , 0 comments

Say Hello to NuCoreAI: A New Chapter for UD

I can’t believe it’s already been seven months since we introduced OPEn (Open Platform for Energy) and promised to keep you in the loop. Time really does fly, or maybe my memory just isn’t what it used to be! A lot has happened since then, and while I thought I’d shared all the updates… turns out I hadn’t.

So, here’s a quick recap:

  • We realized that relying on cloud-based AI services, tools, and models made OPEn way too expensive to be practical. That led to a big shift in focus: we moved to a local, embedded solution. After a ton of research (check out the full story [here]), we’ve hit about 80% success and uncovered lots of ways to improve even more.

  • To make everything open, collaborative, and completely license-free, along with Rolf Bienert at Bienert Consulting, we established the non-profit NuCoreAI Foundation and donated all our work products, including code, AI models, agents, and workflow to the community.

Want to help build the energy platform of the future? Join NuCoreAI.

See you there!!!

, , , , , , , 0 comments

We Did It Again: First OpenADR 3.0 Certified VEN!

Yes, we did it again! We’re proud to announce that eisy is the first to achieve OpenADR 3.0 Certified VEN status! And we didn’t stop there – we’ve made our certified VEN open source so you can all experience its elegance for yourselves!

This achievement comes as the OpenADR Alliance officially announced the first wave of OpenADR 3.0 certified products, with eisy leading the charge. As reported in the March 24th press release, global standards development within the energy management sector continues to accelerate, and we’re thrilled to be at the forefront of this innovation.

By open-sourcing our certified VEN implementation, we’re not just celebrating our own success – we’re contributing to the growing ecosystem of standards-based solutions for energy management worldwide. This move aligns perfectly with the industry’s push toward more interoperable, efficient energy management systems.

Our team has worked tirelessly to ensure our VEN implementation meets the rigorous certification requirements while maintaining the clean, elegant code our developers have come to expect from eisy. We can’t wait to see what you’ll build with it!

, , , , , , , 0 comments

OpenADR Alliance Webinar on OPEn

Join me for the upcoming complimentary OpenADR Alliance Webinar:

Smarter Buildings & Homes: How AI and OpenADR 3 Can Redefine Local Demand Flexibility.

✅ How AI and OpenADR 3.0 eliminates need for yet another new standard
✅ How this technology adapts to any future energy use case
✅ The key components that make this possible
✅ A short but realistic demo showcasing AI-driven demand flexibility in action

When: Wednesday, February 26th at 8AM Pacific Time / 17:00 CET

Link to Register: https://lnkd.in/gG2pCg7s

Slides: https://www.openadr.org/assets/OPEn-Webinar-v5.pdf

Recording: https://www.openadr.org/assets/OPEn_AI_Webinar.mp4

, , , , , , , 0 comments

IEEE PES Grid Edge Technologies

I’m thrilled (terrified) to announce I’ll be presenting OPEn at IEEE PES Grid Edge Technologies on Monday 01/20/2025 in San Diego. For those keeping score, I’m currently avoiding counting down the seconds until I must emerge from my natural habitat of comfortable solitude to interact with … shudders … people!

Why should you come?

– Your intense stares, or complete lack of them, will help maximize my nervous sweating.
– Your mere existence is enough to put me in survival mode.
– Your potential questions have the power to factory-reset my brain on the spot.
– Bonus points if you sit in the front row, nod excessively, look utterly bored, or seem completely confused.
– And if I make it out unscathed… you just might learn about OPEn!

Location: That terrifying room where dreams of peaceful solitude go to die.
Time: Too soon. Way too soon.

RSVP by simply existing. Your attendance will ensure my presentation becomes a core memory that will haunt me for years to come!

Antisocially yours,
Michel

P.S. This entire announcement was generated by AI because I’ve already forgotten how to English.

, , , , , , , 0 comments

OPEn Part I

A couple of weeks ago, I teased you with my idea of OPEn (Open Platform for Energy). Now, it’s time to rock a few boats, and bring some pies down from the sky (consider this my official disclaimer).

To make things easier, I’ve included a table of contents so you can jump to what piques your interest. That said, I highly recommend Section 2, where I share a real-life example of how we can achieve demand flexibility without introducing new standards—using OPEn in conjunction with a simple exchange with AI (ChatGPT, in this case).

Table of contents:

  1. Let’s start by rocking a few boats 
  2. Let’s bring some pies down from the sky 
  3. OPEn

1. Let’s start by rocking a few boats:

Please, let’s put a stop to all the new standards (or whatever we’re calling them these days—guidelines, consortiums, etc.) that claim to once again improve communication between the grid and gadgets to address interoperability for demand flexibility. Why, you ask? Because, let’s face it, we’ve tried every permutation under the sun. 

Here’s why we keep falling short of achieving our goals:

A. Communication standards alone cannot address demand flexibility in the complex world of gadgets.

  • It’s impossible to design a perfect superset. Points, clusters, command classes, gadget types, aggregations – you name it—no single standard can cover every potential use case. Reducing everything to sensors and actuators is possible and has been done, but it requires an enormous, impractical dictionary for every protocol—something only a masochist or a supercomputer would want to maintain.
  • Manufacturers thrive on differentiation. Every communication standard—Z-Wave, Zigbee, Matter, you name it—leaves room for “manufacturer-specific” features outside the spec. And while enforcing a meaningful subset for demand flexibility sounds great in theory, in practice? It works about as well as herding cats.
  • Proxy signals are good but not sufficient. Sending signals like price, time of use, or GHG intensity and expecting gadgets to figure it out independently creates chaos. Each gadget operates in its own silo, ignoring the rest and leaving customers with a disjointed mess. It’s anything but user-friendly.

B. Defining gadget “types” in advance creates a rigid ecosystem that’s impossible to manage.

  • Categorization is a losing game. Trying to create a master list of all possible gadget types (including those not yet invented) is like sorting books in a library where new titles are added every second. While conceptually similar to sensors and actuators, it’s broader—and just as painful.
  • Misclassification is inevitable. Forcing devices into predefined categories often creates messy overlaps and inconsistencies:
    • A Nest thermostat, with its occupancy sensors, is still strictly classified as a thermostat.
    • A Tesla? Sure, it’s an EV, but it’s not energy storage (yet)—unlike the Ford F-150 Lightning, which is classified as both.
    • Add devices that report energy usage, and you’re diving into aggregations, channels, and endpoints.
    • And then there’s Tesla Optimus. What even is that in terms of gadget points? Best not to open that can of wormbots!
  • Endless debates stall progress. These rigid classifications create confusion, lead to endless arguments, and ultimately make it impossible to establish a scalable and practical solution.

C. Demand Flexibility is a customer-facing problem, not a top-down mandate.

Until AGI robots take over, demand flexibility is not a dictatorial fiat imposed by the grid, utilities, or the government. Here’s why:

  • Customers are in charge. Unless we assume customers are clueless (a dangerous and misguided assumption), they already understand what a thermostat, an EV, a pool controller, and a utility bill are. They know how to balance their preferences between saving money and staying comfortable. The rest? It’s just noise.
  • We’re stuck in the past. While AI is transforming everything from grocery lists to self-driving cars, demand flexibility is still stuck in the FM thermostat era—a world where the entire problem is reduced to a single signal and devices obediently responding to it. This outdated mentality has been rehashed in countless forms, but it’s no closer to addressing the real challenges of demand flexibility.

2. Let’s bring some pies down from the sky:

Here’s the cool part!!! I am going to show you how we can easily use ChatGPT for a simple optimization of a thermostat based on utility price signals in our OPEn platform eisy. Here are the steps:

a. Thermostat representation in JSON. The thermostat plugin represents the thermostat using our JSON file. This said, you can invent your own. The only requirements are that properties and commands must also have human readable names!

b. Feed it to ChatGPT

And I pasted the JSON!

c. See if it ChatGPT understood:

Yes, it understood! It mapped the name Cool Setpoint to the esoteric id of CLISPC!!! 

d. Nice, but how about utility price? 

Well, as before, I fed ChatGPT JSON representation of a VEN (OpenADR client that retrieves prices):

e. Ask it to optimize the thermostat based on utility prices!

f. Voila!!!

3. OPEn

The purpose of the example in section 2 was to demonstrate and highlight the 5 pillars of OPEn:

  1. Typeless: Enables interoperability without requiring prior knowledge of the type of the device or entity.
  2. ID-agnostic: Enables interoperability without requiring prior knowledge of element IDs, clusters, command classes, or similar constructs.
  3. UOM (Unit of Measure): Ensures enhanced accuracy and allows for seamless unit conversions.
  4. Editor: Helps UI components and AI agents understand property constraints, such as permissible value ranges (e.g., temperature or price), steps, precision, and more.
  5. Plugin Execution Environment: Allows gadgets, services, widgets, and optimizations to run and work together seamlessly without requiring prior knowledge of each other.

In OPEN part II, we’ll delve deeper into each of these pillars.

, , , , , , , , , 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)

1 2