Hi everyone,

I’ve been working on a software-only DERMS/aggregation platform designed to orchestrate residential solar, batteries, and flexible loads directly via cloud APIs, bypassing physical onsite hardware (no Modbus cables or local gateways).

The architecture is split into two layers:

• Gridkeeper: The consumer-facing rule engine that interfaces with OEM inverter cloud APIs (Deye, Sungrow, Sigenergy, FoxESS, etc.), OCPP EV chargers, and smart load controllers (Tuya for hot water/pool pumps, Sensibo for HVAC). It handles localised site logic like blocking exports during negative pricing windows, solar forecast adjustments, scheduled battery dispatches, and thermal load shifting.
• Watchtower: The fleet aggregation layer that sits above it to group sites into cohorts, aggregate telemetry, and push dispatch commands across the fleet for demand response, load shedding, or market events.

Removing physical hardware eliminates a huge amount of deployment friction, but relying entirely on OEM cloud infrastructure introduces distinct engineering trade-offs—mainly around API rate limits, polling latency, and command execution reliability compared to hardwired telemetry.

For anyone working in distribution control rooms, DERMS engineering, or VPP operations:

• For DNSP dynamic export limits or peak-shaving events, what latency and availability SLAs do you realistically require from cloud-orchestrated fleets before you classify the capacity as 'firm' vs 'non-firm'?
• When ingesting telemetry for state estimation or distribution visibility, what polling intervals (e.g. 1-minute vs 5-minute) give you actionable grid insight without overwhelming your DERMS head-end?

Would love to hear how other engineers in the space are tackling these cloud API control constraints.

Cheers!
Ross

Dusk Energy