ESP RainMaker Neo Cloud Specifications

ESP RainMaker Neo is Espressif’s next-generation RainMaker platform. This is the specification for its cloud backend: an AWS serverless deployment (CDK, Go Lambdas, IoT Core) that owns identity, node lifecycle, groups, timeseries, notifications and the voice-assistant integrations.

It documents how the backend behaves — data models, flows, access control and the contracts it holds with nodes and apps. The node side of those same contracts is specified in the ESP RainMaker Neo firmware documentation.

Each page is self-contained and covers one feature area. Start with User Management, Authentication & Credentials and Node association — almost everything else assumes the identity and ownership model they establish.

Identity and access

  • user_auth — Cognito user pools, the identity pool, the three IAM roles, and the two credential planes (identity-pool credentials vs. AssumeRole with a per-session policy).

  • node_assoc — user–node association: how a node is claimed, what makes the claim secure, and how ownership is torn down.

  • group — the group model, group permissions and access control, naming rules, capacity limits, and the group APIs.

Admin Dashboard

Everything an admin or super admin can reach. See the section overview for the reading order; the pages cover authentication and permissions, the admin APIs, the data model, RBAC, the dashboard itself, fleet indexing and, for contributors, populating a deployment with data.

Node lifecycle

  • assisted-claiming — how a node acquires its identity: the claim-initiate and claim-verify APIs, the reservation table, and the KMS-backed certificate issuer behind them.

  • node_reg — node registration, including the asynchronous bulk CSV job that runs on ECS Fargate.

  • node_connection — the connection lifecycle: the actors involved, the clocks that govern them, and what each timeout does.

  • node_params_messaging — device↔cloud messaging: shadow vs. to_cloud/from_cloud vs. indexed params.

  • device_management — the iparams indexed-params shadow: who writes each section, the DynamoDB mirror rule, and the document shape.

Features

  • schedules — the schedule data model and payload shape, its access control, and the schedules (API) ↔ Schedules (firmware) key translation.

  • automations — per-node triggers (pushed to the node as service config) and group-scoped automations (evaluated in the cloud).

  • group-control-feature — one publish controlling many devices, mapped onto subgroups and addressed by device type.

  • timeseries — the ingest path (MQTT → IoT rule → DynamoDB → stream → aggregator) and the read path.

  • notifications — the dispatcher and service-registry model that the individual channels plug into.

  • notifications-push — the mobile push channel.

  • notifications-webhooks — the outbound webhook channel.

  • s3-device-file-storage — per-device file storage in S3.

  • kvs-camera-streaming — Kinesis Video Streams camera streaming.

Voice assistants

  • alexa — the Alexa Smart Home integration.

  • gva — the Google Voice Assistant integration.

Platform

  • iot_event_mode — SQS-backed lambdas and the runtime mode flip.

  • deploy-publish — the two deployment flows (self-deploy vs. the published installer template) and the operator inputs each takes.

  • limits — the AWS service limits this deployment operates against, and what each means at ESP RainMaker Neo scale.

Contributing

Want to contribute? Start with CONTRIBUTING.md at the repository root — it is the single source of truth for setup, conventions, the CLA and what a pull request needs. (CONTRIBUTING.md, SECURITY.md and LICENSE live at the root because GitHub surfaces them from there; everything longer-form lives under docs/.)

These pages go deeper on individual topics: the contributor agreement, the style guide, documentation expectations and testing.

API reference

The HTTP and MQTT surfaces are not part of this build. They are specified as OpenAPI and AsyncAPI documents under docs/api/ and published as here: https://api.docs.neo.rainmaker.espressif.com

That page links the HTTP, MQTT and event references, each serving the raw YAML alongside its rendering. The specs describe the API contract; every deployment serves that contract at its own API Gateway hostname.