SPAN Response to Request for Information in Docket #24-FDAS-03 - Potential Flexible Demand Appliance Standards for Low-Voltage Thermostats

Span.IO, Inc. (“SPAN”) appreciates the opportunity to provide feedback to the California Energy Commission on Docket #24-FDAS-03. This is in response to the request for information published on September 27, 2024. SPAN is excited by the opportunity for in-home devices to support flexible demand and we envision a number of behind the meter assets coming together in synchrony to best enable grid-edge flexibility, realize the future opportunity for residential decarbonisation, and the optimal homeowner experience. In these comments, we encourage the CEC to consider broader implications of this docket. We are providing this feedback to expand on how to support demand flexibility beyond thermostats and to set up the future of home energy management systems that will be required for the coming wave of electrification enablement

SPAN is a manufacturer of smart panels for single and multifamily homes. SPAN’s flagship product, the SPAN Panel, is a direct replacement of the traditional electrical panel that adds onboard intelligence (i.e. internet connectivity, machine learning-based algorithms, enhanced safety measures) as well as, monitoring and controls to each of its available circuits. SPAN PowerUp™ (a UL-916 Energy Management System) intelligently shifts loads according to homeowner preference to control energy and real-time power consumption, eliminating the need for upgrades to utility service while also providing ongoing demand flexibility.

Introduction: The CEC should broaden the scope of its investigation beyond low-voltage thermostats

SPAN’s understanding is that the CEC is investigating methods to facilitate shifting the energy loads created by heating, ventilation, and air conditioning (HVAC) systems. The goal of this plan is to manage heating and cooling energy loads in order to lower GHG emissions and utility bills for participating electricity customers, and to support grid reliability. HVAC systems, particularly air conditioning, account for up to 50% of household energy use and 60-70% of peak demand, making them a critical focus for Flexible Demand Appliance Standards (FDAS). Optimizing HVAC for flexible demand can significantly reduce energy consumption during peak times, improving grid stability and lowering costs. Therefore, a FDAS for thermostats and home energy management systems more broadly should be a priority for consideration by the CEC.

Control of HVAC power usage, including the shifting of HVAC energy loads, is a crucial component of the CEC’s Flexible-Demand framework. While the locus of most HVAC control systems at present is the thermostat, that may not (and should not, as we describe below) remain the sole location in the future. Therefore, SPAN recommends that the CEC broaden FDAS requirements to encompass the HVAC system overall, not limit the FDAS specifically to the thermostat component.

The CEC should prioritize customer choice and interoperability in an FDAS

California is in the early stages of HVAC electrification, but the market is rapidly maturing. The rules that the CEC develops today will shape the industry structure for the foreseeable future. The CEC should adopt rules that create a customer-centric industry structure and that enable market competition among providers of both hardware and services.

Our view is that the CEC can achieve this objective by focusing on two themes in any future FDAS:

• Customer choice. A customer should be able to use the device of their choosing to control the HVAC systems in their house. Further, a customer should be able to delegate control of their HVAC systems to a third party (including a utility). As we discuss below, the key to this customer choice is an open communications and control standard that applies to all HVAC systems.
• Interoperability. A customer should be able to use their preferred device to control any HVAC system. Interoperability will allow a customer to switch HVAC systems without changing the day-to-day experience of their home, since they can interact with the system without changing their control device.

If the CEC adopts an FDAS that incorporates customer choice and interoperability, we believe Californians would see clear benefits. First, there would be market competition to build the best control system for customers. Second, more customers would be able to connect their HVAC systems with load control programs. Third, customers would shop for HVAC systems based on heating, ventilation, and air conditioning functionality, as opposed to control systems, which will lead to better HVAC system choices.

The current HVAC market structure is not prioritizing customer choice or interoperability

The HVAC industry has changed dramatically in the last two decades. Historically, HVAC systems were controlled via the 24V thermostat control standard, and innovators were able to build products on top of this standard. Most notably, technology startups (starting with Nest, and including companies like Ecobee) created new thermostats with the right combination of functionality, attractiveness, and price to create significant consumer value. These thermostats also came with associated smartphone apps, delivering further consumer value.

