Skip to main content

Overview

Publishers are the mechanism by which instro handles data coming from instruments. In the example, we add two Publishers to a InstroDAQ.

Example

Every Measurement and Command is now recorded by each Publisher in publishers. An Instrument will close() all publishers when it closes. Note: Do not attach the same ordinary Publisher instance to more than one instrument. Use SharedPublisher when multiple instruments need to publish to one underlying destination.

Built-in Publishers

instro provides the following built-in publishers.

FilePublisher

Writes measurements and commands to a local file in Avro, CSV, or JSON Lines format. Constructor
Example:
Format tradeoffs:
  • avro (default): Compact binary format. Uses the same schema as Nominal Core ingest, so captured files can be uploaded after the fact without transformation. Recommended for production captures.
  • csv: One row per (timestamp, channel, value, tags) tuple. Good for quick inspection in spreadsheet tools.
  • jsonl: Newline-delimited JSON, one record per publish. Recommended when you want human-readable output: each record is appended and flushed in constant time, and every flushed line is a complete record.

NominalCorePublisher

Sends measurement and command data to Nominal Core datasets. Constructor Parameters:
Example:
A shorthand method to add publishing to Nominal Core is to directly pass in a dataset_rid kwarg. This requires a default profile to have been configured on the system.
backup FilePublisher If you only need a local file as a fallback for when network connectivity to Nominal Core is lost, use the file_fallback parameter on NominalCorePublisher instead of attaching a separate FilePublisher.

NominalConnectPublisher

Streams real-time data to Nominal Connect for live visualization and monitoring during tests that use the Nominal Connect Desktop Application. Nominal Connect apps can also install instro for you; see Using Nominal Connect. Constructor Parameters:
Example, from a typical Connect app:

Attaching Publishers

Publishers can be attached after Instrument construction also.

Custom Publisher

All Publisher implementations follow a simple protocol with two required methods publish and close:
Example The example below prints to the console every time a Measurement is published corresponding to a predefined name.

Publisher Wrappers

Publisher wrappers modify the behavior of other publishers by adding buffering, asynchronous processing, or explicit shared ownership. They are composable.

SharedPublisher

SharedPublisher coordinates shared ownership of one underlying publisher across multiple instruments. The default model is still exclusive ownership: one publisher instance belongs to one instrument. Use SharedPublisher only when multiple instruments must publish to the same file, stream, client, or other sink. Each instrument receives its own SharedPublisher handle. Closing one instrument closes only that handle. The underlying publisher closes after the last shared handle closes. When to use:
  • Multiple instruments should write to the same local capture file
  • Multiple instruments should publish to the same custom sink
  • The underlying publisher owns a resource that should stay open until all instruments finish
Parameters:
Example:
See Publishers: publish shared for a full example.

BasicBufferedPublisher

BasicBufferedPublisher collects data in memory and publishes in batches, reducing the overhead of frequent publish calls. It is the concrete implementation of the abstract BufferedPublisher base, so instantiate BasicBufferedPublisher. When to use:
  • You’re making many small publish calls and want to reduce overhead
  • You want to batch data before sending to a remote service
  • Network or I/O latency is impacting performance
Parameters:
Example:
The buffer is automatically flushed when it reaches capacity or when close() is called, ensuring no data is lost.

QueuedPublisher

Offloads publishing to a background thread, making publish calls non-blocking and preventing slow publishers from impacting instrument operations. When to use:
  • Publishing is slow (network latency, disk I/O) and blocking your test loop
  • You want instrument operations to proceed immediately without waiting for publish
  • You need guaranteed throughput for time-critical measurements
Parameters:
Example:
Using QueuedPublisher can dramatically improve test performance when publishing is a bottleneck. The background thread handles all I/O while your test continues uninterrupted.