This site uses cookies for analytics and to improve your experience. By clicking Accept, you consent to our use of cookies. Learn more in our privacy policy.

Signal Format and Examples

PMT signal format: tkn, stn, sens, val

A PMT signal is a small GET or POST result from a starter check, script, job, website, device, application, or process.

The source decides the selected outcome or value. PMT accepts the submitted signal for processing and makes stored signal data available for browser display or API readback.

Keep the signal small. Keep the meaning at the edge.

Get your signal

Core fields

Most useful PMT signals include:

tkn
Where the signal belongs. Treat it as a secret.

stn
The station, site, system, device, or source.

sens
A short stable signal/check name.

val
The submitted state or value.

Why this page exists

This page is the canonical public reference for signal shape and basic examples.

The other PMT pages explain where PMT fits. This page explains what a signal should look like when you are ready to send one.

It is deliberately practical: fields, examples, naming discipline, token handling, and common mistakes.

What it is not

  • not a full API manual
  • not a complete SDK
  • not a promise that every submitted request is stored or displayed
  • not a replacement for check definitions
  • not a place for secrets, logs, or large payloads

For richer integrations, use the API and CLI documentation.

Signal fields

Use only what is needed. Do not turn a PMT signal into a log entry or metadata package.

Field Use Public guidance
tkn Send token Required. Keep it out of public scripts and pages.
pin Optional token PIN Only needed for PIN-protected tokens.
stn Station/source name Use a stable source name. For websites, prefer the canonical host without scheme.
sens Signal/check name Use a short stable string such as backup_result or ssl_window.
val State or scalar value The sender decides the meaning. Webapp rules may display values as states.
tag Short grouping label Optional. Keep short, normally up to three characters.
ts_dt Measurement time Optional. Server timestamp is added when omitted.

State values are conventions

Many PMT checks use simple negative values for display conventions:

  • -1 OK / present
  • -2 needs attention soon
  • -3 needs attention now
  • -4 unknown / cannot determine
  • -5 in progress, where applicable

These are check conventions. The core API accepts the submitted value; it does not decide what the value means.

Scalars are conditions, not noise

A source can also send a scalar value such as free GB, temperature, voltage, latency, water level, or days remaining.

A scalar belongs in PMT when a defined range or threshold makes the value operationally useful.

If the value would not change what someone does, it probably does not belong in PMT.

GET example

GET is useful for constrained senders, one-liners, scheduled tasks, and simple checks.

curl "https://ingress.pmtapi.net/v2/?tkn=$PMT_SEND_TOKEN&stn=server-01&sens=backup_result&val=-1"

Use environment variables or protected configuration for tokens where practical.

POST example

POST JSON is cleaner when a sender can provide structured content.

curl -X POST "https://ingress.pmtapi.net/v2/" \
  -H "Content-Type: application/json" \
  -d '{"tkn":"$PMT_SEND_TOKEN","stn":"server-01","sens":"backup_result","val":-1}'

Keep the payload small. Do not send logs, secrets, or broad telemetry.

Practical signal examples

Examples should answer one question clearly. The source decides the result before sending.

Backup result

stn=server-01
sens=backup_result
val=-1 for success, or -3 for failure where the local check decides that.

Website reachability

stn=example.com
sens=site_reachable
val=-1 reachable, -3 unreachable, as decided by the sender.

Scheduled job

stn=server-01
sens=nightly_job
val=-1 when the job completes. Repeated signals allow absence to become visible in the operator view.

Scalar condition

stn=tank-01
sens=water_level
val=42.5. Webapp rules can display ranges if the value has operational meaning.

WordPress/site care

stn=example.com
sens=wp_backup
val=-1 when the plugin or script reports the selected outcome.

Remote gateway

stn=branch-gw-01
sens=gateway_checkin
val=-1 when the gateway reports. Absence may indicate several causes; PMT does not diagnose which.

Naming discipline

  • Use stable station names.
  • Use short, stable sens names.
  • Do not change the meaning of an existing signal name.
  • Use tag only for short grouping or filtering.
  • Do not put secrets or sensitive customer data in names.

For websites, a canonical host such as example.com is usually cleaner than a full URL.

Cadence and absence

One test signal proves a path. Repeated signals create an expected pattern.

The webapp/operator view can use repeated signals and configuration to make missing expected check-ins visible.

The core API stores and returns submitted telemetry. It does not diagnose why a signal stopped arriving.

Read signal data back

PMT is not only a browser view. Stored signal data can also be queried through the read API for scripts, reports, operational screens, notebooks, or integrations.

Use read tokens for readback. Keep send and read access scoped to the project and purpose where practical.

Latest per station example

curl -X POST "https://egress.pmtapi.net/egress/v3/query" \
  -H "Content-Type: application/json" \
  -d '{"tkn":["$PMT_READ_TOKEN"],"latest_stn":true,"limit":100}'

The read API returns stored values and timestamps. Webapp colour/state interpretation is a display/configuration layer.

What not to send

  • passwords
  • API keys or private tokens
  • raw logs
  • file contents
  • personal data unless there is a documented reason and contract basis
  • large payloads or broad telemetry streams

Prefer small outcomes and scalar values that answer a clear operational question.

Boundaries

  • PMT does not run the check for you unless a separate sender/check does that work.
  • PMT does not discover systems.
  • PMT does not infer cause.
  • PMT does not guarantee storage or display of every submitted request.
  • PMT is not a compliance archive.

It gives selected signals somewhere simple to report.

Use starter checks

Start without writing a script using transparent predefined checks.

Starter Checks

Use your own checks

Send selected outcomes from your own scripts, jobs, apps, websites, or devices.

Your Own Checks

Read data through API / CLI

Query stored signal data from your own tools.

Using the CLI/API

Get your signal

Choose one source.
Send one small result.
Keep the meaning clear.

Get your signal