Zap for Developers

The Zap is Sourceful's universal connector for distributed energy resources (DERs). It's a protocol-agnostic coordination platform that enables real-time communication between energy devices and the Sourceful Energy Network.

What is Zap?

Zap is a universal DER coordinator - not just a P1 meter reader. It's designed to connect and coordinate diverse energy resources through multiple communication protocols.

Hardware Foundation:

• ESP32-C3 chipset architecture
• Hardware-agnostic firmware (works on commodity ESP32-C3 boards)
• Closed-source firmware optimized for coordination
• Low-latency edge computing capabilities

Design Philosophy:

• Local-first coordination: Core logic runs at the edge
• Protocol-agnostic: Speaks the native language of your devices
• Distributed deployment: Multiple Zaps per installation for modular systems

Supported Protocols

Multiple protocols can run simultaneously on a single Zap, enabling complex multi-device coordination.

Architecture: Local-First Coordination

Zap operates on an edge computing model where coordination logic executes locally:

Why Local-First:

• Sub-second response times for grid services
• Reliable operation without internet dependency
• Reduced latency for real-time optimization

Cloud Role (Novacore):

• Data aggregation and historical storage
• Advanced analytics and optimization algorithms
• Market integration and grid service coordination
• User interfaces (mobile app, web dashboard)
• Organization and device management

Core coordination continues to function even if cloud connectivity is temporarily lost.

Distributed Deployment

Users often deploy multiple Zaps per installation for modular, flexible systems:

Each connection point can be a separate Zap, enabling independent protocol handling and easy system expansion.

What Zap Provides Developers

• Verified DER telemetry normalized into platform resources (organizations, sites, devices, DERs)
• Near-real-time readings and historical access via Novacore REST API
• Bidirectional communication capabilities (where DER APIs support it)
• Price/tariff alignment for forecasting and analytics (see Price API)
• Secure, organization-based access with role-based permissions

Access Pattern

1. Authenticate with Novacore and obtain a JWT token
2. Query device telemetry for authorized organizations and sites
3. Subscribe to real-time data via SSE streams or poll for new samples

Data Model Overview

Typical reading payloads include:

{
  "siteId": "string",
  "meterId": "string",
  "timestamp": "2025-01-15T14:30:00Z",
  "measurements": [
    { "key": "power_W", "value": 1500, "unit": "W" }
  ],
  "source": "zap"
}

Notes:

• Keys are normalized from meter outputs; availability varies by meter model/locale
• Use siteId/meterId for correlation; do not infer identity from labels
• Units are explicit; do not assume defaults

Cadence & Reliability

• Cadence: Near real-time; exact sample rate depends on meter capabilities
• Ordering: Treat events as eventually consistent; use timestamps
• Gaps: Handle temporary gaps (connectivity, meter limits)
• Idempotency: Use (meterId, timestamp, key) as stable identity for deduplication

Best Practices

• Request least-privilege access and narrow resources to specific sites
• Store and aggregate locally for your UX, but reconcile periodically with historical reads
• Treat tariffs/prices as time-varying; always fetch by effective window
• Be robust to missing fields; meters differ by market and firmware

Regional Considerations

The protocol-agnostic approach enables Zap to work anywhere with supported communication standards.

Related Documentation

• Authentication - Challenge/verify authentication
• Data Models - IDENTITY > ORG > SITE > DEVICE > DER hierarchy
• Price API - Price and tariff data
• API Overview - Novacore REST API documentation
• Zap Local API - Local endpoint documentation