In recent years, the market has changed dramatically. HVAC manufacturers have reacted to the success of third-party thermostats by essentially eliminating the 24V control “standard” from their newest, most energy efficient units - seeking instead a vertically integrated business strategy designed to foster more manufacturer ‘lock-in’ and reduce interoperability and customer choice. A typical new heat-pump, variable-speed HVAC system requires the manufacturer’s proprietary thermostat, usually network-connected (via Wi-Fi), which connects (via the Internet) only to the manufacturer’s cloud, using proprietary protocols not accessible to the purchaser/owner (or other third-party developers), and the owner is not able to choose the app of their preference or connect the system to a unified home energy management system, but rather is forced to use the app the manufacturer provides.

Appendix 2 shows a graphical description of today’s market structures, as well as a desired future market structure.

Customers are benefiting from standardized controls in water heaters

It is instructive to compare the support for standard control interfaces by water heater manufacturers to that by HVAC manufacturers. There is a lot to take away from the successes of the mandated additional controls that were implemented for water heaters. The current state of the HVAC industry (characterized by proprietary thermostats and proprietary protocols) is one future, but the water heater industry shows a very different path forward.

Many water heaters today (and the vast majority in the future) incorporate a CTA-2045/EcoPort control system. The CTA-2045 (also known commercially as “EcoPort”) standard was defined, and then subsequently required by the states of Washington and Oregon. As a result, water heater manufacturers began including this interface on some of their models in 2022. As the cost of a CTA-2045 interface declined to approximately the incremental cost of supporting different SKUs for different states, water heater manufacturers began incorporating this interface into more and more of their models - it was simpler and less expensive to simply include it in all models than to manage different models/SKUs for different markets.

Simultaneously, third-parties developed Universal Communications Modules (UCMs) to enable CTA-2045 demand-response commands to be communicated either on the home LAN or to cloud servers over the Internet, and demand response providers (including utilities) began offering financial incentives for end-user adoption and participation.

None of that would have occurred without the mandate by Washington and Oregon to require a standard control interface on water heaters.¹ Contrast this state of affairs to HVAC systems: no such control standard is required, and as a result, existing HVAC systems do not provide/support a standard control interface protocol.

Limiting demand flexibility to thermostats will not maximize customer benefits

Today’s most advanced thermostats typically offer four sets of features: HVAC control, environmental sensing, display of HVAC status and ambient temperature, and a user input interface. These are critical features that modern thermostats deliver incredibly well. But, there’s no reason that these features must be combined in one device at one arbitrary location inside a home. Indeed, with advances in networking, internet-of-things sensors, and smartphones and tablets, bundling all of these features together makes little sense.

Consider these three examples:

• Location of environmental sensors. With the advent of small, low-cost, and wireless/network-connected temperature sensors, there is no reason for there to be a single temperature sensor in a single thermostat at one location; instead, there can be a temperature sensor in every room in a house. In fact, one can imagine integrating a temperature sensor into the smoke-detector (which is required for most rooms). These temperature sensors could communicate with the HVAC controller via the home’s LAN, using wireless networking (such as Wi-Fi or Thread) when wired networking is not feasible. (This is already starting to happen: the Nest Gen4 thermostat product includes an auxiliary sensor to be placed elsewhere from the thermostat, and additional sensors are available for purchase from Nest.)
• Location of HVAC controller. When environmental sensing is disaggregated from the thermostat, there is no need for the HVAC controller to reside in the “thermostat” instead of being integrated into the air-handler itself. Focusing on the HVAC system instead of the thermostat will create more options for control, and more customer choice in their control preferences.
• HVAC status and user input interface. With HVAC apps on tablets, smartphones, and smart home displays, the need for a HVAC specific, separate wall-mounted thermostat with LCD display is rapidly diminishing and soon it will become merely a consumer preference. Instead, customers can open their smartphone or tablet wherever they are, without walking to an arbitrary location and interacting with a different device (which will almost certainly be less-sophisticated than the consumer’s smartphone or tablet).

These examples show that what customers really need is a set of HVAC features that operate with a common standard, not simply a thermostat. At SPAN, we believe the best path to realize these innovations in HVAC control is to mandate open (and ideally standard) protocols for HVAC systems, including the following functions:

