Blog

Sundry blogs by the UD Team spanning topics in energy, automation, iot, and AI.

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

, , 0 comments

LBNL Awards UD a Contract

Implementing an energy management gateway at each customer site presents significant advantages in terms of cost reduction and performance enhancement for flexible loads and devices, especially in environments characterized by Highly Dynamic Prices. While this functionality could be incorporated into existing devices, certain scenarios—like non-broadband customers or situations requiring meter data—require the deployment of new hardware. Furthermore, the vast majority of California’s current loads cannot directly respond to dynamic pricing, making price optimization for the hundreds of millions of legacy devices crucial.

An energy management gateway can address these challenges by processing price signals and optimizing device performance. The core objectives of this project are:

Price Integration with OpenADR 3.0

  • Implement functionality to receive and process price signals using OpenADR 3.0.

Cellular Data Connection (5G) Integration

  • Integrate a 5G cellular data connection to ensure connectivity in diverse scenarios.
  • Investigate the feasibility of using up to three different cellular modules and plans to assess:
    • Cost implications.
    • Network coverage.
    • Bandwidth constraints.
    • Other relevant characteristics and capabilities.

Local Price Relaying via OpenADR 3.0

  • Develop the capability to relay price signals locally over OpenADR 3.0 for integration with future devices (note: these devices are not part of the current project demonstration).

Functional Control of Connected Devices

  • Utilize received price signals to determine the operational control of three connected devices.

 

, , , , 0 comments

UD Awarded Dynamic Rates Contract by SCE

In July 2022, the California Public Utilities Commission (CPUC) filed an Order Instituting Rulemaking (OIR) aimed at advancing demand flexibility through electric rates. This rulemaking initiative, largely inspired by the results of the successful UD/TeMix RATES project, led Southern California Edison (SCE) to award a contract to Universal Devices (UD) to demonstrate the optimization of off-the-shelf devices using dynamic pricing.

This project leverages a subscription-based model with hourly energy prices, designed to test the ability of smart devices to automatically shift electricity usage to times when energy is both less costly and has lower emissions. By aligning energy usage with optimal times, the program aims to improve the reliability of the power grid and offer cost savings to customers.

California is considering this pilot program as a tool to accelerate the transition to clean, carbon-free energy, enhance the power grid’s reliability, and lower the overall cost of electricity. This effort underscores the state’s commitment to sustainable energy solutions that benefit both consumers and the environment.

 

1 2 3