DEV Community: Rodrigo Giuliani

Home Assistant Already Talks to Your Devices. So What Would DoSync Add?

Rodrigo Giuliani — Tue, 16 Jun 2026 03:00:49 +0000

If you run Home Assistant, you've already solved the hardest problem in the smart home: talking to three thousand kinds of device. Lights, locks, sensors, vacuums, obscure Zigbee gadgets from a brand that no longer exists — HA speaks to all of them. And since 2025 it ships an MCP server, so an AI assistant can already reach in and control them.
So when a project like DoSync shows up describing itself as a protocol between AI and physical devices, the fair question from anyone in the HA community is: why would I need that? I already have HA, and now AI can talk to HA directly.
That's the right question, and I want to answer it honestly — including the part where the answer is "you probably don't."

What Home Assistant is, precisely

HA does three jobs: it integrates with devices, it runs automations, and it gives you a UI. The first job is the one that matters here, and it's genuinely excellent. HA is the richest device-integration layer that exists. Nothing should try to replace that, and DoSync doesn't — it reads devices from HA through a bridge that's already in the repo.
But notice what HA's model is, underneath: it's still commands. "Turn on light.living_room." "Set climate.bedroom to 21." The HA MCP server exposes those same commands to an AI. The intelligence about what to do — what should happen when there's an emergency, when nobody's home, when a sensor reads something strange — lives either in an automation you wrote in advance, or in the AI sending the commands. HA executes; it doesn't decide.
That's not a criticism. It's just the layer HA operates at: it aggregates devices and gives you a uniform way to command them.

Where a different layer might sit

DoSync operates one layer up, and only does one thing: it turns a semantic intent into a coordinated, auditable set of actions.
You don't tell it "turn on these ten lights, unlock that door, send this SMS." You express a goal — ensure_safety, away_mode — and a resolver decides which devices are relevant based on what they've declared they can do, executes the actions, and writes every one of them to a tamper-evident SHA-256 audit log. The devices can come from HA, or from a direct adapter (WiZ over UDP, GPIO on a Pi, BLE, MQTT). HA is one source of "bodies," not the center.
Three things distinguish that from sending commands through the HA MCP:

Intents, not commands. The AI says what it wants to achieve; the resolver works out the rest from declared device capabilities. Add a device and it participates automatically — no automation to rewrite.
An audit log built for accountability. Every action and the reason it fired, in a SHA-256 hash chain: each entry includes the hash of the previous one, so editing or deleting a past entry breaks the chain and is detectable on verification. To be precise about what that buys you — it protects against undetected after-the-fact modification of the history, not against an attacker with root on the hub (who could rewrite the whole chain). HA's recorder and logbook give you a searchable history, which is great for "what happened"; the hash chain adds "and you can show it wasn't altered" — which matters when an auditor, an insurer, or an incident review needs a record they can trust, and matters not at all for everyday automation.
Multiple sources under one contract. DoSync coordinates devices from HA and from other adapters under a single semantic model with policies and certification. HA is one especially rich source among several.

And here's the part most projects won't say

For the vast majority of what people use Home Assistant for — "turn on the porch light when I get home," "set the thermostat back at night" — you do not need DoSync. HA's own automations and its MCP server cover that completely. Adding a coordination layer would be extra infrastructure earning you nothing.
DoSync earns its place only when two things are true at once: coordination matters (one goal has to fan out across many devices, reliably, possibly in an emergency) and traceability matters (you need an auditable record of what acted and why).
A concrete home example: an elderly parent lives alone, and you've built a fall-response setup — a sensor trips and the home should unlock the door for paramedics, turn every light to full, and message the family, all at once, and you need to be able to say afterward exactly what fired and when. That's coordination plus traceability in a house, not a factory. Outside cases like that — most of what HA does day to day — the extra layer earns you nothing.
If that's not your situation, stay with HA and enjoy it. That's not me being modest; it's me not wanting to sell you a layer you won't use.

How they actually fit together

The honest picture isn't DoSync versus Home Assistant. It's DoSync using Home Assistant — treating HA as one of the best places to source devices, and adding a semantic, auditable coordination layer above it for the narrow set of cases that need one. HA keeps owning its integrations. The connecting AI stays where the intelligence belongs — outside, expressing intent. DoSync is just the nervous system in between.
If you're in that narrow set of cases, it's worth a look. If you're not, you already have what you need — and if you're genuinely not sure which side of the line you're on, open an issue describing your setup and I'll tell you straight whether it's worth the trouble.

GitHub: https://github.com/giulianireg-spec/dosync-protocol
Web: https://dosync.dev/
License: Apache 2.0

When Automatic Failover Is More Dangerous Than No Failover

Rodrigo Giuliani — Sun, 14 Jun 2026 15:25:07 +0000

Here's a counterintuitive thing I ran into building redundancy for DoSync, an open protocol that lets AI agents act on physical devices: the obvious failover design can hurt you more than having no failover at all.
Let me show you why.

The setup

DoSync runs a hub — the process that turns a semantic intent ("there's an emergency") into coordinated device actions, and writes every action to an audit log. That log is a SHA-256 hash chain: each entry includes the hash of the previous one, so any edit to history breaks the chain and is detectable. It's the part of the system that lets you answer "what happened, and when?" with confidence.
One hub is a single point of failure. So the natural move is to add a standby that takes over when the primary dies. The naive design writes itself: the standby pings the primary every few seconds, and after N missed heartbeats it promotes itself to primary.
It works perfectly in a demo. It's dangerous in a house.

The trap: split-brain

Picture two hubs on your LAN. The network partitions — not the primary crashing, just the link between the two going away. The primary is alive and well, still serving its devices. But the standby can't see it.
So the standby promotes itself. Now you have two primaries, both convinced they're in charge, both writing to the audit log. The hash chain that made that log tamper-evident diverges into two incompatible histories. The one guarantee the whole system is built on — you can always reconstruct what happened — is gone.
A missed heartbeat doesn't tell you "the primary is dead." It tells you "I can't reach the primary." Those are very different statements, and the naive design treats them as the same.

The fix is mostly about honesty

The real solution to split-brain is a quorum — three nodes voting, à la Raft. But for a home or a small building, that's overkill, and you usually don't have a third node anyway.
So I went with something simpler and more honest: assisted failover. Two changes.
First, before the standby concludes anything, it runs a second probe against an independent target on the LAN (the gateway):

primary unreachable + gateway reachable  → primary is probably down
primary unreachable + gateway also down  → *I* am probably the problem

That one extra check separates two failure modes the naive design conflates. It is not a substitute for quorum — it doesn't help in every partition (if both hubs can still see the gateway but not each other, the probe tells you nothing). What it cheaply catches is the most common home case: the standby itself losing its network. When that happens, the standby enters an UNCERTAIN state and refuses to act.
Second — even when it does think the primary is down, it doesn't promote itself. It proposes promotion to a human. A person can glance at the situation and see whether the primary is actually alive. A 5-second heartbeat timeout cannot.
(To be clear, this whole multi-hub layer is opt-in. A single hub runs exactly as before — redundancy is for people who want it, not a requirement.)

Testing it on real hardware

I ran this on two real machines — a Raspberry Pi (primary) and a laptop (standby) — because this is exactly the kind of behavior that only shows up with real network conditions, not in unit tests.
Killing the primary process: standby detected it, gateway probe still succeeded, proposed promotion. Good.
Pulling the standby's network while the primary stayed up: standby saw both targets go dark, went UNCERTAIN, and stayed quiet. In that test, the only difference between "propose promotion" and "stay quiet" was the gateway probe — one bit of extra information deciding between a safe outcome and a corrupted log.

The takeaway

Availability features have a failure mode of their own. An automatic action taken on bad information can be worse than no action plus a clear signal to a human. For anything writing to physical state — locks, alarms, logs you can't afford to corrupt — "fail loudly and ask" is often a better default than "fail over silently," at least until you have real consensus to back automatic promotion.

DoSync is open source (Apache 2.0). If you want to poke holes in this design — and I'd genuinely like that — it's at dosync.dev. The failover logic is a small, dependency-free state machine; criticism welcome.

Why your smart home breaks the moment you add an AI agent

Rodrigo Giuliani — Wed, 03 Jun 2026 01:27:33 +0000