• Environmental sensor communication
• System status reporting
• Setting of user preferences
• Reception of dynamic prices, demand-response requests, and grid management events
• HVAC control

This point is reinforced if one narrowly considers just the 24V standard. This standard is not capable of supporting the control of modern variable-speed systems, so a new control interface is required. As discussed above, HVAC manufacturers have responded by building proprietary thermostats, which has limited customer choice and interoperability.

Appendix 3 includes further description of HVAC system components and capabilities. We encourage the CEC to review this appendix to understand the wide variety of components and capabilities that are relevant to a consumer, and the limitations of focusing just on the thermostat.

Open standards enforced via regulation will deliver customer benefits

In order to enable the innovation and rapid-development of flexible-demand HVAC-controllers, it is crucial for the CEC to mandate that HVAC systems support open (and ideally standard) control APIs/protocols. A regulatory requirement that all HVAC systems must include open interfaces and protocols to deliver the five features described above would motivate the HVAC industry to transition to FDAS-supporting HVAC systems. SPAN would support the CEC issuing such a regulatory requirement.

Key components of an HVAC FDAS

SPAN understands that Docket #24-FDAS-03 is limited to low-voltage thermostats. However, since we do not see an open docket related to broader HVAC standards, we are providing feedback here about what could go into either an expanded thermostat docket or an FDAS targeting HVAC systems holistically.

1. An HVAC FDAS should support, but not require, aggregators

Virtually all existing demand response programs are implemented through “aggregators”, variously known as demand response providers, automation service providers, or virtual power plants. We recognize that aggregators can play an important role in orchestrating demand flexibility programs, and propose that any HVAC FDAS fully support the aggregator role. But, the HVAC FDAS should in no way require an aggregator, so that utility customers can subscribe, connect, and participate in demand flexibility programs directly and individually, by configuring their flexible-demand appliances to communicate directly with price-servers (hosted either by the Load-Serving Entity (LSE) or the CEC). Ultimately it should be the customer’s choice to participate in demand flexibility programs via an aggregator, or via direct connection to the LSE or CEC price-server. Any HVAC FDAS should support both implementation models, LSE-to-Customer, and LSE-to-Aggregator-to-Customer.

While aggregators and cloud-based services can provide numerous benefits, it is important to realize that there are “costs” and downsides to their use, including:

• Reliability and Availability: Flexible-demand appliances need to operate reliably in the event of grid and/or Internet outages (and Internet outages are more likely during grid outages). With the proliferation of energy storage devices (e.g. Battery ESSs, and Vehicle to Home EVs and chargers) many utility customers’ homes will continue to operate during grid-interruptions, and power and energy control will be even more important when operating under battery power. If power and energy management are cloud-based, they are less likely to be available at these critical times.
• Cost: Cloud applications incur substantial costs for cloud-hosting, staff to operate, monitor, and maintain the service, etc. Someone has to pay these costs, almost certainly the utility-customer, either indirectly (the aggregator takes a percentage of the savings or incentives provided by the LSE), directly via a service subscription fee, or indirectly via the sale of the customer’s usage data to other parties.
• Privacy and Security: Utility-customer usage data (both real-time,and historic) may have significant privacy implications, especially as usage data becomes more granular and specific (e.g., which appliance, in which room, at what time). Some utility customers may not want their flexible-demand appliances sending this data to a cloud-application.

1. An HVAC FDAS should support local control

The ability to control flexible-demand appliances locally, via the home’s LAN, is an important requirement that a HVAC FDAS should support. Considerations include:

• Cost: Local control incurs none of the additional costs required by cloud-based solutions
• Privacy: FDAS state/status has significant privacy implications and some customers may choose to keep this information within the home.
• Reliability: Local communication and control will be more reliable during Internet interruptions and grid outages, especially if the home has energy storage via a BESS and/or V2H-EVSE
• Unified management: A customer may possess multiple flexible-demand appliances, and chooses to manage and control them in a unified holistic manner, via a Home Energy Management System (HEMS)
• Dynamic Power Control: The NEC-705.13 & UL-3141 Power Control Systems (PCS/EMS) standards enable support of large loads within the home, without costly service upgrades. PCS systems can be more effective and provide better customer experience when flexible-demand loads can be incorporated into the power management process, which requires low-latency local communication.

