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 
   • Communication standards alone cannot address demand flexibility in the complex world of gadgets
   • Defining gadget “types” in advance creates a rigid ecosystem that’s impossible to manage
   • Demand Flexibility is a customer-facing problem, not a top-down mandate
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.