doover-app-explorer
npx skills add https://github.com/getdoover/doover-skills --skill doover-app-explorer
Agent 安装分布
Skill 文档
Doover App Explorer
This skill helps you search and explore existing Doover applications to evaluate functionality, find apps for integration, and understand available components.
Important Note
The App Explorer and public API only show public and Doover core apps. Your organization may have access to additional private apps that are not listed here. Private apps are shared directly between organizations and won’t appear in public searches.
To see all apps available to you, check your organization’s app library in the Doover admin panel.
App Explorer UI
Browse available apps visually at:
https://admin.doover.com/app-explorer
The web interface provides:
- Searchable list of all public applications
- App details including description and configuration
- Dependency visualization
- Installation statistics
API Access
Query apps programmatically using the public API:
GET https://api.doover.com/public/applications/
Pagination
| Parameter | Default | Description |
|---|---|---|
page |
1 | Page number |
per_page |
100 | Results per page (max 100) |
Example Request
curl "https://api.doover.com/public/applications/?page=1&per_page=100"
Response Structure
{
"count": 33,
"next": null,
"previous": null,
"results": [
{
"id": "93956442461108741",
"name": "platform_interface",
"display_name": "Platform Interface",
"description": "Core hardware I/O interface",
"long_description": "Full markdown documentation...",
"type": "DEV",
"visibility": "COR",
"allow_many": false,
"config_schema": { ... },
"depends_on": [],
"image_name": "ghcr.io/getdoover/platform_interface",
"approx_installs": 150,
"stars": 5
}
]
}
Application Fields
| Field | Type | Description |
|---|---|---|
id |
string | Unique identifier |
name |
string | Machine-readable name (snake_case) |
display_name |
string | Human-readable title |
description |
string | Brief summary |
long_description |
string | Full markdown documentation |
type |
enum | App type (see below) |
visibility |
enum | Visibility level (see below) |
allow_many |
boolean | Can run multiple instances |
config_schema |
object | JSON Schema for configuration |
depends_on |
array | IDs of required apps |
image_name |
string | Docker image path |
approx_installs |
integer | Approximate install count |
stars |
integer | User rating |
App Types
Doover has three types of applications:
| Type | Name | Runs On | Purpose |
|---|---|---|---|
DEV |
Device App | Docker on devices | Hardware control, local logic, device UI |
PRO |
Processor | Cloud (serverless) | Cloud logic triggered by channels or schedules |
INT |
Integration | Cloud (serverless) | Receive external data for an organization |
Device Apps (DEV)
Run as Docker containers on field devices. They:
- Access hardware via platform interface (GPIO, Modbus)
- Run continuously with a main loop
- Provide real-time device UI
Processors (PRO)
Cloud-based apps triggered by:
- Channel messages (react to device data)
- Schedules (periodic tasks)
Installed per-device, can update device UI remotely.
Integrations (INT)
Cloud-based apps that:
- Receive HTTP POST from external systems
- Are installed at the organization level
- Forward data to device channels
See the doover-cloud-apps skill for detailed documentation on processors and integrations.
Visibility Levels
| Visibility | Description | In Public API |
|---|---|---|
PUB |
Public – available to all users | Yes |
COR |
Core – system infrastructure apps | Yes |
PRI |
Private – shared between specific organizations | No |
Note: Private apps (PRI) are not visible in the public API or App Explorer. They are shared directly between organizations and only accessible to authorized users.
Core System Apps
These are foundational apps that other apps depend on:
Platform Interface
- Purpose: Hardware I/O access (digital/analog inputs and outputs)
- Provides: gRPC interface for GPIO, pulse counting, scheduled outputs
- Used by: Apps needing hardware control
Device Agent
- Purpose: Cloud connectivity and data management
- Provides: Channel publishing, tag management, remote configuration
- Used by: All apps needing cloud features
Modbus Interface
- Purpose: Modbus RTU/TCP communication
- Provides: Register read/write, polling subscriptions, virtual servers
- Used by: Apps communicating with Modbus devices
Finding Apps for Integration
By Functionality
Search the API or UI for apps by their purpose:
# Fetch all apps and filter locally
curl "https://api.doover.com/public/applications/?per_page=100" | \
jq '.results[] | select(.description | test("modbus"; "i"))'
By Dependencies
Find apps that depend on a specific app:
import requests
response = requests.get("https://api.doover.com/public/applications/?per_page=100")
apps = response.json()["results"]
# Find apps depending on platform_interface
platform_id = "93956442461108741"
dependent_apps = [
app for app in apps
if platform_id in app.get("depends_on", [])
]
By Config Schema
Examine config schemas to understand integration points:
# Find apps that accept application references
apps_with_app_refs = [
app for app in apps
if "doover-application" in str(app.get("config_schema", {}))
]
Understanding Config Schemas
Config schemas use JSON Schema with Doover extensions:
Standard Properties
{
"config_schema": {
"$schema": "https://json-schema.org/draft/2020-12/schema",
"type": "object",
"properties": {
"pump_pin": {
"title": "Pump Output Pin",
"type": "integer",
"default": 0,
"minimum": 0,
"maximum": 31
}
},
"required": ["pump_pin"]
}
}
Doover Extensions
| Extension | Description |
|---|---|
x-name |
Property identifier in code |
x-hidden |
Hide from UI (true/false) |
x-required |
Conditional requirement |
format: "doover-application" |
Reference to another app |
format: "doover-device" |
Reference to a device |
format: "doover-schedule" |
Schedule configuration |
Application References
Apps can reference other apps in their config:
{
"data_logger_app": {
"title": "Data Logger Application",
"type": "string",
"format": "doover-application",
"description": "App key of the data logger to send data to"
}
}
Example Apps
Small Motor Control
Controls engine ignition, starter, and emergency stop:
- Dependencies: Platform Interface
- Tags exposed:
state,run_request_reason - Config: Pin assignments for starter, ignition, run sense
{
"name": "small_motor_control",
"display_name": "Small Motor Control",
"depends_on": ["93956442461108741"],
"config_schema": {
"properties": {
"starter_pin": { "type": "integer" },
"ignition_pin": { "type": "integer" },
"run_sense_pins": { "type": "array" }
}
}
}
Modbus Channel Relay
Bridges Modbus devices to Doover channels:
- Dependencies: Modbus Interface, Device Agent
- Purpose: Read Modbus registers and publish as JSON to channels
- Config: Register mappings, data types, channel names
Generator Control
Complex state machine for generator management:
- Dependencies: Platform Interface, Small Motor Control
- Features: Auto start/stop, warmup/cooldown cycles, scheduling
- States: off, starting, warmup, running, cooldown, stopping, error
Integrating with Existing Apps
Reading Tags from Other Apps
class MyApp(Application):
async def main_loop(self):
# Get app key from config
motor_app_key = self.config.motor_control_app.value
# Read state from motor control app
motor_state = self.get_tag("state", app_key=motor_app_key)
run_reason = self.get_tag("run_request_reason", app_key=motor_app_key)
if motor_state == "running":
await self.process_motor_running()
Coordinating with Other Apps
class CoordinatorApp(Application):
async def main_loop(self):
# Read status from multiple apps
apps = [a.value for a in self.config.managed_apps.elements]
statuses = {}
for app_key in apps:
statuses[app_key] = self.get_tag("status", app_key=app_key)
# Coordinate based on aggregate status
all_ready = all(s == "ready" for s in statuses.values())
if all_ready:
await self.start_sequence()
Config for App References
from pydoover.config import Schema, Application
class MyConfig(Schema):
def __init__(self):
self.motor_control_app = Application(
"Motor Control App",
description="App key of the motor control instance"
)
self.data_logger_app = Application(
"Data Logger App",
description="App key for data logging"
)
Evaluating Apps
When evaluating an app for use:
- Check dependencies – Ensure required apps are available
- Review config schema – Understand required configuration
- Read long_description – Full documentation and usage notes
- Check allow_many – Whether multiple instances are supported
- Review tags exposed – What data the app publishes
- Check install count – Indicator of maturity/reliability
Searching Tips
Find Hardware Control Apps
Look for apps depending on Platform Interface:
curl -s "https://api.doover.com/public/applications/?per_page=100" | \
jq '[.results[] | select(.depends_on | index("93956442461108741"))] |
.[] | {name, display_name, description}'
Find Protocol Bridges
Search for “modbus”, “mqtt”, “relay”, “bridge” in descriptions:
curl -s "https://api.doover.com/public/applications/?per_page=100" | \
jq '.results[] | select(.description | test("modbus|mqtt|bridge"; "i")) |
{name, display_name, description}'
Find Apps with Specific Config Types
# Apps accepting schedule configuration
curl -s "https://api.doover.com/public/applications/?per_page=100" | \
jq '.results[] | select(.config_schema | tostring | test("doover-schedule")) |
{name, display_name}'
Using App Explorer in Development
Before Building a New App
- Search the explorer for existing functionality
- Check if an existing app can be extended or configured
- Look for apps with similar dependencies for patterns
- Review config schemas for integration approaches
When Integrating Apps
- Find the target app’s ID and exposed tags
- Add application reference to your config schema
- Use
get_tag()with the app key to read data - Coordinate via tags or channels
Understanding the Ecosystem
The app explorer helps you understand:
- What infrastructure apps are available
- Common patterns in config schemas
- How apps depend on each other
- What functionality already exists