Cloud API vs local gateway for energy sites

An inverter, an EV charger or a heat pump that already reports to its manufacturer gives you two routes to its data. You can call the manufacturer's API, or you can read the device on site over Modbus or another local interface. The sub-meters beside it usually have no cloud connection, so for them a local gateway is the only route. Make the decision for each device, not for the whole site.

Some third-party APIs aggregate the clouds of several manufacturers. They save integration work, but they put a second provider, with its own interval and quota, between you and the data.

Side by side

When a cloud API fits

A cloud API is the quicker route when the equipment is already online and the job is reporting. The call quota then decides how fresh the data can be. Enphase's Enlighten API v4 allows 10 calls a minute and 1,000 a month on its free Watt plan, 50,000 a month on Kilowatt and 300,000 on Megawatt (Enphase developer plans). One call per system every 15 minutes is 96 calls a day, or about 2,900 a month. The free plan cannot sustain that for one system. Forty systems need about 117,000 calls a month, which is above the Kilowatt limit.

The same 40 systems need only 40 calls a day if the integration collects each day's intervals once, overnight, from an endpoint that returns a whole day per call. A monthly portfolio report works well that way. A dashboard that must show the last hour does not.

Test these points with a real account and a real device, not with the examples in the documentation:

• the interval that the API actually returns for your devices, and the quota on your plan;
• how far back the history goes, and whether missed intervals appear later;
• whether each timestamp is measurement time or upload time, and in which time zone;
• how the API shows an offline device: a gap, a repeated last value or a zero;
• who owns the account, and how access moves when the site or the asset is sold;
• how much notice the provider gives before it retires an endpoint.

The last point is a real risk. On 20 February 2026 Enphase announced that nine endpoints would be retired on 16 March 2026, 24 days later. After that date, calls to them return HTTP 401 (Enphase deprecation notice).

When a local gateway fits

A local gateway fits when the devices have local interfaces and no cloud connection. A typical example is a site with 20 Modbus RTU sub-meters on one RS-485 bus, a pulse output on the gas meter and a BACnet/IP building management system. None of these report anywhere. The gateway reads them at an interval that you set, keeps the history on site, and runs automation without a round trip to a server.

Swipe to follow the system

When you read a device yourself, the mapping work is also yours. The frequent errors are at register level: a 32-bit value read with its two words in the wrong order, a scale factor applied twice, or an energy register in Wh that the map declares in kWh. Each one gives a plausible number that is wrong. The Modbus register map guide shows how to check each point against the meter's own display.

The gateway is also equipment that you operate. Give one person the responsibility for its software updates, backups and firewall rules at commissioning. A gateway with no owner does not get updated.

Timestamps and demand intervals

A 15-minute demand charge is calculated from the energy in each interval, so the timestamp decides which interval a reading belongs to. Suppose a device buffers through a three-hour outage at an average of 400 kW, and uploads 1,200 kWh when the link returns at 14:07. If the API or the platform stamps the readings with their upload time, all 1,200 kWh fall into the 14:00 to 14:15 interval. That interval then shows 4,800 kW of demand, twelve times the real value.

The fix is to keep measurement time from the device to the platform. A local poll has a smaller form of the same problem. The gateway stamps a Modbus reading when it polls, so a meter register that updates once a minute can be up to a minute old when it is read. The source time and arrival time guide explains how to specify which time each field carries. The interval demand calculator shows how one wrong interval changes the billed peak.

Hybrid designs

A site often uses both routes. Take a site with a 250 kW PV array whose inverters report to their manufacturer's portal, a main import meter, and six Modbus sub-meters, one of them on the PV feeder. Two rules keep this design correct.

The first rule is one source for each point. For the 15 minutes to 13:00, the PV feeder meter reads 182 kW and the inverter API reports 185 kW. These are two measurements of one flow. If you add both into site generation, the report shows 367 kW from a 250 kW array. Use the feeder meter, because you know its accuracy class, and keep the API value for inverter diagnostics. Do not replace a missing meter value with the API value unless you mark it as substituted.

