PowerLabs
Ops
An internal operations platform for managing the ROAV fleet: live unit telemetry, Raspberry Pi provisioning, user management, aggregate analytics, and an AI assistant with a generated knowledge base around the ROAV codebase.
Fleet table
and deep per-unit view.
At a glance you can see every unit's current state: whether it's deployed, retracting, tracking, and what the battery and power figures look like right now. Any field that changes updates across the table in real time. Alongside that sits the action log: a chronological feed of every command issued, across all units and users.
Selecting a unit opens a detail view with live metric readouts, production charts across multiple time ranges, a log stream, and controls for issuing remote operations to the Pi, all without touching AWS directly.
Register a Pi
in one step.
Provisioning a new Raspberry Pi previously meant manually navigating AWS IoT Core, creating a Thing, generating certificates, attaching a policy, and copying files onto the device. The ops tool wraps all of that into a single form: enter a Thing name, hit register, and download the bundle.
Lambda calls CreateThing and CreateKeysAndCertificate, attaches the ROAV device policy and returns a downloadable credential bundle (certificate.pem, private.key, and AmazonRootCA1.pem) that the Pi reads on first boot. Certificates are never stored server-side.
Chat and a
generated knowledge base.
The assistant has two modes. In Chat, you ask questions about the ROAV stack and get answers grounded in the actual codebase via retrieval-augmented generation (RAG), not generic responses.
The entire codebase (every Lambda function plus everything on the Raspberry Pi) is indexed into a Bedrock Knowledge Base, the vector store both features query. Point the Knowledge Base tool at any part of the codebase (a Lambda function, a Pi script, an MQTT handler) and it generates a structured doc covering that system. Custom docs can be written directly too, and all of it becomes the model's reference material for every future conversation.
Why build
this separately.
The mobile app is a product for operators and customers. The ops tool is a product for me and the team. Keeping them separate meant each could be designed for exactly one audience without compromise.
The ops tool is a second consumer of the same AWS infrastructure: same AppSync API, same DynamoDB tables, same Lambda functions. No separate backend was built. Admin-only operations (provisioning, user creation, IoT Jobs) are gated by a Cognito group check at the Lambda layer rather than a separate API.
Real-time fleet state comes from AppSync subscriptions: low-latency, push-based, field-level. Historical time-series analysis (inverter bins, environmental data, forecast comparisons) is queried from Athena, which is better suited for range scans over large datasets. Using both paths rather than forcing one to do both jobs kept each one simple.
Rather than a generic assistant, the chatbot runs RAG against a Bedrock Knowledge Base built from the entire ROAV codebase: every Lambda function and everything on the Pi. The same vector store backs the generated docs. The model gets targeted, retrieved context rather than a raw code dump, which makes answers meaningfully more useful.
