Nemo & Anna — Forget device types. Name your action

The problem

Everything became a device type. Actions never got a name.

Every traditional IoT platform starts the same way: pick a Device Type, then map options and GPIO inside it. The type defines what names are available. If your action doesn't fit an existing type, you borrow the closest one and distort it.

The result: new behaviors get forced into old templates. Nothing is properly defined. The firmware grows, but the intent stays buried.

The problem isn’t how to implement behavior. It’s that we can’t even name it.

The idea

Name the action first. The device follows.

We don't program devices. We define what they are allowed to do. A device is the result of validated actions — not commands.

Instead of selecting a device type and inheriting its structure, you answer nine questions about a single action. That action gets a name. Multiple named actions compose into a device.

1. What is the intended action?2. What physical effect occurs?3. What boundaries must never be crossed?4. In which context is this action valid?5. What event triggers the action?6. What is the goal value?7. What is the maximum execution time?8. What conflicts must be checked before starting?9. What protection conditions apply before stopping?

If you can name an action, you can build it.

How it works

Two primitives. One JSON. One device.

All execution is reduced to two forms: Button (instant pulse) and Switch (persistent state). This is not a limitation. It is what makes every action explicit and controllable. If an action can't be expressed as one of these two, it's a sign the model is over-engineered.

Anna is the JSON language for defining actions. Nemo is the ESP32-C6 firmware runtime that reads Anna JSON and generates a valid Matter device — endpoints, clusters, commissioning, and all.

{   
    "Label": "Keep Warm",   
    "ExecutionEffect": { "HardwareAnchor": 21 },
    "Boundaries": [     
        { "Type": "warning", "Value": "thermal-risk" },
        { "Type": "limit", "Value": "max-continuous-10min" }   
    ],
    "Context": "ArrivingHome",   
    "ResponsibilityLimit": { "MaxDurationSec": 600 } 
}

This JSON becomes a Matter endpoint — with clusters, attributes, and constraints automatically generated. Identity stored in User Label (0x0041). Constraints stored in Fixed Label (0x0040), read-only.

Five firsts in Matter

To our knowledge, no Matter platform has done any of these — let alone all five together.

FirstThe user writes no code at all. No C++, no scripts, no cluster configuration. Nine questions answered in a UI — that is the entire authoring experience.

SecondDevice behavior is defined per action, not per device type. Each action has a name, boundaries, and execution conditions — independently.

ThirdThat definition is expressed entirely in JSON. No manual firmware. No cluster mapping by hand.

FourthSafety boundaries are declared in Fixed Label (0x0040) as manufacturer-defined, read-only constraints. Fixed Label has never been used this way in Matter before — only for physical orientation and UI labeling.

FifthWhen the JSON changes on the server, the device receives the updated definition at the next commissioning — no firmware update, no reflashing.

You can try all of this at anna.software.

What you get

From JSON definition to Matter device — no manual firmware

Answer the nine questions. Write the Anna JSON. Nemo handles Matter commissioning, endpoint generation, GPIO conflict protection, and state management. Behavior changes without rewriting firmware — update the JSON.

Action definitions are machine-readable, making them usable by AI agents and automation systems without hard-coded device logic.

Links

All the firmware and design logic is here.github.com/anna-soft/Nemo-Anna