Device integration & gateways: from register map to gateway application

The integration problem

A commercial solar + storage site rarely comes from a single supplier. A typical installation combines a power conversion system (PCS) or several inverters, battery systems, meters and a handful of discrete signals such as breaker status. Each device has its own register layout, scaling conventions, data types and firmware history. Two inverters doing the same job may report active power at different addresses, in different units, with different sign conventions.

The gateway sits in the middle. Downward, it must read and command every device reliably. Upward, it must give the owner's SCADA or energy management system (EMS) one consistent view of the site. In between, it runs the control logic that makes the devices behave as a site. Doing this well is mostly a matter of handling that variety without letting it turn into custom code.

Four operating realities shape the design:

• Devices change during a project. Equipment substitutions, firmware updates and late design changes are normal. If every change needs a firmware rebuild, routine variation becomes a release cycle.
• Commissioning happens on site, often done by technicians rather than software engineers, and often on a schedule driven by an interconnection date.
• Field buses are slow and shared. A serial line with several devices on it has a fixed transaction budget, and many devices only tolerate modest request rates.
• Hardware is scarce during development. A PCS, a battery string and a PV array do not fit on a desk, and live high-power equipment is the wrong place to find control-logic bugs.

125

registers per Modbus read request, the upper bound ByteHive uses when it coalesces reads

1, 17, 701–715, 802

SunSpec models with maps included: Common (1), Serial interface (17), DER models 701–715 for PCS / inverters, and Battery (802)

10

waveform behaviours in the generic register-map simulator, for building against devices you do not have yet

5 + 1

five commands and one tap to a simulated site where a power setpoint visibly works

Register maps: configuration, not code

In ByteHive, a device is described by a register map. The map says which registers to read and write, what type each one holds, and how often to poll it. The map is configuration. The edge runtime turns it into named, typed live values in its data model and handles the transactions on the wire. A new device type needs no new driver code.

• Variety stays in data. A second inverter model is a second map, not a second driver. Maps can be reviewed, versioned and compared like any other project file.
• Instances are cheap. One map serves any number of identical devices, and each instance keeps its own live values.
• Everything downstream is insulated. Control logic, the web UI and the cloud work with named, typed values, not raw register addresses. When a device is swapped for a different model, the change is made in configuration, not in firmware. ByteHive Cloud does not need a schema change for new device types either.

The trade-off is real: someone still has to build an accurate map from the vendor's documentation, and a wrong register entry is still wrong. But the work becomes a configuration task you can review, and fixing a mistake does not require a firmware release.

Modbus in the three roles a site needs

Modbus remains the common denominator for energy equipment. ByteHive ships it in three roles.

The two client roles cover the downward side. Support for several RTU devices per serial port matters in practice. Meters and auxiliary equipment are often daisy-chained on one serial line, and a gateway that needs one port per device puts extra hardware and wiring in the cabinet.

The server role covers the upward side. The SCADA or EMS integrator does not have to talk to each device separately: the gateway exposes the values you map through one Modbus TCP endpoint. The owner gets a single integration point, and device-specific quirks stay behind the gateway.

Polling that respects the bus

Modbus has no way for a device to report a change on its own. The gateway has to ask, and every request costs time on the wire and load on the device. ByteHive has two features for spending that budget well.

Per-block polling rates

A register map groups registers into blocks, and each block has its own polling rate. Fast-moving values the control logic depends on, such as active power or a setpoint readback, might be polled every 500 ms. Slow values, such as cumulative energy or nameplate data, might be polled every 3 s or less often. Polling everything fast wastes bus capacity; polling everything slowly makes the control loop sluggish. Per-block rates let one device have both.

Coalesced reads

ByteHive coalesces reads into requests of up to 125 registers. Fewer, larger requests mean less per-transaction overhead. The gain is biggest on serial lines, where the bus is shared and every transaction adds a fixed turnaround cost.

Polling changes take effect live, so rates can be tuned during commissioning without restarting the stack.

SunSpec model maps included

SunSpec defines common register models for inverters and storage. ByteHive includes maps for the Common (1) and Serial interface (17) models, the DER models 701–715 used by PCS / inverters, and the Battery model (802). For equipment that implements these models, integration starts from an included map instead of a blank page.

The included maps also serve as worked examples for devices that expose vendor-specific registers alongside SunSpec models, or instead of them.

Devices implement different subsets of the models. Treat an included map as a starting point to check against the actual unit during commissioning, not as a reason to skip that check.

On-board I/O, reconfigured live

Not every signal on a site comes over Modbus. Breaker auxiliary contacts, contactor commands, cabinet temperature and similar signals are wired directly to the gateway. ByteHive supports on-board GPIO, analog inputs and SPI, and presents them in the same live data model as device registers. Control logic does not need to know whether a value came from a battery over Ethernet or from a contact on a GPIO pin.

I/O configuration can be changed live, without restarting the stack, so correcting a mis-assigned input does not require a restart.

