Reference · built on requestConnectorBuilding management platforms

KMC Commander

Haystack-tagged devices, points, trends, alarms, and schedules from KMC Commander, with point writes and schedule edits.

About

KMC Commander is the building IoT platform from KMC Controls. It runs in the cloud at app.kmccommander.com and on local gateway boxes, models everything as Haystack tag objects, and talks to equipment over BACnet, SNMP, and Modbus. Its REST API is published as a Postman collection at api.kmccommander.com, with folders for tag queries, networks and devices, profiles, points, schedules and events, alarms and groups, trend graphs, and the project update log.

Through Fibric, an operator queries points by tag, reads current values and trend windows, follows alarmInstance objects, and proposes a point write or a schedule change. You approve. The write returns a jobId you can trace, and the receipt keeps the value it replaced.

This is a reference listing. It documents what Fibric would read from KMC Commander and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Any object by Haystack marker tag through GET /api/objects?q=device, ?q=network, ?q=point, ?q=schedule, or ?q=alarm
  • Boolean tag searches such as q=point and sensor and deviceRef==... through GET /data/objects, the same query the Data Explorer uses
  • The latest curVal of every point in the license through GET /api/points/curvals
  • Trend data for one point and time window through POST /api/points/:id/trends with start, end, and type
  • Alarm instances paged by time frame and date through GET /api/objects?q=alarmInstance&page=&timeFrame=&date=
  • User updates and settings changes through GET /api/project/logs, plus gateway heartbeat through GET /api/device/cloud
  • Whole-project trend files for add-ons through POST /api/project/trends with timeWindow all or perPoint

Proposed actions

  • Target capability: propose a point write through POST /api/points/:id with curVal, priority, and timeout; the response is a jobId for the remoteJob
  • Target capability: propose a schedule object created or updated through POST /api/objects, using an existing schedule's JSON as the template
  • Target capability: propose an alarm object or an alarm notification group through POST /api/objects and POST /api/alarms/users
  • Target capability: propose pushing values into the trending service through POST /batchpointupdate with a licenseKey and a point store

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Rank alarms that need a person

    alarmInstance objects arrive by page and day. The operator groups repeats by device, drops the ones that self-cleared, and proposes which alarm group should be notified.

    With Alarm Triage

  • Close a schedule that leaks runtime

    Schedules and point trends sit behind one tag query. The operator matches equipment runtime to its schedule object and proposes the schedule edit when something runs unscheduled.

    With Schedule Leak

  • Spot a sensor that stopped reporting

    curStatus and hisStatus travel with every value. The operator lists points whose status changed or whose curVal froze and proposes a device check with the trend attached.

    With Sensor Health

Requirements

  • A KMC Commander license, either cloud or a local box, with the host set as the API base
  • A user whose JWT can reach the project, or add-on credentials arranged with CommanderSupport@kmccontrols.com
  • The alarms view role for alarm groups and customer-level groups
  • Point uuids for writes, found by querying point and deviceRef== for the parent device
Authentication
A JSON Web Token sent as an Authorization: Bearer header on every request, copied from the user's Profile, API page or issued by Login as User, Get Assigned Licenses, and Set License; add-on vendors obtain a root token from KMC Commander support.

Limits

  • Writes run first-in first-out; relinquishes run in a separate queue, and a repeat relinquish with the same timeout replaces the earlier one
  • The all-trends project job should run only once at add-on initialization and can take hours on an old project
  • The perPoint trend job returns at most the most recent 2 hours when the requested window exceeds 24 hours
  • The Get Group Users bulk call accepts up to 3000 user ids

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request KMC Commander ↗

Questions and answers

Where does the JWT come from?
For a user, from the bottom-left profile icon in the UI under API, or by calling POST /api/login, GET /users/me/activelicenses, then GET /api/setlicense/{{licenseId}}, which sets the license and returns the token. Add-ons instead call GET /api/projects to receive a fresh JWT per project.
How fast can the API write points?
The documentation states the Write Point call has run upwards of 100 requests per second when the downstream network is healthy. For many writes it recommends schedules and events instead. Each write returns a jobId whose remoteJob records success or failure.
Is there a way to fetch trends for a whole project?
Yes, for add-ons. POST /api/project/trends creates a job that writes a file; timeWindow all is for first initialization only, and timeWindow perPoint with a start per point is the recommended incremental path. Poll the job object until tags.running is false.
Ask about KMC Commander

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.