You add a new smoke detector to your home network. It registers with the hub. Thirty seconds later, when someone fires an ensure_safety intent, the detector is part of the response — no automation written, no rule updated, no developer intervention.
How is that possible?
The answer is capability abstraction. And it's the design decision that separates systems that work with AI from systems that merely tolerate it.

The device that knows its own role

Every existing smart home protocol treats a device as a passive endpoint. The device waits. Something external — an app, a rule engine, a developer's script — decides when to call it and what to tell it. The device's only job is to execute.
This model has a hidden assumption: that someone, somewhere, anticipated every scenario the device would be relevant for. They wrote the rule. They tested it. They kept it updated as new devices joined the network.
That assumption holds when humans are in the loop. It breaks the moment an AI agent enters the picture — because the AI doesn't have the rulebook. It has a goal. And the gap between "I have a goal" and "I know which devices to activate" is exactly the integration problem that makes AI-IoT systems fragile.
The fix is to move the knowledge of when a device is relevant from the rulebook into the device itself.

The Capability Manifest — a declaration, not an API

In DoSync, every device publishes a Capability Manifest when it joins the network. Here's a real one from the production deployment — a Philips WiZ bulb running on a Raspberry Pi 5:

json{
  "device_id": "wiz-living1-01",
  "device_name": "Living Room — Bulb 1",
  "manufacturer": "Philips",
  "model": "WiZ RGBW Tunable",
  "firmware": "1.0.0",
  "category": "actuator",
  "tags": ["light", "climate", "smart-plug", "emergency", "wiz"],
  "actuators": [
    { "id": "wiz-living1-01-turn_on",       "type": "turn_on",       "description": "Turn on" },
    { "id": "wiz-living1-01-turn_off",      "type": "turn_off",      "description": "Turn off" },
    { "id": "wiz-living1-01-set_brightness","type": "set_brightness", "description": "Set brightness 0-100%" },
    { "id": "wiz-living1-01-set_color",     "type": "set_color",     "description": "Set RGB color" }
  ],
  "sensors": [],
  "emergency_capable": true,
  "adapter": "wiz",
  "adapter_config": { "ip": "192.168.100.28" }
}

This isn't an API specification. It's a declaration of identity and relevance. The device is answering three questions at once:

What can I do? — turn on, turn off, set brightness, set color
Where do I fit? — I'm a light, I'm a smart plug, I'm an emergency device
When do I matter? — I'm emergency-capable; include me when safety is at stake

The AI agent never needs to know the device's native protocol. It fires:

json{
  "intent": "ensure_safety",
  "urgency": "emergency"
}

The resolver reads every registered manifest, scores each device for relevance — weighting tag overlap, location context, emergency bonus, and actuator match — and builds the action plan. The bulb is included because of its emergency tag and emergency_capable: true — not because anyone hardcoded it. Add ten more bulbs tomorrow with the same manifest structure, and they participate immediately in every emergency response.

emergency_capable is a contract, not a flag
This boolean deserves more attention than it usually gets.
When a device declares emergency_capable: true, it's not filling in a form field. It's making a commitment to the protocol:
I will respond to emergency intents without confirmation. I accept being included in the audit trail as a critical actor. I understand that my actions in emergencies will be logged with a tamper-evident SHA-256 chain.
The protocol enforces this contract. Emergency-capable devices bypass the normal policy evaluation flow. They're always included as candidates in emergency intent resolution, regardless of tag overlap. And every action they take is logged — precisely because actions taken during emergencies are consequential enough to require a verifiable record.
This is the correct place for a safety guarantee to live. Not in a rule written by a developer who may or may not have anticipated the edge case. In the device's own declaration, verified and enforced by the protocol at runtime.
Compare the two designs:
Rule-based: developer writes "if emergency, unlock frontdoor-01"
→ breaks when frontdoor-01 is replaced
→ breaks when a second entrance is added
→ breaks when the emergency scenario changes

Capability: device declares emergency_capable: true
→ protocol enforces the contract
→ survives device replacement, new entrances, new scenarios
→ audit trail is automatic

Why this is different from OpenAPI, MCP, and service registries

Capability abstraction is an old pattern. OpenAPI schemas describe what an HTTP service can do. MCP tool descriptions tell an LLM which tools are available and when to use them. Service registries in microservices architectures let services announce themselves at runtime.
DoSync's Capability Manifest is in this family. But there's a specific difference that matters for physical systems.
OpenAPI and MCP describe interfaces — the exact shape of inputs and outputs. They're precise but context-free. An OpenAPI schema for a door lock tells you the /unlock endpoint accepts a duration_seconds integer. It doesn't tell you that this lock is at the main entrance, that it's relevant in emergencies, or that it should be included in a safety response but not an energy-saving routine.
The Capability Manifest adds semantic context on top of interface description. The tags field isn't a type system — it's a declaration of relevance across scenarios.

["door-lock", "entrance", "emergency"]
tells the resolver three things that no API schema can express: what the device is, where it lives, and when it matters.
This distinction exists because AI agents reason at the semantic level, not the API level. An LLM detecting an emergency thinks "there's a safety situation" — not "send a PUT request to /api/v1/lock/frontdoor-01/state with body {locked: false, duration: 300}". The abstraction layer has to meet the AI where it operates — at the level of meaning, not syntax.

The device as a participant

Here's the shift capability abstraction enables, stated plainly:
In the command model, adding a device means updating your automations. The device is inert until a human decides it should participate in something.
In the capability model, adding a device is the integration. The manifest is the contract. From the moment it registers, the device participates in every scenario it declared itself relevant for.
Before: new device → engineer writes automation → device participates in scenario A
new scenario B → engineer writes automation → device participates in scenario B

After: new device registers manifest → device participates in all relevant scenarios
new scenario added to protocol → device participates automatically
This is not a small operational difference. In a home with 40+ devices, maintaining the "before" model means hundreds of automation rules, each one a potential failure point when a device changes or a scenario is updated. The "after" model has one integration surface per device — the manifest — and it never needs to be updated when scenarios change.

What the manifest teaches manufacturers

If you're building a device that will coexist with AI agents, the Capability Manifest is the interface that matters more than your API documentation.
A well-designed manifest answers the questions AI systems actually ask:

Will this device respond in an emergency? → emergency_capable: true/false
What kind of device is this? → category + semantic tags
What can it physically do? → actuators with meaningful type names
What can it sense? → sensors with type and unit
How does the protocol talk to it? → adapter + adapter_config

A poorly designed manifest — missing location tags, wrong emergency_capable value, generic actuator types — means the device is invisible to the AI in exactly the scenarios where it should matter most. The resolver can only work with what the device declares.
Tag your devices correctly. The rest is automatic.

The idea worth keeping

Five posts ago, we started with a simple observation: AI agents express goals, not commands. Every post since then has been an answer to the same question — what does a system have to look like, at each layer, to bridge that gap?
Semantic intent replaced commands. Policies replaced rules. Events were separated from intents. And now capability abstraction replaces the developer who used to be the translator between device APIs and AI goals.
The translator was always the fragile part. Every time a device changed, the translator broke. Every time a new scenario appeared, the translator had to be updated. Every time an AI agent expressed something that wasn't anticipated, the translator failed silently.
Capability abstraction removes the translator. The device speaks for itself. The AI listens. The protocol enforces the contracts between them.
That's not a smart home feature. That's the infrastructure for any physical environment where AI needs to act reliably.

GitHub: https://github.com/giulianireg-spec/dosync-protocol
Website: https://dosync.dev
License: Apache 2.0

Rules Aren't Enough Once an AI Is in the Loop

Rodrigo Giuliani — Sat, 30 May 2026 03:06:15 +0000

Picture this: it's 03:00. A camera detects that an elderly person has fallen in the bedroom. The AI agent fires ensure_safety [emergency]. The action plan includes unlocking the front door so emergency services can get in.
But someone wrote a rule three months ago: never unlock after midnight.
The rule wins. The door stays locked. The paramedics arrive and can't get in.
This is not a bug in the AI. It's not a bug in the rule — in any other context, locking the door at night is exactly right. It's a design problem — and it's the exact problem that appears when you build physical AI systems on top of automation logic that was never designed for an AI to act on.
The difference between a rule and a policy looks small from a distance. Both constrain behavior. Both say "don't do X in situation Y." But they operate at different levels of the system — and getting this distinction wrong in a physical environment has real consequences.