1. A HVAC FDAS should require open protocols

Flexible-Demand HVAC systems should be required to support freely-available, openly-specified protocols to enable:

• Environmental-sensor communication
• System status reporting
• Setting of user preferences
• Reception of dynamic prices, demand-response requests, and grid management events

1. A HVAC FDAS should require the Flexible-Demand-Server be user-configurable

Flexible-Demand HVAC systems will need to connect to a “Flexible-Demand-Server” (which will need to be created) in order to receive dynamic prices, demand response requests, and grid management events, and the Flexible-Demand-Server must be configurable by the utility customer. HVAC system manufacturers are free to configure a default server for their products, but the consumer must be provided a straightforward (and ideally automatable) procedure to configure the server address (URL) to whatever they choose.

Appendix 4 includes further discussion of how HVAC systems and other DERs should communicate with a Flexible-Demand-Server.

Proposed requirements for an HVAC FDAS

We propose that any future HVAC FDAS should incorporate the following requirements in order to deliver the greatest possible customer benefits:

• The HVAC-System MUST provide an Ethernet network interface, and optionally, MAY provide a Wi-Fi network interface
• The HVAC system MUST support a freely-available, openly-specified, IP-network-based protocol to enable:
  • Environmental-sensor communication
  • System status reporting
  • Setting of user’s preferences, including operating mode, and set-points.
• The HVAC system MUST support a freely-available, openly-specified IP-network-based protocol to enable reception of dynamic prices, demand-response requests, and grid management events
• The server address/URL of these protocols (if any) MUST be user-configurable
• The protocols MUST support both local and aggregator use-cases, and MUST NOT require an aggregator
• The CEC’s protocol requirements MUST be functional, and performance-based, not limited to a fixed, static version of a particular standard. Technological progress and innovation will occur at a much faster pace than the regulatory process, and defining performance-based capabilities for FDAS will achieve the CEC’s goals in the most effective manner possible.

SPAN’s responses to the questions in the September 27, 2024, Request for Information

We’re thankful for the opportunity to respond to specific questions, in addition to providing the feedback above. In order to make these comments as clear and comprehensible as possible, we are providing these responses in Appendix 1.

Conclusion

The actions that CEC takes today will shape the shape of California’s electrification industry well into the future. As the states of Oregon and Washington have demonstrated with water heaters, state regulation can rapidly shape entire segments of the industry. In these comments, we have described why the appropriate scope for the CEC to consider is the HVAC system, not just the thermostat. Indeed, the thermostat itself may be seen as an archaic anachronism in the near future, while electric heating and cooling will be in California homes for as long as those homes stand.

These comments also provide the foundation for a future HVAC FDAS rulemaking. We propose that the CEC should mandate that HVAC systems include open standards for their five key features, so that innovators can deliver solutions that best serve customers.

Finally, we encourage the CEC to keep the values of customer choice and interoperability front of mind. When considering thermostats, HVAC systems, or all appliances and distributed energy resources, the CEC will be well-served to prioritize outcomes that support customer choice and interoperability.

We look forward to continued collaboration to support California’s electrification efforts.

Appendix 1. SPAN’s response to questions from the September 27, 2024, Request for Information

1. Staff is considering the appliances in Table 1 as a baseline for the low-voltage thermostat rulemaking scope. Are there additional examples that might be considered in-scope or out-of-scope?

   HVAC systems controlled by line-voltage thermostats/controllers are also high-load appliances, and SPAN recommends that these systems be included/in-scope for this FDAS effort.

2. Staff is considering the low-voltage thermostat market share from 2019 California Residential Appliance Saturation Study (RASS) in Table 2 as a baseline for the low-voltage thermostat scope. Are there additional data sources that might be considered?

   SPAN has no recommendation regarding additional data sources for thermostat market share at this time.

3. Staff is considering using hourly HVAC energy use estimates from the Hourly Electric Load Model (HELM). What other HVAC load-shape data sources are currently available?

   SPAN has no recommendation regarding additional HVAC load-shape data sources at this time.

4. Staff assumes a 10-year lifetime for a low-voltage thermostat. Are there alternative assumptions for product lifetime that staff should consider? Please reference the sources of those alternative assumptions.

   SPAN concurs that a 10-year product lifetime is reasonable.

