add MOS OS as integration

[Cronus89]

I use proxmox and unraid and love the specific integrations Pulse offers. MOS OS is a new NAS type OS that a previous unraid user has created and has an extensive API and modern features.

https://mos-official.net/

[pulse-triage[bot]]

MOS OS monitoring is recorded as a watching, not scheduled request. Which MOS signals would you actually use—such as disk health, pool capacity or backup state—and is there a read-only API reference for them? That distinguishes a useful native integration from data Pulse's host agent can already show.

How Pulse handles triage

[AzAel76]

Answering the triage questions from a MOS user who drives the MOS API daily (two MOS hosts):

Is there a read-only API reference? Yes. Every MOS install serves its own OpenAPI/Swagger reference at
https://<mos-host>/api-docs (REST, base path /api/v1, bearer-token auth). MOS has scoped API tokens
(POST /api/v1/auth/admin-tokens) with a readonly mode: only GET/HEAD requests are allowed, and the
auth/user endpoints are always blocked. A custom mode grants per-resource none/read/write (resource = first path
segment, e.g. pools, disks, system). So Pulse can ask for a read-only token, the same way it asks for a TrueNAS
API key.

Which signals would be used (and the read-only endpoints that already return them):

Pulse area	MOS signal	Endpoint (GET)
Infrastructure	Host, MOS version, CPU, uptime	/mos/osinfo, /system/detailed
Infrastructure	Load, memory, temperatures, network throughput	/system/load, /system/memory, /mos/sensors
Storage	Pools (btrfs, xfs, ZFS, MergerFS, NonRAID): type, data and parity devices, mount state, throughput	/pools?includeMetrics=true, /pools/{id}/status
Storage / health	Parity state: parity_valid, running operation, progress (SnapRAID-style MergerFS and NonRAID pools)	/pools → status
Storage	Disks, partitions, usage, spin state, I/O	/disks, /disks/{dev}/usage, /disks/{dev}/power, /disks/{dev}/iostats
Disk health	SMART per disk	/disks/{dev}/smart
Workloads	VMs (libvirt) and LXC containers with resource usage	/vm/machines, /vm/machines/usage, /lxc/containers, /lxc/containers/usage
Workloads	Docker containers and compose stacks (update status too)	/docker/mos/containers, /docker/mos/compose/stacks (plus a Docker API proxy)
Recovery	LXC backups and snapshots	/lxc/backups, /lxc/snapshots
Power	UPS (NUT)	/nut/status
Alerts	MOS's own notifications	/notifications

Why native rather than the host agent: the agent can already see CPU, memory and plain disks on a MOS box, but
not MOS's own concepts: pool membership and type, MergerFS "vpools", parity validity and progress, MOS notifications,
or MOS-managed VMs, LXC containers and stacks. It's the same reason Pulse talks to TrueNAS through its API rather than
only through the agent.

Suggested shape: a poller modelled on the TrueNAS integration (Settings → MOS → URL + read-only token → test →
~30 s poll), mapping pools/disks to Storage, VMs/LXC/containers to workloads, LXC backups to Recovery and MOS
notifications to Alerts. MOS also documents WebSocket event streams (/pools, /disks, /system, /vm, /lxc) if
push updates are wanted later.

[pulse-triage[bot]]

MOS monitoring remains a watching, unscheduled request; native pool/parity state and MOS-managed workloads are distinct from what the host agent supplies. This adds a second independent demand signal, while the described API and read-only token restrictions remain unverified rather than a supported integration.

How Pulse handles triage