What a rule is

A rule is a static, pre-written instruction that maps a condition to an action.

if time > 22:00:
    lock.lock()

if motion_detected and away_mode:
    alarm.activate()

if temperature > 28:
    ac.turn_on()

Rules live in the automation layer. They're written by a human, at configuration time, for a specific scenario that was anticipated in advance. They're deterministic in the right circumstances: given the same input, they always produce the same output.
Rules work well when the world is predictable, the device set is stable, and a human is always the one deciding what to do. They've been the foundation of home automation for fifteen years for exactly this reason. Nothing in this article argues that rules are wrong or should be replaced — they're the right tool for scheduling, thresholds, and simple automations that a human configured deliberately. A rule that turns on the porch light at sunset doesn't need a policy — it has no safety implications, no edge cases, and no AI acting on it. Rules fail not because they're a bad idea, but because they were never designed to compose with an autonomous agent that can fire arbitrary intents at arbitrary times.
But rules have a structural weakness: they can only respond to situations that were anticipated when they were written. And when an AI agent starts firing intents, the space of possible situations grows faster than anyone can write rules for.

What breaks when AI enters the picture

An AI agent doesn't write rules. It fires intents.
When a vision model detects someone who has fallen, it doesn't execute alarm.activate() and phone.call("911") — it fires ensure_safety [emergency]. When a model infers that nobody is home, it doesn't iterate through a list of devices and turn them off one by one — it fires save_energy [info].
The intent expresses a goal. The protocol figures out how to achieve it.
But here's the problem: once you have an AI agent firing intents, you need a way to constrain what it can and can't do — without writing a rule for every possible scenario. You need something that can evaluate intent against context at runtime, not something that was pre-written for a specific situation.
You need a policy engine.

The difference that matters

A rule answers: what should happen when X occurs?
A policy answers: is this action permitted, given who's asking, what they want to do, and when?
The distinction is not cosmetic. It changes the entire structure of how you think about safety in a physical system.
Consider a front door lock. With rules:

# Rule 1: lock at midnight
if time == 00:00:
    lock.lock()

# Rule 2: unlock for delivery window
if time > 14:00 and time < 16:00 and delivery_expected:
    lock.unlock()

These rules handle the scenarios they were written for. But what happens when an AI agent fires control_access [emergency] at 03:00 because it detected an intruder? What happens when a different AI agent fires away_mode which includes an unlock action? What happens when two intents fire simultaneously and both want to act on the lock?
Rules don't compose. Each rule was written in isolation, without knowledge of the others. In a system where an AI can fire arbitrary intents at arbitrary times, the rule surface grows unbounded — and the gaps between rules are exactly where accidents happen.
A policy is different:

pythonNeverAfterHoursPolicy(
    actuator="unlock",
    device_ids=["lock-frontdoor-01"],
    blocked_hours=range(0, 6),      # never unlock 00:00–06:00
    except_urgency="emergency",     # unless it's an emergency
)

This policy applies to every intent that would unlock the front door, regardless of which AI fired it, regardless of what scenario triggered it. It's declared once. It evaluates at runtime. It composes with other policies automatically.
And it has an explicit emergency exception — because in a physical system, the rule "never unlock after midnight" has to be breakable in genuine emergencies. Rules can't express that nuance cleanly. Policies can.

What a policy engine actually does

In DoSync, every intent passes through the PolicyEngine before execution. The engine evaluates the action plan against all configured policies and returns one of four verdicts:

ALLOW — proceed as planned
BLOCK — reject the intent entirely
CONFIRM — hold execution and request human confirmation
MODIFY — allow execution but remove or adjust specific actions

This happens between the resolver (which decides what to do) and the executor (which actually does it). The AI never bypasses this layer — not even for emergency intents, which bypass policy constraints at the urgency level, not by circumventing the engine entirely.
In DoSync, this looks like:

python# An AI fires save_energy at 02:00
intent = Intent(
    intent=IntentClass.SAVE_ENERGY,
    urgency=Urgency.INFO,
    context={"trigger": "occupancy_inferred_empty"},
)

# The resolver builds an action plan:
# → turn_off: wiz-living-01..10
# → turn_off: wiz-hallway-01       ← this one is excluded by policy
# → set_temperature: thermostat-01

# The PolicyEngine evaluates:
# DeviceExclusionPolicy: hallway light excluded from save_energy → MODIFY
# ContextualWeightingPolicy: 02:00 on a weekday → weight reduced but ALLOW

# The executor receives the modified plan:
# → turn_off: wiz-living-01..10
# → set_temperature: thermostat-01

The AI expressed a goal. The protocol decided how to achieve it. The policy engine ensured the result was safe — without the AI needing to know anything about the hallway light policy, or the time-based weighting, or which devices are excluded from which intents.

Why this matters beyond the home

The rule/policy distinction becomes critical at scale and in regulated environments.
In a hotel, a rule that says "turn off lights when nobody is in the room" works until a guest leaves their laptop charging and the system decides the room is empty. A policy that says "never cut power to outlet circuits in occupied rooms regardless of occupancy inference" handles the edge case — without needing a rule for every possible device state.
In a hospital, a rule that says "lock all doors at 22:00" breaks the moment a crash cart needs to move between floors. A policy that says "door locks revert to unlocked state on emergency_capable override, regardless of schedule" is robust to the scenario that matters most — the one nobody wanted to think about at configuration time.
In a factory, a rule that says "shut down line B if temperature exceeds threshold" doesn't compose with the rule that says "never shut down line B during a shift change handover." A ConflictResolutionPolicy that assigns priorities to intents and resolves contention explicitly is the right abstraction — not an ever-growing set of conditional rules that interact in unpredictable ways.
The pattern is always the same: rules break at the boundaries between anticipated scenarios. Policies compose across all of them.

The audit implication

There's one more difference that matters in regulated environments: auditability.
A rule that fires an action leaves a trace, but the reasoning is implicit — buried in the automation logic that evaluated the condition. If something goes wrong, you can see what happened, but reconstructing why requires reading the rule code.
A policy verdict is explicit. Every intent execution in DoSync's audit log records what happened, what the resolver decided, and what the executor did — in a tamper-evident SHA-256 chained record. The reasoning is in the system's configuration (which policies are active, with what parameters), not buried in conditional logic that has to be reverse-engineered after the fact.

json{
  "type": "intent_executed",
  "intent": "save_energy",
  "urgency": "info",
  "actions": 9,
  "failed": [],
  "success": true,
  "hash": "a3f7...",
  "prev_hash": "9c12..."
}

This matters for post-incident analysis. It matters for regulatory compliance. And it matters for the fundamental accountability question in any AI-augmented physical system: when something goes wrong, can you reconstruct exactly what the system decided and why?
With rules, the answer is usually "mostly." With policies, the answer is "yes, completely."

The deeper point

Rules encode what to do. Policies encode what's permitted.
When a human is always in the loop, rules are enough — the human's judgment fills the gap between what the rules say and what should actually happen. When an AI agent is in the loop, that judgment gap has to be filled by the infrastructure.
That's what a policy engine is for. Not to constrain the AI arbitrarily, but to make the system's safety model explicit, configurable, and auditable — so that the AI can act autonomously within a boundary that a human defined deliberately.
The AI expresses goals. The protocol executes them. The policy engine ensures the result is safe.
That's the contract a physical AI system needs.

DoSync Protocol: https://github.com/giulianireg-spec/dosync-protocol
License: Apache 2.0

How I Used GitHub Copilot to Turn a Half-Finished Protocol Into a Certified Standard published

Rodrigo Giuliani — Wed, 27 May 2026 02:23:47 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

DoSync Protocol is an open-source communication protocol (Apache 2.0) that lets AI agents control physical devices using semantic intentions instead of commands. Instead of lock.unlock(), an AI agent says ensure_safety — and every registered device figures out its own role automatically.
The Python reference implementation was running in production on a Raspberry Pi 5. But a protocol with only one implementation isn't a standard — it's a library. The unfinished piece: a second independent Node.js implementation that could pass the DoSync certification suite.

