tomevault-io Doover Platform Docs
Development reference for building applications on the Doover IoT platform using the pydoover SDK and the widget JavaScript framework (React + Module Federation).
Your Role
You are assisting a developer who is building or maintaining a Doover application. The reference docs in this skill contain the correct patterns, class structures, import paths, and code examples for the pydoover SDK and the widget JS framework. Use them to give accurate, idiomatic answers — don't guess at APIs or invent patterns.
When to Load Docs
Load relevant reference chunks when the developer is:
- Writing or modifying application code — load the chunk for their app type (Docker, Processor, Integration, or Widget) to get correct class structures and lifecycle methods
- Working on configuration — load
config-schema.mdfor thepydoover.configschema API (types, defaults, constraints, nested objects) - Working on UI elements — load
docker-ui.mdfor thepydoover.uicomponent API (variables, parameters, actions, submodules, range coloring) - Building or modifying a widget — load
widget-architecture.mdfor the 3-layer component pattern, Module Federation config, and styling conventions; loadwidget-hooks.mdfor platform hooks and data access - Working with tags or channels — load
tags-channels.mdforget_tag,set_tag, channel publishing, and inter-agent communication - Setting up a project — load the relevant project setup chunk for Dockerfile/entry point (Docker) or build script/Lambda packaging (Cloud)
- Debugging import errors or missing methods — load the relevant chunk to verify correct import paths and method signatures
- Asking "how do I..." questions about the platform — scan the index for matching keywords and load the relevant chunks
How to Load Docs
- Read
references/index.md— this contains a keyword registry mapping topics to specific chunks - Match the developer's current task to keywords in the index
- Read only the chunks that are relevant — don't load everything upfront
- If the developer's question spans multiple topics, load multiple chunks
Reference Chunks
All chunks live in references/ relative to this skill.
Core (all app types)
| Chunk | File | Covers |
|---|---|---|
| Configuration Schema | config-schema.md |
pydoover.config — Boolean, String, Integer, Number, Array, Object, Enum types, defaults, constraints, nested schemas, export |
| Tags & Channels | tags-channels.md |
get_tag, set_tag, channel publishing, inter-agent messaging, throttling, state persistence |
| doover_config.json | doover-config.md |
App metadata, schema references, platform interfaces, dependency declarations |
Docker apps (device-based, containerised)
| Chunk | File | Covers |
|---|---|---|
| Application Class | docker-application.md |
pydoover.docker.Application — setup, main_loop, callbacks, lifecycle |
| UI Components | docker-ui.md |
pydoover.ui — Variable, Parameter, Action, Submodule, range coloring, alerts, deduplication |
| Advanced Patterns | docker-advanced.md |
State machines, async workers, hardware I/O (GPIO, Modbus), data aggregation |
| Project Setup | docker-project.md |
Entry point (run_app), Dockerfile, docker-compose, simulators, environment variables |
Cloud apps (Processor & Integration, serverless Lambda)
| Chunk | File | Covers |
|---|---|---|
| Handler & Events | cloud-handler.md |
pydoover.cloud.processor.Application — handler entry point, event methods (on_message_create, on_schedule, on_ingestion, on_deployment) |
| Project Setup | cloud-project.md |
build.sh, Lambda packaging, cold start considerations, idempotency |
| Processor Features | processor-features.md |
ManySubscriptionConfig, ScheduleConfig, ui_manager.push_async, connection status, processor-specific patterns |
| Integration Features | integration-features.md |
IngestionEndpointConfig, ExtendedPermissionsConfig, payload parsing, device routing, HMAC/CIDR validation |
Widget apps (React + Module Federation + Python processor)
| Chunk | File | Covers |
|---|---|---|
| Widget Architecture | widget-architecture.md |
3-layer component pattern, Module Federation config (rsbuild), shared modules from customer_site, ConcatenatePlugin, Tailwind CSS styling, processor-side RemoteComponent setup, name conventions |
| Widget Hooks & Data | widget-hooks.md |
Platform hooks (useAgent, useAgentChannel, useChannelUpdateAggregate, useChannelSendMessage), dataProvider methods, useParams/useRemoteParams, permissions, WebSocket behavior, common read/write patterns |
Key Principles
- Always verify imports against the docs. The
pydooverSDK has specific import paths (e.g.,from pydoover.docker import Applicationvsfrom pydoover.cloud.processor import Application). Don't guess — check the relevant chunk. - Docker and Cloud apps have different base classes and lifecycles. Docker apps loop continuously (
main_loop); Cloud apps respond to events (on_message_create,on_schedule, etc.). Don't mix patterns. - UI components work the same in Docker and Processor apps. Both use
pydoover.ui. Integration apps never have UI. - Widget apps have two sides. The JavaScript widget (React + Module Federation) handles the UI; the Python processor (
RemoteComponent+on_aggregate_update) registers the widget with the platform. Both chunks should be loaded together. - Widget JS must follow the 3-layer pattern. RemoteComponentWrapper → Hooks wrapper → Inner component. The inner component uses
useParams()fromreact-routerforagentId. Checkwidget-architecture.mdfor the exact structure. - Widget hooks come from
customer_site/hooks. Don't invent hook signatures — checkwidget-hooks.mdfor the correct names, parameters, and return values. - Config schemas are shared across all app types. The
pydoover.configAPI is identical regardless of app type. - When in doubt, load the chunk and quote it. It's better to show the developer the exact pattern from the docs than to paraphrase from memory.
Converted and distributed by TomeVault — claim your Tome and manage your conversions.