RPC debug terminal

Who it’s for

Firmware developers and integrators bringing a device up — trying a method before wiring a control to it, checking what a call returns, reproducing a problem a field engineer reported. The tool is a scratchpad for RPC, not a control anyone should be given on a production dashboard.

What it does

The RPC debug terminal lets any RPC method be typed in with its parameters and sent to the device, printing the response in a terminal-style log. Because the method name and payload are entered at send time rather than configured, one widget covers a device’s whole API without a button per call.

• Any method, any payload, typed at the moment of sending — which is exactly what building a control widget requires knowing first.
• The response is printed, so a two-way call’s result is visible rather than being discarded.
• Successive calls accumulate in the log, which makes a sequence of calls and their answers readable as a session.
• Persistent RPC is supported with a polling interval, so a device that acknowledges asynchronously can still be tested here.
• The request timeout is configurable, so a slow link can be distinguished from a device that is not answering.
• The RPC debug terminal is a development tool: it sends whatever is typed with no validation and no guard, so it does not belong on a dashboard that operators use.

How to set up

Data keys

The RPC debug terminal takes no data keys — the method and payload are entered at send time.

Method	Direction	Parameters	Sent when
Whatever is typed	Two-way (request-response)	Whatever is typed	On each send

RPC

Setting	Default	Effect
RPC request timeout	Platform default	How long each call waits, in milliseconds
RPC request persistent	Off	For devices acknowledging asynchronously
Polling interval	Platform default	How often a persistent command’s response is polled

Point the widget at one device and keep it on a dashboard that only developers open. There is no confirmation step and no restriction on what can be sent.

How to customize

• To test a device that answers slowly — raise the RPC request timeout, so a working but slow device is not reported as unresponsive.
• To test asynchronous devices — turn on RPC request persistent and set the polling interval for the command response.

Tips

• Use this widget to discover the exact payload a device accepts, then move the working call into a Command button or an RPC Button. The terminal is for finding out; a configured button is what belongs in front of an operator.
• Keep it on a separate developer dashboard rather than hidden in a state of the operational one. An unrestricted RPC console is one wrong tap away from a command nobody intended, and hiding it is not the same as removing it.