Demo

GitHub: https://github.com/giulianireg-spec/dosync-protocol

── Tier BASIC ─────────────────────────────────────────────
  ✓  Hub reachable — version 0.1.0
  ✓  Protocol version declared — dosync/0.1
  ✓  Device can register — registered
  ✓  Device appears in registry — 1 device registered
  ✓  Hub returns device detail — status=200
  ✓  Capability manifest has all required fields — all present
── Tier STANDARD — Intents and events ─────────────────────
  ✓  Hub accepts notify_family intent — 4 actions executed
  ✓  Intent resolves correctly — 4 actions processed
  ✓  Device can send event — received
  ✓  Hub rejects unknown intents with 422 — status=422
  ✓  Hub rejects unregistered device events with 404 — status=404
── Result ──────────────────────────────────────────────────
  Tests passed: 11
  Tests failed: 0
  ✓ CERTIFIED — DoSync STANDARD

The Comeback Story

Before: The Node.js implementation (implementations/dosync-node) passed Basic certification (6/6 tests) — it could register devices and handle simple queries. But Standard tier was failing at test 1 because the server was missing GET /v1/status, the endpoint the certification suite uses to verify hub identity and protocol version.
Additionally, the certification CLI (certify.py) only supported HTTP — but the production hub runs on HTTPS with a local PKI. Running Standard tests against real infrastructure was impossible.
What changed:
certify.py — fixed to support real deployments:

HTTPS support with CA certificate validation via DOSYNC_CA_CERT
Bearer token injection via DOSYNC_TOKEN
Localhost detection: HTTP for local dev, HTTPS for remote
Connectivity test fixed to use /v1/status instead of / (which returns the HTML dashboard)

dosync-node — the missing endpoint, added with Copilot:

GET /v1/status — the single endpoint that unlocked Standard certification

After: dosync-node passes DoSync Standard certification (11/11). Two independent implementations in different languages, same protocol, same certification suite — the minimum criterion for an open standard.

My Experience with GitHub Copilot

Copilot contributed in two ways during this session.
Inline suggestions while editing certify.py. As I was modifying the HTTP helper to support HTTPS and token injection, Copilot's inline suggestions consistently anticipated the next line — the SSL context setup, the os.environ.get() calls, the exception handling pattern. It didn't write the logic, but it reduced the friction of writing boilerplate correctly on the first pass.
The endpoint that closed the gap. Once I identified that GET /v1/status was the missing piece, I asked Copilot Chat:

"I'm implementing the DoSync Protocol in Node.js. The certification suite requires a GET /v1/status endpoint that returns name, version, protocol, status, devices count, and audit_entries count. The existing code uses Fastify. Please add this endpoint following the same patterns already in the file."

Copilot read the existing file, identified the right variable names (registry, auditLog, VERSION, PROTOCOL), and generated:

javascript// GET /v1/status
app.get('/v1/status', async () => ({
  name:          'DoSync Hub',
  version:       VERSION,
  protocol:      PROTOCOL,
  status:        'running',
  devices:       registry.size,
  audit_entries: auditLog.length,
}))

Correct variable names. Correct Fastify pattern. No hallucinations. The key was giving Copilot the right context: the spec requirement, the existing code pattern, and the constraint. It didn't need to invent — it needed to synthesize what was already there.
After accepting the suggestion, the certification run went from 0/11 to 11/11. GitHub Copilot helped close the gap between "protocol with one implementation" and "protocol with a certified standard."

Repository: https://github.com/giulianireg-spec/dosync-protocol
License: Apache 2.0

Why AI Agents and IoT Protocols Speak Different Languages

Rodrigo Giuliani — Tue, 26 May 2026 13:21:13 +0000

There's a distinction that comes up constantly when designing systems that connect AI to physical environments, and it's one that most protocols blur or ignore entirely.
The distinction is between an event and an intent.
They look similar on the surface. Both are messages. Both carry information about the world. But they describe fundamentally different things — and building a system that confuses them leads to brittleness, fragility, and automation that breaks exactly when it matters most.

What an event is

An event is a description of something that happened.

json{
  "device": "pir-sensor-01",
  "type": "motion_detected",
  "timestamp": 1748000000,
  "location": "entrance"
}

An event is past tense. It's factual. It carries no opinion about what should happen next. The PIR sensor doesn't know whether this motion means "the kids just got home" or "there's an intruder" or "the cat walked by again." It just observed something and reported it asynchronously — fire and forget.
Events are the raw material of a physical system. Sensors generate them constantly — temperature readings, contact closures, power measurements, motion pulses. They are objective and dumb, in the best possible sense.

What an intent is

An intent is a description of something that needs to happen.

json{
  "intent": "children_arrived_home",
  "urgency": "info",
  "context": {
    "trigger": "motion_detected",
    "time": "18:45",
    "day": "monday"
  }
}

An intent is future tense. It carries meaning. It encodes a goal — what the system should achieve — without specifying how to achieve it. The intent doesn't say "turn on lights 3, 7, and 9 at 80% brightness." It says "the kids are home." The infrastructure figures out the rest.

The leap from event to intent requires reasoning. Something has to look at the motion event, consider the time, the day, the history, and decide: this event means the kids just arrived. That reasoning is exactly what AI agents are good at.

Concretely, that transition looks like this:

[PIR fires motion_detected at 18:45 on Monday]
        ↓
  AI agent reasons:
  - time: 18:45 → within arrival window
  - day: Monday → weekday
  - location: entrance → consistent with arrival
        ↓
  fires: children_arrived_home [info]
        ↓
  hub resolves against device registry:
  → 5 lights turn on
  → SMS sent to parents
  → audit log updated

The agent handled the meaning. The protocol handled the coordination.

Why conflating the two breaks systems

Most smart home platforms today — Home Assistant automations, Matter scenes, Zigbee rules — are built on a hidden assumption: that the translation from event to action is a simple, static mapping.
IF motion_detected AND time > 18:00 AND day IN [Mon, Tue, Wed, Thu, Fri]
THEN turn_on(light_1), turn_on(light_2), send_sms("kids home")
This works until it doesn't. Add a new light and the rule doesn't know about it. Change the schedule and you rewrite rules. Move to a new home with different devices and you start over. The rule hardcodes both the reasoning ("this motion means the kids arrived") and the execution ("these specific lights, this specific message").
Separating events from intents breaks this coupling.
The AI agent handles the reasoning layer: event → intent. It observes the motion, considers the context, and decides what's happening. That reasoning can be as simple or as sophisticated as needed — a time-based rule, a learned pattern, or a full LLM inference.
The protocol handles the execution layer: intent → actions. Once the intent is declared, every device that registered as relevant participates automatically. Add a new light and it joins the response. Remove a device and the system adapts. No rules to rewrite.

Why this matters beyond the home

The event/intent separation is not a smart home concept. It's an architectural pattern for any system where AI needs to act on physical infrastructure.
In a factory: a temperature sensor fires threshold_exceeded on a critical component — that's an event. The AI reasons about it: abnormal reading, production line active, no scheduled maintenance — and determines execute_safe_shutdown. That's an intent. The execution is then coordinated automatically across the line: equipment powers down in sequence, the supervisor is paged, a maintenance request is logged, cooling activates. None of those responses were hardcoded for that specific sensor reading. Each system declared what it could do, and the protocol assembled the response.
The pattern is always the same: the AI reasons about meaning, the infrastructure handles coordination. The temperature sensor does not know about the cooling system. The cooling system does not know about the sensor. The protocol coordinates both.

How DoSync implements this separation

In DoSync, the separation is structural. Events flow in from sensors and adapters — raw, factual, carrying no prescription. Intents flow out from AI agents — meaningful, goal-oriented, carrying no implementation.
The hub sits in between: it receives intents, resolves them against every device's declared Capability Manifest, and builds an action plan at runtime. The resolver never sees the original event. The sensor never sees the resulting actions. The layers are cleanly decoupled.
That decoupling is what makes the system extensible by design. A new device joins the network, declares its capabilities, and automatically participates in every relevant intent — without any rule being written, without any configuration being changed.
That's the architectural difference that matters.

DoSync Protocol: https://github.com/giulianireg-spec/dosync-protocol
License: Apache 2.0

