Persistent RPC table

Who it’s for

Anyone commanding devices that are not always connected — battery sensors that wake on a schedule, cellular equipment with intermittent coverage, anything where a command is queued rather than delivered. The question is which commands are still waiting, which were delivered, and which failed.

What it does

The Persistent RPC table lists queued and completed RPC requests for the entities an alias resolves to, showing each request’s id, message type, status and method. Requests can be inspected in detail, resent, or deleted from the queue, so a command stuck against an offline device can be dealt with rather than waited on.

• Visibility into the queue — persistent RPC is otherwise invisible until it either arrives or expires.
• Resend and delete are actions on the row, so a failed command is retried and an obsolete one is removed without going near the API.
• Request details show the full record, including the payload and the response.
• A filter narrows the list, which matters on a device that has accumulated a long command history.
• The columns shown are configurable, defaulting to request id, message type, status and method.
• The Persistent RPC table shows the queue, not the device: whether a command achieved anything is a question for the device’s own telemetry.

How to set up

Data keys

The Persistent RPC table takes no data keys — it lists RPC requests for the entities its alias resolves to.

Method	Direction	Parameters	Sent when
The request’s own method	Two-way (request-response)	The request’s stored payload	When an existing request is resent from the table

Table

Setting	Default	Effect
Columns to display	rpcId, messageType, status, method	Which request fields appear as columns
Default sort order	-createdTime	Newest first
Display request details	On	Opens the full request record
Allow send RPC request	On	Shows the resend action
Allow delete request	On	Shows the delete action
Enable filter	On	Lets the reader narrow the list
Default page size	10	Rows per page

Point the alias at the devices whose commands this table is for. The delete action removes queued requests, so a table scoped more broadly than intended can discard commands nobody meant to cancel.

How to customize

• To show more of each request — add columns under Columns to display.
• To make it read-only — turn off Allow send RPC request and Allow delete request for a monitoring board.
• To find a specific command — leave Enable filter on so the list can be narrowed by status or method.
• To fit the tile — set the Default page size and the page step settings.
• To open on the oldest first — change the Default sort order, which is useful when working a backlog rather than watching new commands.

Tips

• Put this table beside the widget that issues the commands. A persistent command gives the operator no feedback at the moment of sending, and the queue is the only place the outcome is visible.
• Clear expired requests rather than leaving them to accumulate. A device that has been offline for a week collects a queue that all delivers at once on reconnection, which is rarely what anyone wanted by then.