The second rule is one owner for each writable point. A flexibility platform dispatches the site battery through the manufacturer's API and sets discharge to 0 kW for a charging event. At the same time, a local peak-shaving rule writes 150 kW of discharge when import goes above its limit. Each interface reports success. The set point changes each time either system writes, and its trend shows a saw-tooth. Give the set point to one system. The other system reads it, or asks the owner for a change.

The data quality guide explains how to mark substituted and stale values.

Security and access

The two routes put the trust boundary in different places. With a cloud API, the credential is the asset. Enlighten API v4 uses OAuth 2.0. The system owner approves the application, the access token is valid for one day, and the refresh token for one month (Enphase quick start). If the integration does not refresh within that month, it needs a new approval from the owner. Record whose account each asset is registered to. A site sale or a change of installer can remove your access.

With a gateway, the device on your OT network is the asset. It does not need a port open to the internet, because it connects out to the platform. NIST SP 800-82 Rev. 3, section 5.2.3.1, recommends that you segment OT from IT, permit connections only between adjacent zones, and make outbound rules as strict as inbound rules. For a gateway, this means an allow-list of its actual destinations: the platform's broker or endpoint, the time servers and the update service. A general rule that permits all outbound HTTPS is not an allow-list.

Test an outage

Before you commit a portfolio to either route, interrupt the internet connection at a pilot site under an agreed plan. Disconnect the WAN link, not the gateway's power, because a power cut tests a different failure. Keep the link down for at least two hours. That crosses eight 15-minute demand intervals.

1. During the outage, record what continues on site: readings, local history, dashboards and automation.
2. Record how the platform shows the missing period: a gap, a stale value held flat, or zeros. Zeros are the worst result, because they look like real readings.
3. Restore the link and count what arrives. Fifty points at a 1-minute interval over two hours should give 6,000 readings. Fewer means loss. More means duplicates, which the platform must remove. MQTT QoS 1 is at-least-once delivery (MQTT 5.0, section 4.3.2), so duplicates after a reconnect are normal behaviour, not a fault.
4. Check that the backfilled readings keep their measurement times, and that no demand interval shows a spike like the one in the example above.
5. For an API, check whether the provider fills the gap, how long it takes, and whether your integration requests the missing period again.

The test passes when the count is correct, every reading keeps its original timestamp, and the platform never showed the outage as zeros. The commissioning checklist gives a record for the test. The store-and-forward guide shows how to size local storage for the longest outage you plan for.

Reporting and control are different jobs

A reporting integration needs periodic reads. A control integration needs a command life cycle: expiry, local limits, measured feedback and a fallback for when the link fails. A cloud API cannot supply the fallback, because the failed link is the path to the cloud.

An API's success response means that the provider accepted the command. A Modbus write response means that the register was written. Neither means that the asset acted. The BESS command verification guide shows how to prove the response from measurements. The interlock failure matrix shows how to decide what the site does when the command path fails.

Edge on the Gateway

Edge runs on the ZGW-20 Gateway on site. It reads EpiSensor wireless devices, third-party Zigbee and LoRaWAN devices, Modbus and BACnet equipment into one data model, keeps the history locally, and runs dashboards and automation without an internet connection. It can be a complete site system on its own, or send data to your energy platform over MQTT or HTTPS. No EpiSensor cloud service is needed. Edge runs on the ZGW-20 Gateway on site. It reads EpiSensor wireless devices, third-party Zigbee and LoRaWAN devices, Modbus TCP and RTU equipment and BACnet/IP controllers into one inventory. It keeps the history locally and runs dashboards and automation without an internet connection. It sends data on over MQTT or HTTPS, or as files over FTPS, as JSON or CSV. No EpiSensor cloud service is in that path. The Gateway draws 5 W when idle and 15 W at most.

In the outage test, Edge puts failed deliveries into a queue on disk. For the destinations that Edge manages, it checks the queue every minute and resends when the destination is available again. The resent readings keep their original timestamps and do not run local automation again. Two limits affect the count in step 3. A batch that is still in memory when the Gateway loses power can be lost. A batch that the receiver stored before Edge recorded the success can arrive twice.