Why AI Agents Like Hermes Need a Semantic Execution Layer for the Physical World

Rodrigo Giuliani — Sat, 23 May 2026 16:20:14 +0000

This is a submission for the Hermes Agent Challenge: Write About Hermes Agent

Most AI agents interact with the world through APIs, databases, and web services. The feedback loop is fast and forgiving — if something goes wrong, you retry.
Physical environments are different. A light that turns on twice isn't a problem. A door that unlocks at the wrong time is. An agent operating in the physical world needs not just reasoning capability, but a clear contract between what it decides and what actually executes.
This post is about that contract — and why Hermes Agent's architecture makes it a natural fit for physical systems.

What makes Hermes Agent relevant here

Hermes Agent has three characteristics that matter specifically for physical environments:
Native MCP support. Hermes connects to external systems via Model Context Protocol natively. Any hub or device layer that exposes an MCP server becomes immediately accessible — no custom integrations, no bridges.
Multi-step tool use with context. Hermes doesn't just call tools — it reasons about which tool to call, in what order, based on context. For physical systems where the right action depends on time, location, and state, this matters.
Open weights and local execution. Physical environments often have strict privacy requirements. A system that can run fully local — without sending home sensor data to a cloud provider — is architecturally different from one that can't.
These three properties together describe an agent that can act on physical systems in a way that's both capable and auditable.

The gap it needs to cross

Every physical device protocol was designed around one assumption: a human decides what to do, and a device executes it. The protocols speak in commands — lock.unlock(), light.set_brightness(100).
An AI agent doesn't produce commands. It produces understanding. "The kids just arrived home" is not a command. The translation from that understanding to the right set of device actions — for the specific devices available, in the right context — still has to be written by someone, in advance.
This is where most physical AI integrations break down. The agent reasons correctly and the devices exist, but the translation layer between them is a pile of hardcoded rules that grows more fragile with every new device.
A semantic execution layer inverts this. Instead of the agent knowing how to act, devices declare what they can do and when they're relevant. The agent expresses goals. The infrastructure handles translation at runtime.

An experiment: Hermes + DoSync
I tested this with DoSync Protocol, an open-source hub (Apache 2.0) that implements this semantic layer. Devices register with a capability manifest. The hub exposes a native MCP server.
Connecting Hermes to DoSync required three lines in ~/.hermes/config.yaml:

yaml
mcp_servers:
  dosync:
    command: python3
    args: [/path/to/dosync/mcp_server.py]
    env:
      DOSYNC_HUB_URL: http://localhost:47200
      DOSYNC_TOKEN: <token>

I gave Hermes a single prompt:
It's 18:45 on a Monday. The PIR sensor at the entrance just detected motion.
What does the system do?

Hermes queried the hub state, reasoned about the time and day, identified the appropriate semantic intent (children_arrived_home), and fired it once. Five physical lights turned on. An SMS was sent to the family. The audit log updated with two new SHA-256 chained entries.
What Hermes didn't need to know: which specific bulbs to address, the SMS provider, or the schedule policy restricting this intent to weekday evenings. That knowledge lived in the hub. Hermes expressed a goal — the infrastructure handled execution.

The open question

This experiment raises a boundary question that physical AI deployments will have to answer: where does agent reasoning end and infrastructure policy begin?
Should Hermes decide which intent to fire, or should context mapping be pre-configured? When an agent acts in a physical environment with real consequences, how much autonomy is appropriate before a human needs to confirm?
Hermes Agent's transparency — open weights, observable tool calls, local execution — makes it the right kind of system to explore these questions. You can see exactly what it reasoned and why. In physical environments, that auditability isn't a nice-to-have. It's a requirement.

DoSync Protocol (open source): https://github.com/giulianireg-spec/dosync-protocol
Hermes Agent: https://hermes-agent.nousresearch.com

Why Hardcoded Automations Fail AI Agents

Rodrigo Giuliani — Fri, 22 May 2026 12:39:00 +0000

DoSync Concepts — Part 2 of 5

There's a rule every smart home developer has written at least once:

if motion_detected and time > 22:00:
    turn_on(hallway_light)

It works. It's simple. And it's the foundation of how every major home automation platform thinks about intelligence today.
The problem isn't that the rule is wrong. The problem is what happens when you add an AI agent to the system — and why rules, no matter how many you write, are the wrong abstraction for that job.

The rule-writing problem
Rules are commands in disguise. "If X happens, do Y" is just a delayed command — the human still decided what Y should be, they just decided it in advance.
That works perfectly when you can anticipate every scenario, your device set never changes, and the AI's job is simply to trigger pre-approved responses. None of those assumptions hold in a real AI-augmented environment.
Consider what happens when you add a new device. A smart lock arrives. You register it with your platform. Now you have to go back through every relevant rule and add the lock. Miss one and the system silently does nothing in exactly the scenario where you needed it most.
Or consider an AI that detects unusual temperature patterns in the kitchen — a sensor reading that might mean the fridge compressor is failing. The AI knows something is wrong. But there's no rule for "fridge compressor anomaly," because nobody wrote one. The system does nothing.
This is the brittleness problem: hardcoded automations only respond to situations that were anticipated when the rule was written.

Why AI agents make this worse, not better
The intuitive solution is to write more rules, or smarter rules. Use the AI to generate them. Inspect logs and auto-suggest new automations.
But this misses the architectural problem.
An AI agent doesn't produce rules. It produces understanding. When a vision model detects a fall, it doesn't know it needs to call phone.call("911") and lock.unlock() and alarm.activate("emergency"). It knows there's an emergency. The translation from understanding to commands still has to be written somewhere — by someone — in advance.
The more capable the AI, the more situations it can detect. And every new situation the AI can detect is a new set of rules that needs to be written to respond to it. The rule surface grows faster than anyone can maintain it.

What capability-based discovery changes
The alternative is to shift where the knowledge lives.
Instead of centralizing the response logic in rules, distribute it to the devices themselves. Each device declares what it can do and in what contexts it's appropriate to act:

json{
  "device_id": "lock-frontdoor-01",
  "tags": ["door-lock", "entrance", "emergency"],
  "actuators": [
    { "type": "unlock", "emergency_capable": true }
  ],
  "emergency_capable": true
}

This manifest is not a rule. It's a declaration. The device is saying: I can unlock. I'm relevant in emergencies. I'm at the entrance.
When the AI fires a semantic intent — ensure_safety / emergency — the resolver reads every registered manifest and asks: which devices declared themselves relevant to this situation? It builds the response at runtime, from what's actually available.
ensure_safety [emergency]
→ lock-frontdoor-01 unlock (emergency_capable, entrance tag)
→ alarm-main-01 activate (emergency_capable)
→ wiz-living-01..10 turn_on (light tag, full brightness)
→ notifier-sms-01 notify (communication tag)
All in parallel. No rules written for this scenario.
Add the smart lock tomorrow — it participates automatically in every relevant scenario. No rule rewriting. No code changes. The device brought its own knowledge.

The difference that matters
Hardcoded automations are fragile because they encode knowledge in a central place that can't keep up with change. Every new device, every new scenario, every new AI capability requires human intervention to update the rules.
Capability-based discovery distributes that knowledge to the edges. Devices own their context. The system is resilient to change because adding new capabilities is additive, not a rewrite.
For AI agents specifically, this is the difference between a system that only responds to situations you anticipated and a system that responds to situations the AI can detect — whether you anticipated them or not.

GitHub: https://github.com/giulianireg-spec/dosync-protocol
License: Apache 2.0

DoSync Concepts is a series exploring the ideas behind the DoSync Protocol — the semantic layer between AI agents and physical systems.

What is Semantic Intent? And Why It's Not the Same as a Command

Rodrigo Giuliani — Sun, 17 May 2026 16:34:48 +0000

DoSync Concepts — Part 1 of 5

There's a word that keeps appearing in conversations about AI and the physical world: intent.
We say things like "the AI understood my intent" or "I want the system to infer my intent from context." But when you actually sit down to build something — a smart home, a hospital room, a hotel — you quickly discover that most protocols don't have a concept of intent at all.
They have commands.
And that difference, small as it sounds, is architectural. It changes everything about how you build systems that are supposed to work with AI.

