COSMOS

Ball / OpenC3 ground software for commanding and monitoring hardware.

COSMOS 7 keeps every decommutated value in QuestDB, so Plexus reads it as a database connection — no plugin to install in your COSMOS.

Run against COSMOS 7.3.0.

What Plexus reads

Every telemetry packet table, one per packet, with the converted value where COSMOS defines a conversion
Enumeration labels, from the textual converted column beside the numeric code
COSMOS's own limit state per sample — the GREEN, YELLOW_HIGH and RED_LOW it wrote beside each value

What it does not read

Command history. The __CMD__ tables are excluded deliberately: command records are yours and are a different conversation
Anything through the COSMOS API. Plexus talks to the store, not to your instance
Items whose names cannot be safely quoted in SQL — COSMOS names array members with brackets, and rather than widen an injection guard we decline the item

Connecting it

1Publish QuestDB's Postgres-wire port — the COSMOS compose file ships it commented out
2Paste the connection string
3Plexus works out which column holds the real number from the schema

Their documentation: docs.openc3.com

Worth knowing

Limit state is COSMOS's verdict on a single reading, so an oscillating value genuinely enters and leaves its limit. That is not the same as COSMOS's persisted alarm state, which lives in its API.
OpenC3 COSMOS is AGPL-3.0 with addendums, one of which restricts use of the OpenC3 name for publicity. We read a database you point us at; we do not modify or redistribute COSMOS.

If you build it

Plexus is not a replacement for COSMOS. Your console is for the person operating the machine; ours is for the people around them — and for the screen where this system's data sits beside everything else the team runs. If you work on COSMOS, we would rather hear where this page is wrong than have a customer find out.

Get started →Talk to us →