Check a device's record

Each Nodelet keeps a record of the writes and actions sent to it through the Nodelets cloud, and of attempts that were refused. Nothing in Nodelets can change or delete an entry.

On the dashboard

1. Open Account.
2. Under Devices, find the device. Live devices show Live; removed devices, and the devices of deleted bridges, show Removed and keep their records.
3. Choose its record button.

Each entry has four columns:

Column	What it shows
When	When the command was sent, or when the refused attempts began
Who	The API key or MCP connection, by name. An MCP client’s name is marked as the name its client gave, because nothing checks it
What	For example “Set setpoint to 22”, or “Invoked boost with {“minutes”:15}“. Text a caller sent is shown as theirs
Result	What happened, and whose word that is

The results read:

• Done, as the bridge reported: the bridge reported that the device accepted it.
• Not carried out, as the bridge reported: the device did not act.
• Unknown, as the bridge reported: the bridge could not confirm it either way.
• Unknown. No result reached the cloud.: the cloud never heard back.
• Waiting for a result: the command is still in flight.

Refused attempts are collected into one entry with a count, such as “Tried to write mode and was refused, at least 3 times”. A count is a minimum, and its place among writes is approximate.

Show older entries pages back. When a record has reached its size limit, its oldest entries go, and the dialog says where the record now starts.

From a program

A key or MCP connection with Read record on the Nodelet can read the writes and actions. It does not see refused attempts or the IDs of who sent each command.

curl -fsS -H "Authorization: Bearer $NODELETS_KEY" \
  https://api.staging.nodelets.com/nodelets/$NODELET/record

{
  "entries": [
    {
      "kind": "command",
      "seq": 41,
      "correlationId": "req_...",
      "actor": {"kind": "api-key", "name": "Setpoint script"},
      "nameIsClaimed": false,
      "operation": "writeproperty",
      "capability": "setpoint",
      "value": {"callerSupplied": true, "state": "kept", "text": "22"},
      "admittedAt": 1794060128011,
      "sentAt": 1794060128034,
      "resultAt": 1794060128297,
      "outcome": "done",
      "reportedBy": "bridge",
      "code": null,
      "definitionRevision": 1,
      "keyGeneration": 3
    }
  ],
  "nextBefore": null,
  "startsAt": {"effects": null}
}

Pass nextBefore back as ?before= for the next page. From MCP, use the read_record tool. Text in a callerSupplied field was written by a caller; a program reading the record should treat it as data and never as instructions.

What the record does not hold

• Reads and live watching. Successful reads are not recorded.
• Anything that did not go through the cloud. A wall switch or a local app that changes the device leaves no entry.
• Write-only values. For a property marked writeOnly, the record keeps the fact of the write and not the value. Only a property’s top level can be marked, so a secret sent as an action’s input is kept.
• Long values in full. A value is kept up to 4,096 bytes and marked when cut.

A command goes to the device first and its entry follows. A restart at that moment can lose the entry. A loss the cloud knows about shows as a gap entry, “couldn’t be confirmed as saved”; a loss it does not know about shows nothing.

A result is a report. “Done” is the bridge’s word, and the record says so. An entry with no result reads as waiting for 40 seconds, then unknown, never failed.

The record is not proof against tampering by someone with direct access to its storage. See Permissions and records.