Open Protocol · Apache 2.0

AI speaks in goals.
Devices speak in
commands.
DoSync is the bridge.

An open communication protocol that lets AI agents interact with physical devices using semantic intent — no hardcoded rules, no manual configuration per device.

33/33certification tests
2implementations
<100msintent to action
Apache 2.0open source

Existing protocols

lock.unlock()
light.set_brightness(100)
thermostat.set_temperature(21)
// hardcoded, per-device, per-scenario

DoSync

"there is an emergency at home"
"nobody is home — save energy"
"good morning"
// every device resolves its own role

Architecture

Five layers. One semantic bridge.

DoSync is a 5-layer protocol stack. Each layer has a single responsibility and doesn't need to know how the others work. Compatible with Home Assistant, Philips WiZ, Shelly, Matter, Zigbee, and any WiFi device.

Layer 5

Intent

AI expresses semantic goals

Layer 4

Semantic

Resolver maps intent → device actions

Layer 3

Registry

Devices self-declare capabilities on join

Layer 2

Security

mTLS, local PKI — no internet required

Layer 1

Transport

WiFi · BLE · Zigbee · Z-Wave · Thread

Demo

From natural language to physical action.

A conversation with Claude AI triggers a physical emergency protocol in real time — 10 Philips WiZ bulbs, SMS notification, audit log. No commands. No rules. No cloud.

user → "there is an emergency at home"
# DoSync hub receives intent
# ensure_safety [emergency]
wiz-living1-01 turn_on brightness=100 ✓
wiz-living1-02 turn_on brightness=100 ✓
wiz-living2-01 turn_on brightness=100 ✓
alarm-test-01 alarm pattern=emergency ✓
notifier-sms-01 notify → +1555012... ✓
# 18 actions · 8 devices · 79ms
# audit log updated · SHA-256 chain intact
Watch the demo — 2 min

Raspberry Pi 5 running the hub autonomously · 10 Philips WiZ bulbs via UDP · SMS via Twilio · zero internet dependency

Milestone · June 2026

An AI gave one sentence.
A drone flew the whole mission.

DoSync was built domain-agnostic — nothing in it assumes a house. The proof: we took it to the hardest device, an autonomous drone. Then an AI model, from a single sentence in plain language, fired the intent and the drone flew the entire mission — every step confirmed by real telemetry, validated against ArduPilot SITL.

Human → AI

A sentence

“inspect the perimeter of this area”

AI → Intent

inspect_area

model builds the context and fires it

DoSync → Drone

Mission

take_off → 4× go_to → return_home → land

Path A — verified first

Intent fired by API

The full mission flown by posting the semantic intent to the hub. Proves the closed loop: command, telemetry, confirmed arrival at every step.

Path B — the real goal

Intent fired by an AI model