5. Staff has identified a range of typical flexible demand functions associated with low-voltage thermostats. Staff may consider using Joint Appendix JA5 Technical Specifications For Occupant Controlled Smart Thermostats as a baseline standard for functions in low-voltage thermostats. Provide a current market share and likely incremental cost of including the following capabilities:
   a. Bi-directional communications.
   b. Hourly scheduling capability.
   c. Device software optimization for GHG.
   d. Device software optimization for hourly electricity pricing rates.
   e. Cybersecurity.

   SPAN believes that hardware/BOM cost of adding the listed capabilities to a smart/network-connected thermostat is zero or negligible.

6. Staff estimates the total incremental cost to consumers (the difference in purchase price between a flexible-demand low-voltage thermostat and a non-flexible-demand low-voltage thermostat) to be $25. Staff is seeking input on whether this estimate is reasonable.

   SPAN believes that hardware/BOM cost of adding flexible-demand to a smart/network-connected thermostat is zero or negligible.

7. Staff may consider using Title 20, California Code of Regulations, Section 1692(c) General Requirements as a baseline standard for cybersecurity in low-voltage thermostats. Are there any additional cybersecurity requirements to be considered?

   SPAN supports the Section 1692(c) General Requirements as a cybersecurity standard.

8. Provide information on any demand response programs currently used in California or other locations for HVAC loads that use the thermostat for load control, including the following.
   a. How many low-voltage thermostats are used in these demand response programs?
   b. How much energy load in kW is each low-voltage thermostat shifting?
   c. What is the time shift duration?
   d. What are the participation rates with an opt-in and opt-out framework?

   SPAN has no relevant data at this time.

9. Is there anything like a common communications protocol or platform with significant market share, and/or which could facilitate aggregation of HVAC systems via thermostatic controls? Please feel free to describe alternatives to ensuring effective and reliable communications with targeted aggregations of (customer-consented) HVAC loads.

   Note that SPAN proposes that the aggregation role not be a requirement for utility-customer participation in flexible-demand programs, as discussed above.
   That being said, SPAN believes that existing (and future) aggregators could implement/offer standard protocols to receive dynamic-pricing, demand-response program requests, and grid management events from CEC/LSE price-servers.

   OpenADR 3 (and especially v3.1, in process) provides a standard protocol for delivering dynamic prices, demand-response requests from LSEs (and/or the CEC) to HVAC systems and thermostats, and also supports the same functionality locally on the home’s LAN. OpenADR 3 was first published in late 2023, and the first implementations were certified in Q3 2024, so there are no existing HVAC systems/thermostats that support it.

10. Please discuss strategies for low-voltage thermostats to best utilize the CEC’s Market Informed Demand Automation Server (MIDAS), which provides access to utilities’ time-varying rates, GHG emission signals, and California Independent System Operator (California ISO) Flex Alerts

    The MIDAS service protocol, and the RIN, are not standards. This is highly problematic as it reduces the likelihood of it being implemented by FDAS device manufacturers or other jurisdictions.

    The MIDAS service protocol is not (currently) used by other jurisdictions, nor does that seem likely.

    The MIDAS server protocol doesn’t support client subscription to prices and events with “push” notifications of new prices and events, so that clients must continuously query MIDAS for new messages. Enhancing the MIDAS service with a publish/subscribe protocol (examples include MQTT and/or Kafka) should be straightforward.

    SPAN recommends that the CEC’s FDAS standards support price-servers by LSEs, and if the CEC continues to advocate for the use of MIDAS, that MIDAS be revised to support a standard protocol, with OpenADR 3.1 being the most suitable candidate today.

    Please refer to Appendix 2 “SPAN’s Proposed Communications Requirements for Flexible-Demand Price-Servers, Appliances, and DERs” for additional background and context regarding SPAN’s recommendations regarding MIDAS and price-server-protocols.

11. What percentage of low-voltage thermostats sold in California have an ability to respond to data originated from MIDAS to alter the HVAC operating schedule? Describe whether low-voltage thermostats can respond to MIDAS’s price, GHG, or Flex Alert

    Existing smart thermostats with proprietary connections (via the Internet) to the manufacturer’s cloud (and then possibly connected cloud-to-cloud to an aggregator) could respond to MIDAS or standard protocols (like OpenADR 3) if the manufacturer’s or aggregator’s cloud were augmented to support the MIDAS and/or OpenADR protocols

