Build Against a Real Platform
These docs cover the practical path: get a camera feed online, connect hardware over MQTT, keep the rig healthy, and launch privately before you ever go public.
Architecture Overview
A practical yourmove node has four moving parts, and each one has a clear job.
Physical Rig
Your hardware does the actual work: motion, firing, dispensing, triggering, sensing, or reacting to commands.
Camera Feed
Your camera shows the interaction area. That feed needs to be available locally so an edge machine can publish it upstream.
Local Edge Runtime
The edge box sits near the rig, publishes live video, creates buffered clips, and reports health back to the platform. Linux is the supported path today.
Device Runtime
Your firmware or local client subscribes to commands over MQTT, executes them safely, and reports state, acknowledgements, and results back.
Current Supported Path
Linux Edge Machine
Use a small Linux box near the rig to handle live publishing and buffered clips. That is the path we actively run and support today.
RTSP Camera Source
Expose a clear local camera feed and let the edge runtime publish it upstream. The camera stays local; the edge box handles the bridge.
ESP32 or Pi Control
Use an ESP32 for direct rig control or a small local computer if your project needs something richer. Both fit the command model.
Windows Later
We plan to offer a Windows-friendly edge path later, but Linux is the real supported route today and the one to build against now.
BYO Bring-Up Flow
This is the practical path for a developer bringing their own hardware onto the platform today.
Create or Claim a Private Node
Start with a private node in the platform so you have a place to configure video, device settings, limits, scheduling, and diagnostics.
Register the Device in the Dashboard
Use Register Device in the dashboard to generate the platform-side MQTT identity and the one-time bootstrap credentials for your hardware.
Save Credentials Immediately
The MQTT password is shown once on registration. Store it right away and treat it like a real credential, not something the page will keep revealing forever.
Wire Up Reporting Before Action
Get presence, capabilities, state/reported, and telemetry flowing before you worry about firing relays or moving motors.
Calibrate on the Private Node
Use diagnostics, inversion, limits, and cooldown tuning in the dashboard until motion, firing, and state reporting feel clean and repeatable.
Local Edge Runtime
The edge layer is what makes low-latency video and reliable clip capture practical in the real world.
What It Does
Publishes the local camera feed upstream, keeps a rolling clip buffer near the rig, and reports runtime health back to the platform.
Current Support
Linux is the supported path today. The current runtime is built around Python, Docker, ffmpeg, and local machine access near the rig.
Feed Publishing
The edge machine takes a local camera feed and pushes it to the platform ingest path. That keeps the camera private while still enabling live playback.
Buffered Clips
Clips are captured near the rig so the action itself is not missed. This avoids the delay and timing problems of cloud-started clip recording.
Sample Edge Config
{
"node_slug": "chicken-blaster",
"base_url": "https://yourmove.live",
"auth_token": "REPLACE_WITH_OWNER_JWT",
"rtsp_url": "rtsp://admin:password@192.168.0.106:10554/tcp/av0_1",
"probe_interval_seconds": 2,
"clip_pre_roll_seconds": 3,
"clip_post_roll_seconds": 6
}The edge config tells the local runtime which node it belongs to, where the camera feed lives, how to authenticate back to the platform, and how the clip buffer should behave.
What You Get From Us
- private node slug
- operator access
- edge config pattern
- live ingest path
- MQTT topics and credentials
- dashboard diagnosticsThe goal is not to dump you into a blank page. Once you are in, you should have enough platform-side structure to get a real private node online quickly.
Device Runtime and Firmware
You can run this on an ESP32, a Raspberry Pi, or your own hardware stack as long as it speaks the command lifecycle cleanly.
Reference Firmware
We already have a working ESP32 control path for motion, relay firing, reporting, bounds, and runtime tuning. That is the best reference point today.
Known Patterns
Pin mappings, inversion settings, soft limits, cooldown tuning, and calibration patterns are already part of the current rig model.
Safety Expectations
Commands need bounds, expiry, safe defaults, and sane fail states. The platform can help, but hardware safety still starts on the device side.
Diagnostics
The dashboard already supports diagnostics, inversion, motion limits, cooldown tuning, schedule windows, and operator visibility for real-world testing.
Reference Rig Profile
We already have a working reference pattern for a turret-style rig. Builders should not have to reverse-engineer that from scattered commits.
Current ESP32 Pinout
#define YM_PAN_SERVO_PIN 4
#define YM_TILT_SERVO_PIN 5
#define YM_RELAY_PIN 3
#define YM_SERVO_MIN_US 500
#define YM_SERVO_MAX_US 2400
#define YM_COOLDOWN_MS 2000This is not the only possible hardware profile, but it is a real current one. It gives builders a concrete starting point instead of abstract talk.
What This Pattern Covers
- pan / tilt motion
- relay trigger action
- inversion controls
- motion limits
- cooldown tuning
- telemetry and presence
- dashboard diagnosticsIf your project looks roughly like a controllable aimed device, this path gets you a lot for free. More exotic rigs can still adapt the same control and reporting model.
MQTT Command Model
At the protocol layer, the goal is simple: commands go out with a lifecycle, and the device reports back what actually happened.
Topic Set at a Glance
nodes/{node_id}/commands
nodes/{node_id}/ack
nodes/{node_id}/result
nodes/{node_id}/presence
nodes/{node_id}/telemetry
nodes/{node_id}/capabilities
nodes/{node_id}/state/reportedOnce a node is registered in the dashboard, these are the concrete topics the platform expects your runtime to use.
Credential Hand-Off
- mqtt_node_id
- mqtt_username
- mqtt_password
- runtime_type
- device_typeThose values are what your firmware or local device runtime uses to authenticate and map itself to the correct platform node.
Command Topic
{
"command_id": "uuid",
"class": "action",
"type": "fire",
"payload": { "pan": 45.0, "tilt": -12.5 },
"issued_at": 1710000000,
"expires_at": 1710000002
}Your runtime receives commands, validates them, executes them safely, and treats expiry seriously so stale actions do not linger.
Reporting Topics
{
"command_id": "uuid",
"status": "ack"
}
{
"command_id": "uuid",
"status": "completed"
}
{
"state": "online"
}This reporting loop is what keeps the public UI, dashboard, and diagnostics honest. If the rig is healthy, the platform should know it in near real time.
Private Launch Checklist
This is the path we want developers to follow before a node is ever exposed publicly.
Get a Private Node
Request access, get a private node online, and keep it private while you integrate and test.
Bring Up Video First
Verify that the local camera feed, edge runtime, and public playback path are stable before worrying about control polish.
Connect Commands and Reporting
Subscribe to commands, confirm acknowledgements and state reporting, and make sure the dashboard reflects what the rig is actually doing rather than what you hope it is doing.
Calibrate and Harden
Set limits, tune inversion, confirm recovery behavior, and make sure long sessions do not require babysitting.
Prepare for Public Launch
Once the node is stable, understandable on camera, and worth replaying, move toward review and public listing.
Build With Us
If you already have hardware or a strong concept, request developer access and we will help you get a private node online.