The command model
Every smart home protocol in existence today was designed around one assumption: a human decides what to do, an app translates that decision into a specific instruction, and a device executes it.
Human → App → Command → Device
lock.unlock()
light.set_brightness(80)
thermostat.set_temperature(21)
This is the command model. It works beautifully when the human is in the loop — when someone taps a button, sets a schedule, or writes a rule. The intent is implicit in the human's action. The app just needs to translate it correctly.
The problem starts when you remove the human.

What an AI agent actually produces
When an AI system observes the world — a camera detecting a fall, a sensor registering unusual temperature, a model inferring that nobody is home — it doesn't produce a command. It produces an understanding of a situation.
"There is an emergency."
"The person who lives here has arrived."
"Something is wrong with the refrigerator."
These are not commands. They're semantic descriptions of a state of the world. They describe what is happening or what needs to happen, not how to make it happen.
To translate this into device commands, someone has to write that translation — manually, in advance, for every possible situation, for every device combination. Miss one edge case and the system does nothing. Add a new device and you rewrite the rules.
This is the command gap. And it only becomes visible when you try to add AI to a physical system.

Semantic intent: a different contract
A semantic intent is a structured expression of a goal — what needs to be achieved — without specifying how to achieve it.
Compare:
json// Command (existing protocols)
{
"device": "lock-frontdoor-01",
"command": "unlock",
"duration": 300
}

// Semantic Intent (DoSync)
{
"intent": "ensure_safety",
"urgency": "emergency",
"context": {
"trigger": "fall_detected",
"location": "bedroom"
}
}
The command says: unlock this specific lock for 5 minutes.
The intent says: there is a safety emergency in the bedroom.
The difference isn't just syntactic. It's about who holds the knowledge.
In the command model, the knowledge of which devices to activate and how lives in the app, or in the rules engine, or in the code a developer wrote last year. That knowledge is static. It can't adapt to new devices, new scenarios, or new contexts.
In the intent model, that knowledge lives in the devices themselves — in their Capability Manifests. Each device declares what it can do and when it's appropriate to act. The system assembles the response at runtime, based on what's available.

How DoSync implements this
In DoSync, every device publishes a Capability Manifest when it joins the network:
json{
"device_id": "lock-frontdoor-01",
"tags": ["door-lock", "entrance", "emergency"],
"actuators": [
{ "type": "unlock", "description": "Unlock for emergency access" },
{ "type": "lock" }
],
"emergency_capable": true
}
This manifest is not a command interface. It's a declaration of capability and context. The device is saying: I can unlock. I am relevant in emergencies. I am at the entrance.
When an AI agent fires an intent:
json{
"intent": "ensure_safety",
"urgency": "emergency"
}
The DoSync semantic resolver reads every registered manifest and asks: which devices are relevant to this intent, given their declared capabilities and tags? It builds an action plan automatically — no rules written, no pre-configuration required.
ensure_safety [emergency]
→ lock-frontdoor-01 unlock (emergency_capable, entrance tag)
→ alarm-main-01 alarm (emergency_capable)
→ phone-family-01 call (communication tag)
→ wiz-living-01..10 turn_on (light tag, full brightness)
All in parallel. Under 100ms. No internet. No cloud.
Add a new device tomorrow — a smart siren, a second lock, a notification relay — and it participates automatically in every relevant scenario. No rule rewriting. No code changes.

Why this matters beyond the home
The command gap isn't unique to smart homes. It's structural — it appears anywhere an AI system needs to coordinate physical devices in response to real-world events.
A hospital AI detects a deteriorating patient. It knows there's urgency. But it doesn't know which room equipment to prepare, which staff to page, which doors to unlock for the crash cart. With command-based protocols, an engineer had to anticipate that exact scenario in advance. With semantic intent, each device declares its relevance and the system responds.
A factory line detects an anomaly on a critical component. The AI knows something is wrong. With commands, someone pre-wrote the response. With intent, the devices coordinate a safe shutdown based on their declared capabilities — and the audit log captures every action with a tamper-evident chain.
The protocol is domain-agnostic. The insight is not.

The deeper shift
Here's what semantic intent actually changes, at a philosophical level:
In the command model, the AI is a remote control. It knows the exact sequence of buttons to press. It breaks when a device changes, when a new device appears, or when a scenario wasn't anticipated.
In the intent model, the AI is a coordinator. It expresses what needs to happen. The devices figure out their role. The system is resilient to change because the knowledge is distributed — each device owns its own context.
This is not a small difference. It's the difference between building a system that works today and building a system that can grow.

What comes next
This is the first post in a series exploring the concepts behind DoSync — an open protocol (Apache 2.0) for semantic intent-based communication between AI and physical devices.
In the next post: Why hardcoded automations fail AI agents — and what a system designed from first principles for AI actually looks like.
GitHub: https://github.com/giulianireg-spec/dosync-protocol
License: Apache 2.0

DoSync Concepts is a series exploring the ideas behind the DoSync Protocol — the semantic layer between AI agents and physical systems.

The Missing Layer Between AI Agents and Physical Systems

Rodrigo Giuliani — Fri, 15 May 2026 17:56:57 +0000

There's a fundamental mismatch at the heart of every smart home today, and most people building in this space haven't fully articulated what it is.

It's not a hardware problem. The sensors, locks, cameras, and thermostats we have today are genuinely capable. It's not a connectivity problem — Matter, Zigbee, and Z-Wave do a perfectly good job of letting apps talk to devices. The problem is architectural, and it only becomes visible when you try to add AI to the picture.

Let me show you what I mean.

The command gap

Every smart home protocol in existence was designed around a fundamental assumption: a human decides what to do, an app translates that decision into a command, and a device executes it.

Human decision → App → Command → Device
lock.unlock()
light.set_brightness(100)
thermostat.set_temperature(21)

This works perfectly for app-controlled scenarios. Matter is an excellent solution to the problem of letting different brands' apps control different brands' devices. Zigbee and Z-Wave solve real problems in mesh networking and low-power communication.

But AI systems don't think in commands. They think in goals.

When an AI detects a fall, it doesn't know it needs to call lock.unlock() and phone.call("911") and alarm.activate("emergency"). It knows there's an emergency. The translation from "there's an emergency" to the specific sequence of device commands has to be written by a human, device by device, scenario by scenario, in advance.

That translation layer is fragile. It breaks when you add a new device. It fails to anticipate scenarios. And in emergencies — where the system should be most reliable — it's exactly the layer most likely to have a gap.

Why this matters now

For the last decade, this wasn't a real problem. Smart home automation was primarily rule-based: "if motion sensor triggers after 10pm, turn on the hallway light." Rules are commands. The mapping was trivial.

But the emergence of capable AI agents changes the equation entirely. We now have systems that can:

Detect that an elderly person has fallen from camera footage
Infer from sensor data that a fridge compressor has failed
Understand from context that "nobody is home" without a button press
React to a smoke detector with a phased evacuation response

These are goal-oriented events, not command-oriented ones. And every existing protocol forces you to pre-write the translation between "goal" and "command" yourself. There is no standard interface for saying "ensure her safety" and having the home figure out the rest.

This problem isn't limited to the home. Consider a manufacturing line: a temperature sensor detects an abnormal reading on a critical component. The AI system knows there's an anomaly — but it doesn't know whether to stop the line, alert the supervisor, activate cooling, trigger a maintenance request, or all of the above. With existing protocols, an engineer had to anticipate this scenario and write that rule in advance. Miss one edge case and the system does nothing. With a semantic protocol, each device declares its capabilities and the resolver determines the appropriate response based on urgency and context — without any pre-written rules for that specific failure mode.

The same architectural gap exists in hospitals, hotels, smart buildings, and anywhere an AI needs to coordinate physical systems in response to real-world events.

What a semantic protocol actually needs

I've been working on this problem for several months, and the design space is clearer than it looks. A protocol that can bridge AI goals and physical devices needs a few specific things:

1. Capability-based device registration

Instead of a device waiting to receive commands, it announces what it can do when it joins the network:

{
  "device_id": "lock-frontdoor-01",
  "tags": ["door-lock", "entrance", "emergency"],
  "actuators": [
    { "type": "unlock", "emergency_capable": true },
    { "type": "lock" }
  ],
  "emergency_capable": true
}