A model (Claude Haiku, via DoSync's native MCP server) read the goal in plain language, chose inspect_area, built the context, and fired it. The AI decided to act — the whole point of the protocol.

An AI model receives a plain-language instruction and fires the inspect_area intent
1 · The AI commands. A sentence in plain language → the model fires inspect_area with the center, radius and altitude it inferred.
DoSync hub log showing each waypoint command followed by a telemetry-confirmed arrival
2 · The hub confirms. Every go_to accepted is followed by a telemetry-confirmed reached target — FINISHED. Acceptance ≠ completion.
ArduPilot SITL console: arm, takeoff, climb, RTL, land, disarm
3 · The drone flies. ArduPilot SITL: ARM → NAV_TAKEOFF → height 25 → RTL → land → DISARMED. A complete autonomous mission.

When the AI guessed wrong, the system caught it.

On the first attempt — with no coordinates given — the model filled the gap with a plausible guess 11,000 km away from the drone. The supervisor did not fake success: it waited for a confirmed arrival, none came, and it aborted the mission with a clear diagnosis. The AI can be wrong. The protocol does not have to be.

Validated in ArduPilot SITL · physical-hardware flight is the next step, not a claim made today.

How it executes

From intent to action in 79ms.

Press the button and watch every layer of the protocol execute in sequence — resolver, policy engine, adapters, audit log. Real times from the production deployment.

Intent fired
intent: "ensure_safety"
urgency: emergency
source: claude_mcp
79ms
total latency
8
devices acted
18
actions fired
0
rules written

Quick start

Up and running in three commands.

No hardware required. The Docker demo starts the hub and registers 8 simulated devices automatically.

1 Clone the repo
$ git clone https://github.com/
  giulianireg-spec/dosync-protocol
2 Start with Docker
$ cd dosync-protocol
$ docker compose up
3 Open the dashboard
open http://localhost:47200
# hub · devices · audit log

Extensibility

Adding your own device takes one method.

Any device that can receive a network message can be a DoSync adapter. You implement one method — the hub handles the rest.

my_adapter.py
class MyBrandAdapter(DoSyncAdapter):

  async def execute(self, action, urgency):
    # translate DoSync action to your device
    await self.device.send(action.action, action.params)
    return ActionResult(success=True)

  @property
  def adapter_name(self):
    return "mybrand"

# register once — hub uses it automatically
executor.register(MyBrandAdapter())

Available today

wiz · homeassistant · shelly · matter · gpio · simulated

The adapter contract

One method: execute(action, urgency). The hub handles routing, audit logging, policy evaluation, and state tracking. Your adapter only speaks to the device.

Optional: state querying

Implement get_state(device_id) to participate in the background state refresher — the hub polls your device every 60s and skips redundant actions automatically.

Use cases

Not just for the home.

The same 5-layer stack works anywhere an AI needs to coordinate physical systems.

🏠

Smart home

Emergencies, routines, energy efficiency — orchestrated by intent, not rules.

🛒

Retail store

Cold chain failure at 3am → manager notified, sector locked, maintenance dispatched — before products are lost.

🏨

Hotel

"Guest in 412 has arrived" → room configured to saved preferences, no configuration needed.

🏭

Factory

"Line B failure" → notifications, access control, tamper-evident audit trail — coordinated alongside the line's own safety systems.

Certification

Self-certify your device in minutes.

Three tiers, self-certifiable with the CLI. No manual approval required for Basic and Standard.

Basic

DoSync Basic

Layers 1–3: connectivity, authentication, capability manifest.

  • Connects and authenticates
  • Publishes capability manifest
  • Appears in device registry
Standard

DoSync Standard

Layers 1–4: intent response, events, health reporting.

  • Responds to all intent classes
  • Sends events to the hub
  • Passes explainability checks
Emergency

DoSync Emergency

All layers + emergency override + tamper-evident audit log.

  • Emergency override without confirmation
  • SHA-256 chained audit log
  • mTLS per-device authentication
$ python3 certify.py --host <device-ip> --port 47200 --tier emergency
# generates dosync-cert.json — signed certification report

Project status

Honest about where we are.

Reference implementation. Apache 2.0. One person building it. Here's what's real today.

DoneREST API · WebSocket · Dashboard
DoneCertification CLI — Standard 33/33 · Emergency 44/44
DonePhilips WiZ adapter (UDP local)
DoneHome Assistant bridge (10 domains)
DoneNative MCP server (Claude, any LLM)
DoneLocal PKI + mTLS per-device auth
DoneRaspberry Pi 5 — autonomous 24/7
Donedosync-node — Node.js implementation
DoneMulti-hub assisted failover
DoneEmergency preemption — device-finality guaranteed (v0.4)
DonePrometheus /metrics — zero-dep observability
In progressDistributed state replication
PlannedBLE transport adapter
PlannedThird-party device certifications

Roadmap

Q2 2026 Idempotency + delivery semantics · multi-hub assisted failover · protocol v0.4
Q3 2026 Distributed state replication · benchmark under concurrent load · penetration testing · BLE transport
Q4 2026 IEEE WF-IoT 2026 paper · second independent implementation · outreach to device manufacturers
2027+ FamilyOS integration · DoSync as native protocol in commercial devices

Works with Home Assistant

A layer on top of HA — not a replacement for it.

Home Assistant already solved the hardest problem in the smart home: talking to thousands of devices. DoSync doesn't reinvent that — it reads devices from HA through a bridge that's already in the repo, and adds a semantic, auditable coordination layer above them. HA is one source of devices; the intelligence stays in the connecting AI.

HA's MCP server exposes commands

Turn on this light, set that thermostat. The intelligence of what to do lives in an automation you wrote, or in the AI sending commands.

DoSync resolves intents

Express a goal — ensure_safety — and a resolver coordinates the right devices across any source, with a tamper-evident audit log of what acted and why.

When DoSync earns its place

When coordination and traceability both matter at once — a fall-response that unlocks the door, lights the house, and messages family, with an auditable record of exactly what fired.

When it doesn't

For everyday automation — "porch light when I get home" — you don't need DoSync. HA's automations and its MCP cover that completely. The extra layer is for the narrow set of cases that need auditable coordination.