Sparkplug publication and measurement times
Which Sparkplug timestamp should a buyer use to distinguish sample age from publication delay?
Sparkplug 3.0.0 distinguishes the payload timestamp, representing publication time, from metric timestamps associated with captured values. The specification describes metric timestamps as UTC capture times and requires them in birth and data messages. Comparing the two can support a declared delay assessment, but neither field independently establishes clock accuracy or physical measurement time.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Clock synchronization and actual sampling were not verified.
- No independently verified physical outcome, calibration, industrial safety, deletion or complete capture.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Sparkplug aliases and birth-message context
Can a Sparkplug metric alias be interpreted without the associated birth-message mapping?
Sparkplug 3.0.0 permits aliases but requires each alias to be unique across the Edge Node metrics. Birth messages carry the metric name and alias together; subsequent data and command messages using aliases omit the name. A numeric alias therefore needs the applicable birth mapping, including the node context, before a consumer can identify the intended metric.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- The deployed alias assignments and session continuity were not inspected.
- No independently verified physical outcome, calibration, industrial safety, deletion or complete capture.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Sparkplug data types and birth definitions
Can an agent infer a Sparkplug metric datatype from the data message alone?
Sparkplug 3.0.0 requires a metric datatype in NBIRTH and DBIRTH and says it should not be included in subsequent data and command messages. Consumers need the birth definition to interpret the metric consistently. The representation of a value in the payload is not a substitute for the declared Sparkplug datatype and its applicable node or device context.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Actual decoder compatibility and device value semantics were not tested.
- No independently verified physical outcome, calibration, industrial safety, deletion or complete capture.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Sparkplug sequence wrap and message counts
Does a repeated Sparkplug seq value prove that a message is a duplicate?
Sparkplug 3.0.0 uses an Edge Node message sequence in the range 0 to 255 and wraps after 255. NDEATH is excluded from this sequence. A repeated seq value can therefore be expected after wrap and cannot serve as a globally unique message identifier. Reconstruction needs node, session and ordering context as well as the sequence value.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Complete delivery and actual retransmission behaviour were not verified.
- No independently verified physical outcome, calibration, industrial safety, deletion or complete capture.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Sparkplug historical values and live decisions
Can a Sparkplug metric marked is_historical be treated as a current live reading?
Sparkplug 3.0.0 describes is_historical as marking a historical value, including data delivered through store-and-forward or batch collection. The flag separates delayed observations from real-time updates. A consumer must interpret that value with its timestamp and intended use; arrival in the latest message does not make a historical metric current.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Actual sensor state and elapsed delay were not independently measured.
- No independently verified physical outcome, calibration, industrial safety, deletion or complete capture.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Sparkplug explicit null values
Does a Sparkplug metric with is_null mean that its measured value is zero?
Sparkplug 3.0.0 provides is_null to indicate a null metric value, with the value field permitted to be omitted. This is distinct from an actual numeric zero or false Boolean. A consumer must preserve that distinction when evaluating a reading, rather than silently filling an absent value with a successful measurement.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- The reason for the null reading is not independently established.
- No independently verified physical outcome, calibration, industrial safety, deletion or complete capture.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Sparkplug omitted Quality properties
Does an omitted Sparkplug Quality property independently prove a sensor reading is good?
Sparkplug 3.0.0 defines an optional Quality property and requires it when quality is not GOOD. Under that convention, omission represents the default GOOD condition. This is a declaration convention, not an independent sensor or calibration check. Buyers need the producer implementation and measurement evidence before relying on an omitted property as proof of quality.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Sensor accuracy and producer compliance were not verified.
- No independently verified physical outcome, calibration, industrial safety, deletion or complete capture.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Sparkplug death messages and session correlation
Can a delayed Sparkplug NDEATH be applied to a newer birth session without checking bdSeq?
Sparkplug 3.0.0 uses bdSeq to correlate NBIRTH with the corresponding NDEATH. A delayed Will can arrive after a later birth, so consumers must assess the matching session instead of treating arrival order alone as current state. A rebirth request within the same MQTT session retains bdSeq; a new birth message does not by itself prove a new connection.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Actual connection history and delivery order were not inspected.
- No independently verified physical outcome, calibration, industrial safety, deletion or complete capture.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Sparkplug death timestamps and outage timing
Does the timestamp in a Sparkplug NDEATH identify when the node actually failed?
Sparkplug 3.0.0 explains that a Will payload is prepared during MQTT CONNECT, so its original NDEATH timestamp is not a reliable failure instant. Host processing marks the node offline using host time. A Sparkplug-aware broker may replace the timestamp with its attempted delivery time. These times have different meanings and do not independently establish the physical outage instant.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- The actual failure instant and broker replacement policy were not observed.
- No independently verified physical outcome, calibration, industrial safety, deletion or complete capture.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Sparkplug intentional disconnect evidence
Will a clean MQTT disconnect automatically publish the Sparkplug node death message?
Sparkplug 3.0.0 requires an intentionally disconnecting Edge Node to publish NDEATH before sending MQTT DISCONNECT. A clean disconnect suppresses the broker Will, so relying only on the Will would omit that notification. If no DISCONNECT is sent and a later Will duplicates the death notification, the host must use the matching bdSeq to avoid duplicate processing.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Actual shutdown delivery was not observed.
- No independently verified physical outcome, calibration, industrial safety, deletion or complete capture.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Sparkplug node death and child-device state
Does Sparkplug marking every child device offline mean those physical devices have stopped?
Sparkplug 3.0.0 directs the host to mark the Edge Node and its associated devices offline after the applicable NDEATH and to mark their birth metrics STALE. This describes the host view of unavailable data through that node. It is not physical shutdown evidence for each device, which may continue operating while its reporting path is unavailable.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Physical equipment behaviour was not inspected.
- No independently verified physical outcome, calibration, industrial safety, deletion or complete capture.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Sparkplug reorder recovery and missing data
Does a Sparkplug rebirth after a sequence gap recover every missing historical sample?
Sparkplug 3.0.0 recommends a configurable reorder timeout. Where configured, unresolved missing sequence messages at timeout require a rebirth request. Rebirth stops data publication temporarily and sends the complete birth sequence to restore the consumer state. This is not a promise to replay every missing sample or reconstruct the lost interval.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Actual loss, retained history and downstream recovery were not tested.
- No independently verified physical outcome, calibration, industrial safety, deletion or complete capture.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Sparkplug change-only updates and state reconstruction
Can a Sparkplug consumer treat each DATA message as a complete snapshot of every metric?
Sparkplug 3.0.0 requires the birth sequence to expose the metrics for the session and recommends that subsequent DATA messages contain only changed values. Unchanged values need not recur until a new session. Reconstructing state therefore needs the applicable birth values and subsequent changes; a single DATA message is not necessarily a full snapshot.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Completeness of the captured birth and update sequence was not verified.
- No independently verified physical outcome, calibration, industrial safety, deletion or complete capture.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Sparkplug multiple samples in one payload
Can repeated appearances of one Sparkplug metric in a DATA payload be discarded as duplicates?
Sparkplug 3.0.0 permits multiple changes for the same metric within one DATA message when the samples have distinct timestamps. It also requires non-historical metrics in chronological order. A consumer that deduplicates by metric name alone can discard legitimate intermediate samples; interpretation needs the individual timestamps and the historical flag.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Actual sample completeness and clock order were not verified.
- No independently verified physical outcome, calibration, industrial safety, deletion or complete capture.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Sparkplug-aware stored births and current values
Are retained birth messages from a Sparkplug-aware broker guaranteed to contain current metric values?
Sparkplug 3.0.0 requires a Sparkplug-aware broker to store the latest NBIRTH and DBIRTH and expose them on designated retained $sparkplug topics. These remain the original birth messages: later DATA changes do not make their metric values current. The specification explicitly warns consumers to account for those subsequent updates.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- The broker cache and intervening data were not inspected.
- No independently verified physical outcome, calibration, industrial safety, deletion or complete capture.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Sparkplug conformance and command authority
Does Sparkplug protocol conformance prove that command-topic permissions are correctly secured?
Sparkplug 3.0.0 presents its security chapter as non-normative guidance, discussing MQTT client identity, credentials and topic access control. These considerations do not make protocol conformance an independent permission audit. A buyer must inspect the actual broker and application authorization policies for publishing and subscribing to command topics.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Actual broker permissions and command enforcement were not assessed.
- No independently verified physical outcome, calibration, industrial safety, deletion or complete capture.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Sparkplug transient flags and storage evidence
Does Sparkplug is_transient prove a metric was never retained by a downstream historian?
Sparkplug 3.0.0 describes is_transient as identifying a value that should not be stored by a historian. That expresses intended treatment of the metric; it does not demonstrate what any downstream consumer actually retained. A buyer assessing storage obligations still needs consumer configuration and retention evidence for each relevant copy.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Downstream storage and deletion were not inspected.
- No independently verified physical outcome, calibration, industrial safety, deletion or complete capture.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
SensorThings server-assigned observation times
Does SensorThings phenomenonTime always come from the sensing device clock?
SensorThings Sensing 1.1 permits a client to omit phenomenonTime when creating an observation. The service must then assign its current server time. A populated phenomenonTime can therefore be a server fallback rather than a device timestamp. A freshness decision needs the submitted observation and timestamp-origin policy, not just the stored field.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Actual observation time and clock accuracy were not inspected.
- No independently verified physical outcome, calibration, industrial safety, deletion or complete capture.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
SensorThings unknown result-generation time
Does a null SensorThings resultTime mean the measurement failed?
SensorThings Sensing 1.1 says that when an observation submission omits resultTime, the service assigns null. That field describes result-generation time, separately from the result value and phenomenonTime. Null therefore does not itself diagnose a failed measurement or supply a generation timestamp; the buyer must seek the missing timing evidence separately.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- The actual generation time and measurement validity remain unverified.
- No independently verified physical outcome, calibration, industrial safety, deletion or complete capture.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
SensorThings device locations and observed targets
Can a SensorThings Thing location be substituted for the location of what was actually observed?
SensorThings Sensing 1.1 distinguishes a Thing location from an observation FeatureOfInterest. In remote sensing, the observed feature may be somewhere other than the sensing Thing. An observation is associated with its FeatureOfInterest, so geographic attribution needs that relation rather than assuming the device location identifies the target.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Actual target geometry and device position were not verified.
- No independently verified physical outcome, calibration, industrial safety, deletion or complete capture.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
SensorThings units and comparable measurements
Can two SensorThings result numbers be compared without their Datastream unit definitions?
SensorThings Sensing 1.1 groups a Datastream by a shared ObservedProperty and Sensor and defines unitOfMeasurement using name, symbol and definition. Unit properties are null for observations without a measurement unit. A number alone does not carry this context; comparison needs the stream definitions and observation types as well as the values.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Unit conversion and instrument equivalence were not validated.
- No independently verified physical outcome, calibration, industrial safety, deletion or complete capture.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
SensorThings deletion and related observation loss
Can deleting a SensorThings Datastream leave all its linked observations intact?
SensorThings Sensing 1.1 deletion rules remove entity relations and specify integrity cascades, including deleting observations linked to a deleted Datastream. Deleting a Sensor or ObservedProperty also deletes linked Datastreams. Buyers should assess these dependencies before removal; API entity deletion does not independently prove erasure of backups or other stored copies.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Actual cascade execution and residual copies were not inspected.
- No independently verified physical outcome, calibration, industrial safety, deletion or complete capture.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
SensorThings bulk creation and per-observation errors
Does SensorThings CreateObservations returning 201 mean that every submitted observation was created?
SensorThings Sensing 1.1 dataArray creation returns 201 with an ordered response array. Each element is the created observation URL or the string error when that individual creation failed. A successful outer status therefore does not establish complete import; buyers need to reconcile each response position with the corresponding submitted observation.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Actual persisted observations and retry safety were not tested.
- No independently verified physical outcome, calibration, industrial safety, deletion or complete capture.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
SensorThings multi-value alignment
Can a SensorThings MultiDatastream result array be reordered without changing its meaning?
SensorThings Sensing 1.1 requires matching size and order across MultiDatastream unitOfMeasurements, ObservedProperties, observation result elements and multiObservationDataTypes. Each position carries corresponding meaning. Reordering one array without the others can associate a value with the wrong property, datatype or unit even if the payload remains syntactically valid.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Actual transformations and sensor values were not validated.
- No independently verified physical outcome, calibration, industrial safety, deletion or complete capture.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
SensorThings batch envelopes and failed operations
Does HTTP 200 for a SensorThings batch establish success of every enclosed request?
SensorThings Sensing 1.1 defines multipart batch responses and includes an example where the outer response is 200 while an enclosed query fails. The outer status must therefore be distinguished from individual operation results. This observation does not establish atomicity for every batch or changeset; the buyer must inspect the applicable operation and transaction rules.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Actual operation persistence and changeset atomicity were not tested.
- No independently verified physical outcome, calibration, industrial safety, deletion or complete capture.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
SensorThings MQTT creation and notification endpoints
Does finding a SensorThings MQTT notification endpoint mean the same endpoint accepts new observations?
SensorThings Sensing 1.1 treats MQTT as an optional extension and advertises supported capabilities through serverSettings. Observation creation and update notifications have separate capability identifiers, and a service supporting both may use different endpoints. A buyer must discover the required capability and endpoint instead of inferring write support from a notification connection.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Actual endpoint availability and write permissions were not tested.
- No independently verified physical outcome, calibration, industrial safety, deletion or complete capture.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
SensorThings MQTT topics and observation ownership
Can the SensorThings MQTT topic determine which Datastream a new observation belongs to?
SensorThings Sensing 1.1 says that when the MQTT topic is a Datastream or FeatureOfInterest navigation link, the new observation is automatically associated with that entity. HTTP creation integrity constraints and specified defaults also apply. Reconciliation must therefore retain the publication topic as well as the payload before attributing the observation to a stream or target.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Actual ingestion and entity association were not inspected.
- No independently verified physical outcome, calibration, industrial safety, deletion or complete capture.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
SensorThings API conformance and access controls
Does SensorThings Sensing conformance establish authenticated access and permission enforcement?
SensorThings Sensing 1.1 states that it does not define specific security capabilities and describes use of existing security mechanisms across the architecture. Its data and operation model therefore does not independently demonstrate authentication or authorization in a deployment. Buyers need the actual service access policy and enforcement evidence for the intended read, create or delete operation.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Actual service identity and permission enforcement were not reviewed.
- No independently verified physical outcome, calibration, industrial safety, deletion or complete capture.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
SensorThings task creation and physical completion
Does creating a SensorThings Task prove the actuator completed the requested physical action?
SensorThings Tasking Core 1.0 describes checking submitted taskingParameters against the corresponding TaskingCapability and creating the Task when they are correct. A Task contains the control-action parameters that should run. This validates the declared task request; it does not independently demonstrate actuator execution or a verified physical result.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Actuator execution and physical state were not observed.
- No independently verified physical outcome, calibration, industrial safety, deletion or complete capture.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
SensorThings pre-provisioned control capabilities
Can a SensorThings Tasking Core client create new actuators or control capabilities as part of submitting a Task?
SensorThings Tasking Core 1.0 limits client creation to Tasks. Other entities, including TaskingCapabilities, Actuators and Things, are pre-provisioned to the server. A client therefore cannot infer capability-provisioning authority from its ability to submit a valid Task under this core specification.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Deployment extensions and actual provisioning permissions were not inspected.
- No independently verified physical outcome, calibration, industrial safety, deletion or complete capture.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
SensorThings task parameter constraints
Can an agent submit arbitrary named fields as SensorThings taskingParameters?
SensorThings Tasking Core 1.0 defines TaskingCapability parameter descriptions and Task values using the SWE Common JSON representation. The capability defines the optional and mandatory parameters, and the server checks submitted parameters against it. Buyers should retain that definition when preparing a task; a plausible field name alone does not establish an accepted control input.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Runtime validation and physical safety of accepted values were not tested.
- No independently verified physical outcome, calibration, industrial safety, deletion or complete capture.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
SensorThings task targets and capability identifiers
What evidence binds a SensorThings Task to the intended TaskingCapability rather than a similarly named control?
SensorThings Tasking Core 1.0 requires each Task to link to one TaskingCapability. Creation can identify it by @iot.id in the request body or through the TaskingCapabilities identifier in the POST URL. Target reconciliation needs the effective identifier and its Actuator and Thing relations; a descriptive capability name is not a substitute for this binding.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Actual target identity and execution were not verified.
- No independently verified physical outcome, calibration, industrial safety, deletion or complete capture.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review