One engineering note: safety functions that must work independently of software, such as an emergency-stop circuit, should stay hardwired. The gateway's role is to monitor them, report them and respond to them.

Commissioning from the web UI

Commissioning is where an integration design meets reality: IP addresses, serial settings, unit IDs, and the occasional device that does not quite match its datasheet. With ByteHive, devices are commissioned from the gateway's web UI. The JSON web API exposes commissioning as well, alongside variables, devices, faults, history and users, so a product team can build its own commissioning flow or script bulk setup.

The person on site is usually a technician with a laptop, not a developer with a toolchain. Commissioning in a browser over HTTPS, with Admin, User and Viewer roles, means site setup needs neither shell access nor a software build.

From devices to a site

Operators and EMS platforms think in site terms: total PV output, average battery state of charge, the hottest cabinet, the lowest available capacity. ByteHive's control logic includes aggregates across devices, with SUM, AVG, MIN and MAX computed across every online device.

• Online devices only. Aggregates count only devices that are currently online, so a battery that drops off the network does not silently pull an average toward zero. The flip side is that a site total falls when a device goes offline. That is why communication status and device faults belong in the same control logic as the aggregates.
• Available without C. Aggregates are available in the built-in scripting engine and can be bound on the visual canvas of ByteHive Studio (developer preview). Scripts are fully checked before anything runs, and behaviour changes by swapping a script, not by rebuilding firmware.

Combined with PID control with anti-windup, low-pass filters, time-of-day logic and event-driven state machines, aggregates are the building blocks for site behaviour such as spreading a site power setpoint across several PCS units. That logic is your application; ByteHive is the platform underneath it.

Developing without hardware

Control logic should meet its first bugs on a development machine, not in a live cabinet. ByteHive ships simulators for the device types that dominate solar + storage sites.

The sample gateway app, which contains no C code, adds simulated devices with one tap. A whole-site simulation then models solar, load and battery dispatch (simulation only; the sample app does not include a site-wide dispatch strategy). Five commands and one tap produce a simulated site where a power setpoint visibly works. Development and hardware-free simulation run on x86_64 Linux, which is also a supported target. On ARM64, a production appliance image ships for Cortex-A76 class SBCs and a binary package for Cortex-A53 class SBCs.

The sample gateway app: CSS Gateway

CSS Gateway is the sample solar + storage gateway application that comes with the SDK, delivered as source. It shows the integration layer assembled into an application:

• a device commissioning wizard and per-device controls for setpoints;
• a live dashboard with site KPIs and animated power flow;
• faults and events with severity, acknowledgement and daily logs;
• Modbus TCP upstream for SCADA and EMS;
• telemetry to ByteHive Cloud, signed over-the-air updates and Wi-Fi setup.

Underneath, it inherits the platform's operating features, including a self-healing watchdog that restarts the stack about 5 s after a core service fails. Its updates are signed and delivered over the air, and install only with the site owner's approval.

It is a starting point, not a finished product: it has been run only with simulators and has not been tested with any real equipment. Re-skin it (logo, palette, product name), extend it for your equipment, and qualify it with that equipment before deployment.

Any other protocol: connectors

Modbus TCP and RTU, with SunSpec maps, ship today. Equipment that speaks another protocol, for example EtherNet/IP, is connected the same way the shipping clients are: CSS writes a connector that feeds the data model, typically working within a week. Everything above it, from control logic and the local web UI to ByteHive Cloud and signed updates, works unchanged. Ask us about the protocol your equipment uses.

Roadmap

The following protocol work is in development or planned. It is not part of the shipping SDK 1.0.0 release, so confirm status with CSS Inc. before building it into a project plan.

• EtherNet/IP (planned): a packaged connector for industrial automation equipment.
• CAN / J1939 (planned): for battery systems and other equipment that communicate over CAN rather than Modbus.
• DNP3 (planned): for utility and SCADA environments that require it upstream.
• OCPP 2.0.1 charge point (planned): to bring EV charging into site logic.
• OpenADR 2.0b (planned): to receive demand-response signals.
• MQTT (planned): for publish/subscribe integration with plant and enterprise systems.
• Modbus RTU server (planned): so supervisory systems connected only over serial can read the values you map.

Summary

Integrating an energy site is mostly about handling variety: many device makers, changing equipment, slow shared buses, on-site commissioning and hardware that is not available when development starts. ByteHive answers each of these with a specific choice. Register maps are configuration rather than drivers. Modbus TCP and RTU clients serve the devices below the gateway, and a Modbus TCP server serves SCADA or EMS above it. Per-block polling and coalesced reads of up to 125 registers make good use of the bus. SunSpec maps are included, on-board I/O can be reconfigured live, devices are commissioned from the web UI, site-level SUM, AVG, MIN and MAX are built in, and simulators exercise logic before it reaches hardware.

The sample gateway app, CSS Gateway, shows the result assembled into an application you can start from. ByteHive gives you the same foundation for building your own.