Appendix 2

The following diagram details the existing HVAC control connections for various HVAC system types, and shows how these connections would change with a transition to a standard IP-network based control protocol.

Appendix 3. HVAC System Overview

System Components

Conceptually, most centralized ducted and minisplit HVAC systems consist of the following functions which are performed by the listed components

• Air-Movement: Air-Handler
• Heat-Source/Pump: Heat-Pump(heating/cooling), Furnace(heating), Air-Conditioner(cooling)
• User-Interface: Typically provided by the thermostat, and/or a smartphone app
• Environmental-Sensing: Typically integrated into the thermostat
• System-Controller: Typically integrated into the thermostat

HVAC System Types

There are three types of central ducted HVAC system:

• Single-Stage: the heat-source and air-handler operate at either 100% or 0% of capacity
• Dual-Stage: the heat-source and air-handler operate at 100%, 65% (approximately), or 0% of capacity
• Variable-Speed: operate at whatever capacity is necessary to accomplish the current mode/set-point, using the lowest possible power to do so.

Another important distinction is the number of distinct zones supported by the HVAC system:

• Single-Zone: The entire structure’s temperature is controlled by a single thermostat/controller
• Multi-Zone: The structure is segmented by region (typically floors), and each zone may be controlled separately. Multi-zone systems typically require variable-speed operation

Mini-Split HVAC systems are similar to centralized ducted systems, but they use separate air movement equipment for each zone and typically share one electrical circuit between the heat source and air-movement devices.

HVAC Control

As noted above, the system-controller function for most HVAC systems has traditionally been incorporated into, and performed by, the thermostat. 90% of all home heating systems are thermostat controlled according to 2020 RECS. Other functions historically provided by, or integrated into, the thermostat include environmental-sensing, the user-interface functions, for example: mode, set-point, schedule, and display of HVAC status and ambient temperature.

Thermostat Types

• Non-programmable/Manual (40% of thermostats)
• Programmable (48% of thermostats)
• Smart/Network-Connected (12% of thermostats)

Thermostat Functionality by Type

Manual, Single-stage Thermostats Provide:

• Heat-Source/Pump selection: Off/On, or Off/Heat/Cool
• Fan-Mode selection: On/Auto
• Temperature-Sensing: Display of the current ambient temperature at the thermostat
• Selection and display of the current set-point

Programmable Thermostats Provide:

• All the same functions as a manual thermostat
• User-configurable scheduling of modes and setpoints

Smart/Network-Connected Thermostats Provide:

• All the same functions of programmable and manual thermostats
• Graphical display and user-interface via LCD displays and touch input
• A network interface (typically Wi-Fi) for connection to the home’s LAN, primarily in order to connect to the thermostat manufacturer’s cloud, via the Internet
• A smartphone app for display and interaction with the thermostat, either locally or remotely. Typically the smartphone-app’s connection to the thermostat is via the thermostat-manufacturer’s cloud (over the Internet), and not via direct communication between the app/phone and the thermostat over the home’s LAN

#

Appendix 4. SPAN’s Proposed Communications Requirements for Flexible-Demand Price-Servers, Appliances, and DERs

Flexible-Demand System Overview

The CPUC/CEC depicts the Flexible-Demand system architecture as follows:

We note the following (relevant to our proposed requirements)

• There may be multiple smart-appliances and DERs within the home
• The home’s smart-appliances and DERs are orchestrated by a “Home Energy Management System” (HEMS)
• The HEMS function may reside with the home itself, or in the cloud via a Third Party Service Provider (TSP); the HEMS can be a dedicated device or a function implemented by a device with some other primary purpose (e.g. Wi-Fi access point, Amazon Echo)
• Price-Server/home communication is via the Internet, using a Demand-Response-Protocol
• The HEMS receives prices and grid/utility events (e.g. FlexAlerts, PSPS, Demand-Response requests) from a (cloud-based) Price-Server. The HEMS controls smart-appliances and DERS in the home based on:
  • Price and Grid/Utility events
  • Current power consumption needs, and DER generation status/capacity within home
  • Customer preference and prioritization
