Open app

OpenC3 COSMOS

Plexus reads a COSMOS instance directly. There is no plugin to install in your COSMOS, and nothing is ever written back.

COSMOS 7 keeps every decommutated value in a QuestDB it already runs, one table per packet. That store is what Plexus connects to. Verified against COSMOS 7.3.0.

Connect

1. Publish QuestDB's Postgres-wire port

This is the only change you make on the COSMOS side, and it is the step people miss: the COSMOS compose file ships the port commented out. In compose.yaml, under the openc3-tsdb service:

    ports:
      - "127.0.0.1:8812:8812"

Then bring the stack back up. Bind it somewhere Plexus can reach — leave it on localhost only if you are running Plexus on the same host.

2. Find the credential

QuestDB's Postgres user is set in the COSMOS environment as QDB_PG_USER and QDB_PG_PASSWORD. If you have not changed them, they are the OpenC3 defaults.

3. Add the connection

In Plexus, Connections → Add, choose OpenC3 COSMOS under Ground systems, and paste:

postgresql://<user>:<password>@<cosmos-host>:8812/qdb

That is the whole setup. Plexus reads the schema on connect and works out which column holds the real number for each item — you do not map anything by hand.

What Plexus reads

  • Every telemetry packet, one table per packet, using the converted value wherever COSMOS defines a conversion.
  • Enumeration labels, taken from the textual converted column that sits beside the numeric code — so you see OFF, not 0.
  • COSMOS's own limit state per sample: the GREEN, YELLOW_HIGH, RED_LOW it wrote next to the value. Plexus reports COSMOS's verdict rather than forming a second opinion.
  • Command history — one table per command, with the parameters that were sent. This is worth knowing about: COSMOS's own API declines to serve command history on 7.3.0, so reading the store is the only way to get it.
  • Array members. COSMOS names them BRACKET[0]; the subscript is quoted, not dropped.

What it does not read

  • Anything through the COSMOS API. Plexus talks to the store, not to your instance. That is a deliberate boundary, and it is also why command history works at all.
  • The command string and the operator who sent it. Both are in the store, in a JSON column beside every command record, and you can reach them with SQL — but they are text rather than numbers, so no chart picks them up on its own.

Things worth knowing

Limit state is per reading, not per alarm. COSMOS's __L column is its verdict on a single sample, so a value oscillating around a threshold really does enter and leave its limit. That is not the same as COSMOS's persisted alarm state, which lives in its API.

Most command tables are empty, and that is correct. COSMOS defines a table per command whether or not it has ever been sent. Plexus lists them anyway — a command with no history is a truthful empty, not a missing one.

Alerting is not available on this connection yet. Alert rules evaluate telemetry Plexus has stored, and a COSMOS connection is queried where it lives. Dashboards, charts, item browsing and limit states all work.

Licensing

OpenC3 COSMOS is AGPL-3.0 with addendums, one of which restricts use of the OpenC3 name for publicity. Plexus reads a database you point it at; it does not modify or redistribute COSMOS.