Beyond IT
Remote equipment signals without building an IoT platform
Use PMT where a device, gateway, controller, sensor or process can send one small operational result: normal, fault, unknown, outside range or expected report. PMT makes received states visible without becoming a control system, IoT platform or data lake.
Source → signal → view
Start with one source and one signal that answers a real operational question.
Outcome
Normal, fault, complete, unknown.
Condition
A value inside or outside an acceptable range.
Absence
An expected signal has not arrived.
Before you use PMT outside IT
PMT can be useful beyond computers, but only when the signal is simple, explicit and worth acting on.
PMT may fit if
- the source already knows its own outcome or condition
- one small signal is more useful than broad data collection
- a value can be evaluated against a defined range
- non-reporting is operationally important
- someone can act when the condition becomes visible
PMT may not fit if
- you need rich metadata or changing schemas
- you want analysis, modelling or interpretation inside PMT
- you need a control system or actuator platform
- you need a safety-critical or life-critical system
- you need a compliance archive or system of record
PMT reflects selected signals. It does not interpret the world.
Good non-IT fits
Cold storage temperature condition
Pump or controller state
Remote gateway check-in
Battery or voltage condition
Water level or flow range
Field sensor arrival
Two practical starting paths
Do not start by collecting everything. Start where one signal would change what someone does.
Use an existing source
A controller, gateway, device, script, process or application can send a small GET or POST result to PMT.
The source owns the meaning. PMT centralises the received state.
Add a small check
Where the source does not already report, use a small script or gateway check to evaluate one condition and send one signal.
Keep the check visible, inspectable and easy to remove.
Three signal patterns
Keep the order disciplined: explicit outcome first, scalar condition second, absence last.
Outcome state
A source reports a simple state such as normal, fault, complete or unknown.
Value as condition
A value such as temperature, voltage, pressure or level is evaluated inside or outside an acceptable range.
Expected report
A device, gateway, sensor or process is expected to report on a known pattern. If it does not, absence can be shown.
Useful first signals
These are examples, not promises of coverage. Each signal should answer one clear operational question.
Cold storage
Is the temperature condition still within a range that someone cares about?
Pumps and equipment
Did a controller, pump or device report a usable state, fault state or unknown state?
Remote gateways
Did the gateway, logger or field device send the expected result or check-in?
Battery or power
Is voltage, charge state or power availability outside a range that should be visible?
Process completion
Did a field process, transfer, batch or local routine complete and report a result?
Environmental readings
Is a known sensor reading outside its expected condition, without turning PMT into an analysis platform?
Built for constrained visibility
Beyond-IT use often means mixed ownership, weak links, awkward sites and limited local expertise. PMT fits best where a tiny outbound signal is enough.
Tiny outbound signals
Sources send small HTTP results rather than maintaining heavy telemetry, brokers or remote-control channels.
Separated projects
Use separate projects and scoped tokens for sites, customers, stations, research groups or operational areas.
Browser, mobile and API
View received states in the webapp, use a mobile browser view, or read signal data through API/CLI access.
Field visibility without building a dashboard stack
For equipment, sensors, gateways and field processes, the webapp is the first useful surface: last received value, visible state, mobile access, NOC-style display and stale-state visibility where repeated signals and rules support it. Export and API readback remain available where downstream analysis is needed.
For field and research projects
PMT can fit homogeneous sensor projects where the meaning of each reading is already known, the main operational risk is silent data loss, and interpretation happens later in Excel, pandas, R, MATLAB or another downstream tool.
Keep interpretation outside PMT
The source decides what the signal means.
That source may be a device, gateway, controller, local script, human-defined threshold or downstream process.
PMT makes the received state visible. Calibration, analysis, domain judgement and operational response remain outside PMT.
When a signal needs attention
You do not investigate inside PMT. You use the tools, processes or people that already own the work:
- equipment controls
- site visits
- local logs or sensor tools
- maintenance processes
- spreadsheets or research tools
- operational procedures
PMT makes the received condition visible. Your process decides what happens next.
What PMT does not do
- control equipment
- operate actuators
- calibrate sensors
- validate physical truth
- analyse scientific or operational data
- manage metadata
- collect broad performance metrics
- replace domain tools
- act as a compliance archive
It reflects selected signals and whether they continue.
Why it is deliberately small
Broad collection creates noise.
PMT is designed for selected signals that represent conditions worth seeing.
A useful non-IT setup starts small and grows only where another signal is justified.
If the answer would not change what someone does, it probably does not belong in PMT.
Related starting points
Use these if the non-IT signal is part of a wider operational or technical setup.
Use your own checks
Send selected results from scripts, gateways, devices or processes.
API and CLI access
Read signal data into your own tools, reports or operational views.
Get your signal
Start with one source.
Send one signal.
Replace the test with something real.