• The HEMS communicates over the building LAN to the home’s smart-appliances and DERs, to obtain status and issue functional commands
• For clarity, the diagram above depicts a single-family home as the target of energy management, but multi-family residences and commercial buildings are equally applicable. Hereafter, the use of “home” in this document is intended to apply all of these structure types.
• This document will use the word “customer” to refer to the occupant(s) of the structure, in particular the person/persons that manage the structure’s utility service, and that have the authority and responsibility to configure and manage the smart-appliances and DERs within.
• We interpret Third-Party Service Providers (TSPs) to include Aggregators, Demand Response Providers (DRPs), and Automation Service Providers (ASPs), and our use of TSP hereafter is intended to reference/include all of those energy system participants

Proposed Requirements

Smart-Appliances and DERs

• MUST be capable of being connected to an IP network, and once connected, to provide operational status to, and receive and respond to functional commands from, other networked entities. The standard CTA-2045 connector provides the capability for an IP network connection, but only if an additional Universal-Communications-Module (UCM) is added/attached. In practice, the cost, and logistics around adding a UCM acquisition and installing will limit the scale of CTA-2045 based programs.
• SHOULD support/include one or ideally more IP network interfaces, e.g. Wi-Fi and Ethernet. If WiFI/Ethernet are infeasible for the appliance type, a lower-power wireless connectivity that supports routing to an IP network (e.g. Thread) may be substituted. Many device manufacturers integrate a Wi-Fi interface, but do not also provide a wired Ethernet interface, and then bemoan the frequency of networked device network disconnection due to Wi-Fi password changes. Devices SHOULD provide hardwired Ethernet interfaces when feasible.
• MUST support a freely-available, openly-specified protocol for reporting status (including current operating mode/state) and receiving functional commands, hereinafter referred to as the Device-Protocol.
• SHOULD use a modern, widely-supported open standard for its Device-Protocol. Examples include Matter and possibly OpenADR 3.
• Device-Protocol specifications SHOULD include formal, machine-readable definitions using OpenAPI and AsyncAPI (as appropriate)
• MUST support local communication with the home’s IP network, and MUST NOT require communication via a cloud-server. Note that communication with a cloud-server is not precluded, only that it must not be required, and cloud-communication MUST be capable of being disabled by the customer. Further note that because device <-> cloud communications are most likely to fail during grid outages and power events, the use of local communications increases reliability
• MUST support customer configuration of the HEMS and/or Price-Server, and MUST NOT require the use of a specific HEMS, Price-Server, or TSP
• The Device-Protocol SHOULD support publish-subscribe operations, to enable continuous reception of smart-device/DER status (e.g current operating mode, and power usage), so that interested network entities can receive the real-time status of a device without constantly requesting status reports.
• SHOULD advertise/broadcast their existence and capabilities on the home IP network, and listen for the advertisements of other network entities using standard Multicast DNS (mDNS) and DNS Service Discovery (DNS-SD) protocols in order to facilitate discoverability, configuration, and coordination.
• MUST be able to connect directly to a Price-Server, when no centralized HEMS function is provided (either within the home, or via a cloud-based TSP). Thus the device must support the Demand-Response-Protocol, which is used when no HEMS is configured.

Price-Server

• Price-Server MUST support direct connection from customer, as configured by the customer
• Price-Server MUST NOT require connection via TSP (ASP, DRP, Aggregator)
• Price-Server SHOULD support (at the customer’s option) customer connection via TSP

Demand-Response-Protocol

• MUST be freely-available and openly-specified.
• Documentation SHOULD include formal, machine-readable specifications. Examples include OpenAPI and AsyncAPI.
• SHOULD be a widely-supported open standard, OpenADR 3 being one possible candidate
• MUST be easily usable/adaptable by other jurisdictions (states). It is not feasible or cost-effective for Smart-Appliance/DER manufacturers to provide different Demand-Response-Protocol implementations for each jurisdiction. Note that we do not suggest seeking agreement/consensus with other jurisdictions regarding the protocol, but simply to enable the protocol to be usable by other jurisdictions (if they so choose), by providing their own Price-Servers incorporating the Protocol, customers in those jurisdictions would then configure the applicable Price-Server for their locale.
• MUST support publish/subscribe functionality to enable the Price-Server to “push” prices and events, without need for continuous/repeated requests for new prices/events. The protocol specified for push of subscribed events from the Price-Server to the home MUST be easily capable of use by customers employing common Internet connections that by default prohibit direct inbound connections from the cloud/Internet. Protocols like MQTT and Kafka provide a common solution to this requirement. Note that OpenADR 3.1.0 (in progress) defines/enables the use of the MQTT protocol for push notifications for exactly this reason.

