Skip to main content

get_post_filter

ReferenceAudience: API consumerUse: read back the reader's current post-filter rules

Overview​

get_post_filter reads back the reader's current post-filters — the rules that include or exclude scanned RFID tag data before it is reported to a data endpoint. Each rule matches tag data by pattern (prefix, suffix, or regex) and either reports (INCLUDE) or drops (EXCLUDE) it, scoped to a data endpoint. It is read-only. It is a control-plane (CTRL) command; configure filters with set_post_filter.

This is a CTRL-endpoint command: it is published on the control endpoint (<tenantId>/CTRL/clients/cmnd/<serial>) and answered only there (not on the MGMT/MDM channel). Returning a response requires an active CTRL endpoint (config_endpoint, epType: CTRL, activate: true).

Details​

PropertyValue
Interaction PatternRequest / Response (app publishes a command; device publishes the correlated reply)
State ChangeREAD-ONLY
Required Request Fieldscommand, requestId (no other payload)
Applies ToEndpoint: Control (CTRL). Reader: RFD40 series, RFD90 series
API VersionV1.1 (API Version Reporting)
Relatedset_post_filter, get_operating_mode, config_endpoint

When to Use​

Use get_post_filter to inspect the reader's post-filters:

  • Audit filtering — see which patterns are included/excluded per data endpoint before relying on the tag-data stream.
  • After set_post_filter — verify a filter was applied (the setter's response carries no configuration echo).
  • Confirm none are set — an absent postFilterPayload means no filters are configured (see Response Semantics).

Topic Mapping​

MessageDirectionTopicNote
RequestApp → Reader<tenantId>/CTRL/clients/cmnd/<serial>On the control endpoint. Requires an active CTRL endpoint.
ResponseReader → App<tenantId>/CTRL/clients/resp/<serial>Correlated reply; the in-payload requestId links the twin topics.

Topics follow the pattern <tenantId>/<topic>/<serial> — the tenant id assigned to you at provisioning (a slot you fill in, never a literal), the base topic you configure on the endpoint, and the reader's serial number, which the reader appends itself in its model-prefixed form (for example RFD40-212735201D0053). App → Reader means your app publishes and the reader subscribes; Reader → App means the reader publishes and your app subscribes.

Control commands are answered only on the CTRL endpoint — publishing get_post_filter to the MGMT/MDM command topic produces no reply.

Post-filters act on tag data (post-singulation), distinct from the Gen2 select pre-filters in set_operating_mode that act on the air interface. If control commands time out, confirm a CTRL endpoint is active and activate one with config_endpoint if needed.

See Topics and Channels.

Key Fields​

  • postFilterPayload.postFilter[] (response) — the configured rules; absent when none are set.
  • dataEpType (response) — the data endpoint (DATA_EP1 / DATA_EP2) each rule scopes to. DATA_EP2 targets the DATA2 endpoint, which is currently not supported.
  • matchPattern + matchPatternMethod (response) — what to match and how (PREFIX / SUFFIX / REGEX).
  • reportOperation (response) — INCLUDE (report matches) or EXCLUDE (drop matches).
  • response.code (response) — read this to determine success vs failure. The contract requires it; note the reported success-path omission (see Success without a code). See Response Codes.

Request Payload​

The request is a minimal envelope — just command and requestId. It returns all configured post-filters and takes no parameters.

Request payload
{
"command": "get_post_filter",
"requestId": "abc123"
}

Response Payload​

On success the device returns the envelope (command, requestId, apiVersion, response) plus postFilterPayload when filters are configured. The Example tab shows one DATA_EP1 regex filter.

Response payload
Example: with a filter set
{
"command": "get_post_filter",
"requestId": "abc123",
"apiVersion": "V1.1",
"postFilterPayload": {
"postFilter": [
{
"dataEpType": "DATA_EP1",
"matchPattern": "FFFF",
"matchPatternMethod": "REGEX",
"reportOperation": "INCLUDE"
}
]
},
"response": {
"code": 0,
"description": "Success"
}
}

When no filters are configured, the device omits postFilterPayload entirely:

Response — no filters configured
{
"command": "get_post_filter",
"requestId": "abc123",
"apiVersion": "V1.1",
"response": {
"code": 0,
"description": "Success"
}
}

Response Semantics​

  • postFilterPayload is absent when no filters are set. With no post-filters configured, the device omits postFilterPayload entirely — not even an empty postFilter: []. Treat its absence as "no filters." When filters exist, postFilter[] lists them.

Response Codes​

get_post_filter returns response.code. The codes applicable to this command are below; for the full table see the Response Codes and Correlation and Request/Response Pairing.

CodeDescription
0Success — the post-filter configuration was retrieved (an empty configuration still succeeds).
3Not able to retrieve information (IOT_ERROR_INFO_NOT_AVAILABLE) — the device could not gather the post-filters at this time. Retry after a short delay; if persistent, reboot.
101Default error — generic catch-all.

The contract requires response.code. Readers have been reported to omit it on a successful reply, returning just response: { "description": "Success" } — treat that as success too. See Success without a code.

Examples​

Publish get_post_filter over the CTRL endpoint (with an active CTRL endpoint); the device replies with the current filters. The Response Payload shows a configured filter; the no-filter reply is shown above it. There are no request variants — the command takes no parameters.

Notes and Caveats​

  • Post-filters vs pre-filters. get_post_filter reports post-filters — pattern rules applied to scanned tag data before it reaches a data endpoint (INCLUDE/EXCLUDE). These are separate from the Gen2 select pre-filters in set_operating_mode, which filter on the air interface during inventory. Configure post-filters with set_post_filter.

get_post_filter is a read-only, idempotent getter — safe to poll. Use it to verify a change applied by set_post_filter; it carries no credentials in request or response. For the concept-level view, see Tag Filtering.

Related: 📕 set_post_filter · 📕 get_operating_mode · 📕 config_endpoint · 📕 Tag Filtering · 📕 Response Codes

Was this helpful?