This manifest lets the system discover what's available without any pre-configuration. Add a new device and it participates automatically in every relevant scenario.

2. Semantic intent, not commands

The AI layer submits an intent — what it wants to achieve — not a specific sequence of commands:

{
  "intent": "ensure_safety",
  "urgency": "emergency",
  "context": {
    "trigger": "fall_detected",
    "location": "bedroom"
  }
}

A semantic resolver then matches this intent against the registered device manifests, determines which devices are relevant, and builds an action plan. The AI doesn't need to know what devices exist.

3. Emergency override without confirmation

For urgent situations, the system must be able to act immediately. This means emergency_capable devices bypass the normal confirmation flow. Every action is logged with a tamper-evident chain — but the action executes without waiting.

4. Transport agnosticism

A semantic protocol should be independent of the physical layer. Whether devices communicate over WiFi, Zigbee, Z-Wave, BLE, or Thread should be an implementation detail, not an architectural constraint.

DoSync: a working implementation

I built a reference implementation of these ideas called DoSync Protocol (Apache 2.0). It's not a theoretical spec — there's a running hub, a web dashboard, a certification CLI, and hardware adapters.

Here's what happens when the system receives an emergency intent:

PIR sensor detects motion → gpio_adapter fires ensure_safety [emergency]
    → Semantic resolver scores all 23 registered devices
        → 10 Philips WiZ bulbs: turn_on at full brightness (WiZ UDP adapter)
        → HA lock: unlock for 5 minutes (Home Assistant adapter)  
        → Alarm: activate emergency pattern (simulated)
        → SMS: sent to emergency contact (Twilio)
        → Audit log: SHA-256 chain updated
All in under 100ms. No rules written. No pre-configuration.

The current hardware setup runs autonomously on a Raspberry Pi 5 with a PIR motion sensor and DHT22 temperature sensor. The hub survives reboots via systemd. Any LLM with MCP support (Claude, ChatGPT, etc.) can control the hub through a native MCP server.

What this doesn't solve

I want to be honest about the limitations, because I think intellectual honesty is what makes a protocol worth taking seriously.

DoSync is a protocol of application layer, not transport. It runs over HTTP/WebSocket today. It doesn't replace Zigbee or Z-Wave at the radio level — it sits above them and abstracts them.

The semantic resolver is simple. Today it's a capability matching algorithm that scores devices by tags, urgency, and emergency_capable flag. It works well for the scenarios we have, but a production-grade resolver needs to go further.

The current algorithm asks: which devices have the right tags and capabilities for this intent? A mature resolver would also ask:

Device state awareness — don't unlock a door that's already unlocked, don't turn on a light that's already at full brightness
Competing priorities — if two intents fire simultaneously (morning routine + motion detected), which takes precedence and how do they compose?
Contextual weighting — a motion sensor in a bedroom at 3am carries different weight than the same sensor at 3pm
Learned patterns — over time, the resolver should know that in this home, "save energy" means turning off the living room lights but never the hallway

The resolver interface is already decoupled from the rest of the protocol — you can implement a more sophisticated one without touching the adapter layer or the audit system. The spec defines what a resolver must do, not how. That's intentional. I plan to document this interface formally in v0.2 so that third-party resolver implementations can be dropped in. A production deployment might use a small local LLM as the resolver itself — the protocol is designed to support that path.

There is no hardware certification process yet. The CLI generates a signed JSON report, but there's no third-party review. That's the right long-term model — it's just not there yet.

It's one person's implementation. A protocol needs multiple independent implementations to become a standard. That's the next milestone.

The broader point

Smart home AI is arriving whether the protocol layer is ready or not. Home Assistant added MCP support in 2025. Claude and ChatGPT can already control devices via tool calls. The question isn't whether AI will be integrated into physical environments — it's whether the integration will be done well or badly.

Done badly: AI systems that call device APIs directly, with hardcoded rules, fragile integrations, no audit trail, and no standard for what "emergency capable" even means.

Done well: a semantic layer where devices declare what they can do, AI expresses what it wants to achieve, and the home figures out the rest — with full auditability and a clear certification model for safety-critical scenarios.

The hardware is ready. The AI is ready. The missing piece is a protocol designed from first principles for this use case.

Try it

git clone https://github.com/giulianireg-spec/dosync-protocol
cd dosync-protocol
python3 -m venv venv && source venv/bin/activate
pip install fastapi uvicorn websockets pywizlight aiohttp

PYTHONPATH=. uvicorn server:app --host 0.0.0.0 --port 47200 --reload
# Open http://localhost:47200

The dashboard shows registered devices, live events, and the audit log in real time. The certification CLI runs 16 tests across three tiers. The MCP server lets any compatible LLM control the hub directly.

Feedback, contributions, and adapter implementations are welcome. The RFC process is open.

GitHub: github.com/giulianireg-spec/dosync-protocol
License: Apache 2.0
Contact: giulianireg@gmail.com

DoSync Protocol v0.1 — building the semantic layer between AI and physical systems.

Why Your Smart Home AI Can't Open the Door in an Emergency (And How to Fix It)

Rodrigo Giuliani — Tue, 05 May 2026 16:57:07 +0000

A practical story about the missing protocol between AI and physical devices — and the open-source project building it.

The scenario that started everything

Imagine your grandmother lives with your family. One afternoon, no one is home. She falls in the bedroom and can't get up.

Your home has a smart lock, a camera with AI fall detection, a connected phone hub, and an alarm system. All of them are online. All of them are certified Matter devices. And none of them can coordinate a response — because no standard exists that lets an AI say "ensure her safety" and have every device figure out its role automatically.

The camera can detect the fall. But it can't tell the lock to open. The lock can open, but it doesn't know there's an emergency. The phone hub can call 911, but it doesn't know when to. Each device speaks its own command language, and the AI speaks in goals.

That gap — between AI intent and physical action — is what DoSync is built to close.

The core problem with existing protocols

Matter, Zigbee, and Z-Wave are excellent at what they do: letting apps control devices. They define command clusters like OnOff, LevelControl, and Lock that work across manufacturers. That's genuinely valuable.

But they were designed for human-initiated control via apps. When an AI enters the picture, these protocols become a bottleneck:

# What existing protocols understand
lock.unlock()
light.set_brightness(100)
thermostat.set_temperature(21)

# What an AI actually thinks in
"ensure the safety of the person who fell"
"prepare the home for bedtime"  
"nobody is home — save energy"

Someone has to translate. Today, that translation is custom code written per-device, per-platform, per-scenario. It doesn't scale. It breaks when you add a new device. And it completely fails in emergencies where milliseconds matter.

Introducing DoSync

DoSync is an open communication protocol (Apache 2.0) that lets AI systems interact with physical home devices using semantic intent — expressing what they want to achieve, not how to achieve it.

The key insight: instead of the AI issuing commands, devices declare their capabilities, and a semantic resolver matches intent to capability automatically.

// A device announces what it can do (Capability Manifest)
{
  "device_id": "lock-frontdoor-01",
  "tags": ["door-lock", "entrance", "emergency"],
  "actuators": [
    { "id": "unlock", "type": "unlock" },
    { "id": "lock",   "type": "lock"   }
  ],
  "emergency_capable": true
}

// The AI sends an intent — not a command
{
  "intent": "ensure_safety",
  "urgency": "emergency",
  "context": {
    "trigger": "fall_detected",
    "location": "bedroom",
    "emergency_number": "911"
  }
}

// DoSync resolves this automatically to:
// → lock-frontdoor-01: unlock (emergency_capable = true)
// → phone-hub-01: call 911
// → alarm-01: activate emergency pattern
// → family phones: push notification
// All in parallel. No hardcoded rules.

The 5-layer architecture

DoSync is organized in 5 layers, similar to OSI but designed for AI-to-device communication:

Layer 5 — Intent        AI expresses goals in natural language or JSON
Layer 4 — Semantic      Intent → device action mapping via capability matching  
Layer 3 — Registry      Devices self-declare capabilities on network join
Layer 2 — Secure ch.    mTLS, local PKI, zero-trust — no internet required
Layer 1 — Transport     WiFi · BLE · Zigbee · Z-Wave · Thread · Ethernet