Home Energy Management System (HEMS) Function

• MAY reside within the home on the home’s network, OR MAY be provided in the cloud by a TSP
• The choice of HEMS (including type: local or via TSP) MUST reside with the customer.
• MUST be configured with the Price-Server URL, the home’s electric utility provider, and the electric service rate/tariff (identifiers) applicable to the home.
• MUST connect with the Price-Server on behalf of the customer, communicating via the Price-Server-Protocol.
• Communicates with Smart-Appliances and DERs within the home, using each device’s Device-Protocol. Note that the number of different/distinct Device-Protocols used within the home increases the complexity and cost of the HEMS, thus the use of industry standard Device-Protocols is highly desirable.
• A home-located HEMS SHOULD advertise its existence on the home network via mDNS, and Smart-Appliances and DERs SHOULD listen for these broadcasts, in order to facilitate the configuration by the customer.

Discussion

CEC’s Market Informed Demand Automation Server (MIDAS) as a Price-Server

The current MIDAS server is an innovative prototype/proof-of-concept of a Price-Server.

Notable attributes include:

• The MIDAS service is freely accessible on the Internet, and supports direct connections by customers
• The MIDAS service protocol is publicly specified, utilizes modern API methodologies (e.g. REST, JSON), and source code examples are provided for several popular programming languages

Limitations of the current MIDAS system include:

• Rate Information Number (RIN)
  • The ability of a typical customer to obtain/determine the MIDAS (RIN) representing the applicable rate/tariff is not simple and straightforward.
  • A customer’s rate/tariff should be represented as a single RIN, we understand that at present, some customers must use two (or more?) RINs.
  • The RIN alone is not sufficient for the customer to connect directly to MIDAS; the URL of the MIDAS service, and a MIDAS username/password (needed to obtain a MIDAS protocol access token) are both also required.
  • What customers need is the complete Price-Server configuration data, which includes the URL of the Price-Server, the unique identifier for the customer’s applicable rate/tariff, and the customer’s Price-Server authentication credentials, provided as a “Connection-URI” that encodes all of the information required to connect to a service within a single string.
• The MIDAS server protocol doesn’t support client subscription to prices and events with “push” notifications of new prices and events, so that clients must continuously query MIDAS for new messages. Enhancing the MIDAS service with a publish/subscribe protocol (examples include MQTT and/or Kafka) should be straightforward.
• The MIDAS service protocol is not (currently) used by other jurisdictions, nor does that seem likely
• The MIDAS service protocol, and the RIN, are not standards. This is highly problematic as it reduces the likelihood of it being implemented by manufacturers or other jurisdictions.
• The MIDAS protocol and “data model” should be reviewed for its applicability to the needs of other jurisdictions, and any “California specific” terminology generalized. For example FlexAlert is a CAISO-ism, and might be rephrased as “Alert”.

Should the Price-Server be hosted by the CEC, or should each load serving entity (LSE) host their own Price-Server?

Possible considerations include:

• Both options (LSE-hosted, CEC-hosted) should be supported, but we expect that most customers will use the LSE’s Price-Server.
• As the Price-Server becomes an important and critical component in the electric grid, its scope, scale, and reliability requirements will increase, and its ongoing development and operational support may become burdensome for the CEC
• The aforementioned observation regarding the difficulty for a utility customer to obtain the RIN (or RIN-equivalent) might more easily be solved if the utility provided the Price-Server to its customers, the utility:
  • Has a formal billing relationship with the customer
  • Website already provides authenticated account access to the customer
  • Clearly has the specifics and details of the customer’s rate/tariff, and is best suited to be able to provide the customer’s RIN (or equivalent)