The transport-agnostic HAL (Hardware Abstraction Layer) means the same protocol runs over any physical medium. A manufacturer implements DoSync once and supports any AI system.

What's built today

The protocol is not theoretical. There's a working reference implementation:

git clone https://github.com/giulianireg-spec/dosync-protocol
cd dosync-protocol
pip install fastapi uvicorn

# Start the hub
PYTHONPATH=. uvicorn server:app --host 0.0.0.0 --port 47200 --reload

# Run the full demo — 7 scenarios
PYTHONPATH=. python3 examples/demo_full.py

# Run the certification suite
python3 certify.py --host localhost --port 47200 --tier emergency

The demo output looks like this:

══════════════════════════════════════════════════════════════
  Scenario 1 — Fall detected · Emergency
══════════════════════════════════════════════════════════════
  ▶  Camera emits event: fall_detected [EMERGENCY]
  ▶  AI resolves intent: ensure_safety [EMERGENCY]
  ✓  [lock-frontdoor-01] unlock  → {"status": "unlocked", "duration_seconds": 300}
  ✓  [alarm-main-01] alarm       → {"status": "activated", "pattern": "emergency"}
  ✓  [phone-family-01] call      → {"status": "calling", "number": "911"}
  ✓ SUCCESS  — 7 parallel actions in < 100ms

And the certification CLI:

── Tier EMERGENCY — Override and audit log ─────────────
  ✓  Emergency intent executes without confirmation
  ✓  Emergency-capable devices participate in response
  ✓  Audit log exists and has entries
  ✓  SHA-256 chain integrity verified
  ✓  Emergency event recorded in audit log
── Result ──────────────────────────────────────────────
  Tests passed: 16  ·  Tests failed: 0
  ✓ CERTIFIED — DoSync EMERGENCY
  Fingerprint: fb083f5740978b9a38c448bdc4fe3090…

The 7 working scenarios

The demo covers situations that no existing protocol handles automatically:

Scenario	Trigger	DoSync response
Fall detected	Camera AI	911 called · Door unlocked · Alarm · Family notified
Smoke / CO	Detector over threshold	3 phases: Alert → Evacuate → Unlock for responders
Fridge failure	Compressor off, temp rising	Family SMS before food spoils
Nobody home	Phone WiFi + power meter	Lights off · Thermostat eco · Alarm armed
Laundry done	Appliance cycle complete	Remind family before clothes wrinkle
Good morning	First motion of the day	Blinds 80% · Coffee on · Weather shown
Bedtime	Scheduler at 21:30	Lights dim to 10% · Blinds close

The smoke scenario is worth highlighting because it introduces phased execution — unlike the others that run in parallel, a fire evacuation needs a specific order:

PhasedActionPlan(phases=[
    Phase("ALERT — immediate notification", delay_after_ms=2000, actions=[
        PhaseAction("alarm-main-01",   "alarm",  {"pattern": "fire"}),
        PhaseAction("phone-family-01", "call",   {"number": "100"}),
        PhaseAction("phone-family-01", "notify", {"urgency": "emergency"}),
    ]),
    Phase("EVACUATION — visual guidance", delay_after_ms=3000, actions=[
        PhaseAction("lights-main-01",   "set_brightness", {"brightness": 100}),
        PhaseAction("lock-backdoor-01", "unlock",         {"duration_seconds": 600}),
    ]),
    Phase("ACCESS — entry for responders", actions=[
        PhaseAction("lock-frontdoor-01",  "unlock", {"duration_seconds": 600}),
        PhaseAction("camera-exterior-01", "record", {"reason": "fire_emergency"}),
    ]),
])

Presence inference — not detection

One of the less obvious design decisions: DoSync doesn't treat presence as a binary sensor. It uses an OccupancyEngine that aggregates weighted signals from multiple context providers:

# Phone leaves WiFi network (weight: 0.7)
hub.update_presence(PresenceSignal(
    device_id="phone-rodrigo-01",
    signal_type=ContextSignalType.PRESENCE,
    present=False,
    confidence=0.7,
))

# Hub infers: occupied=False | confidence=100% | signals=1
state = hub.get_occupancy()

When a smartwatch is added, its GPS signal (weight 0.9) combines with the phone WiFi signal for a more robust inference. If the phone battery died but the smartwatch is home, the system correctly infers someone is still there. The AI learns patterns over time — this is the bridge to FamilyOS, the generational AI project that DoSync is designed to power.

The certification model

Following the Matter approach, DoSync uses self-certification with three tiers:

Tier	Requirements
Basic	Connects, authenticates, publishes capability manifest
Standard	Responds to intents, sends events
Emergency	Emergency override + tamper-evident SHA-256 audit log

The CLI generates a signed dosync-cert.json report. No manual approval needed for Basic and Standard. Emergency tier requires human review.

dosync-certify --host 192.168.1.50 --tier standard --output cert.json

The tamper-evident audit log is worth a separate mention: every action chains to the previous one with SHA-256, similar to blockchain. If someone modifies any historical entry, the entire chain breaks and the system detects it immediately.

What's different from Matter, Zigbee, and Home Assistant

Matter solves device interoperability for app-controlled scenarios. It has no semantic layer, no emergency override, and no concept of AI intent. DoSync doesn't replace Matter — a device can be Matter-certified for app control and DoSync-certified for AI interaction simultaneously.

Home Assistant is a platform, not a protocol. It recently added MCP support for natural language, which is directionally similar, but it's adapting an existing command-based system rather than designing from first principles for AI communication.

DoSync is the only open protocol designed specifically for AI-to-device semantic communication, with transport agnosticism, emergency override, capability-based discovery, and a certifiable standard that any manufacturer can implement.

What's next

The Raspberry Pi hardware kit is on order. The next milestone is a physical demo: a real door lock opening in response to a semantic emergency intent. That demo, combined with the working certification CLI, is the artifact we're taking to hardware manufacturers and IoT investors.

The roadmap:

Already shipped: SQLite persistence · 7 working scenarios · REST API · Certification CLI 16/16

Q2 2026 — GPIO adapter for Raspberry Pi · Physical door lock demo
Q3 2026 — Home Assistant bridge · BLE transport adapter
Q4 2026 — 3 certified partner devices · First manufacturer outreach
2027+ — FamilyOS integration · Generational AI memory layer

Try it now

git clone https://github.com/giulianireg-spec/dosync-protocol
cd dosync-protocol
pip install fastapi uvicorn
PYTHONPATH=. uvicorn server:app --host 0.0.0.0 --port 47200 --reload
# Open http://localhost:47200/docs

The interactive API docs let you register devices, fire intents, and see the semantic resolver work in real time — no hardware required.

If you're building IoT firmware, smart home devices, or AI home assistants, I'd love to hear your feedback. The RFC process is open and transport adapter contributions are welcome.

GitHub: github.com/giulianireg-spec/dosync-protocol

License: Apache 2.0

Contact: giulianireg@gmail.com

Update — May 2026

Since this post was published, DoSync has moved from theory to working hardware.

Physical demo live: 10 Philips WiZ bulbs responding to semantic intents
via UDP — no cloud, no intermediary. A natural language conversation with
Claude Desktop controls real lights in real time.

📹 Watch the demo: https://youtu.be/2czAqoIrd08

What shipped since this post:

WebSocket endpoint — real-time event broadcasting to all connected clients
Web dashboard at http://localhost:47200 — live feed, intent launcher, audit log
API key authentication with SHA-256 hashing
Native MCP server — any LLM with MCP support can control the hub directly
Home Assistant bridge — imports devices from HA automatically (10 domains)
Automatic device discovery via UDP broadcast
WiZ adapter — direct UDP control of Philips WiZ bulbs
Full device management CLI (manage.py)
Raspberry Pi kit arrived — GPIO adapter in progress

The MCP integration deserves a mention: with the DoSync MCP server
configured in Claude Desktop, you can type "there's an emergency at home"
and physical lights respond immediately. No app. No command. Just intent.

The door lock demo (the scenario this project was built for) is coming
as soon as the physical lock hardware arrives.

DoSync is part of a larger project: FamilyOS — a private, local, generational AI for the home. The best inheritance we can leave our children is knowledge. DoSync is the protocol that lets the home itself become part of that inheritance.