On this page
Subscribe to receive the latest blog posts to your inbox every week.
By subscribing you agree to with our Privacy Policy.
October was about making every dispatch count.
Automated maintenance is supposed to save time and money.
But when work orders follow ticket status instead of what equipment is actually doing, waste creeps in: tickets closed while the alarm is still active, maintenance trips for conditions that have already resolved themselves, and separate visits for issues that could have been handled in one.
October’s headline release tackles that problem directly by anchoring work order decisions to live equipment data. Alongside it, Building BI gains built-in what if analysis, new integrations and API capabilities bring more data in automatically, and the platform’s foundations continue to get stronger.
Here’s what shipped, grouped around the outcomes it delivers.
For organizations running FDD-driven maintenance, the gap between what the CMMS says and what the equipment is doing is where dispatch waste lives.
New Triage Rules in KODE OS close that gap. Work order decisions are now anchored to live sensor data rather than manual ticket status, with five automated rules that reopen, carry forward, hold, or cancel work orders as conditions change:
Rules ship turned off and can be enabled across the entire portfolio or configured building by building, with grace periods, windows, and priority thresholds all adjustable. They apply whether a work order was created automatically by KODE OS or manually by a user, and every action is recorded in the activity log.
In practice: A vendor closes a work order for a rooftop unit’s high supply-air temperature alarm, but the alarm never cleared. Instead of that closure flowing through to invoicing, KODE OS reopens the work order and flags it as a Bad Closure, so the building doesn’t pay for a callback it was already owed.
Dispatch decisions should follow the equipment, not the ticket.
Triage Rules address three of the most common sources of operational waste: closures that aren’t verified, maintenance visits for conditions that no longer exist, and fragmented visits for low-priority issues.
The result is fewer wasted dispatches, cleaner maintenance history, and stronger accountability across vendors and facility management teams, with the biggest impact in large, distributed portfolios such as national retail.
Testing a different target, rate, or baseline shouldn’t mean rebuilding a dashboard.
Building BI now supports Parameters. Datasource authors can define parameters with a display name, description, data type, default value, and an optional list of allowed values, and decide whether each one is required and whether dashboards can override it.
On any dashboard, a new Parameters panel lets users set values with controls matched to each type, including numbers, text, yes/no toggles, dates, and dropdowns. When a parameter is used in a calculated column or metric, changing its value recalculates every widget built on it. Reset returns a value to the datasource default.
Values are scoped to the dashboard, so two dashboards built on the same datasource can run different scenarios without affecting each other, or anyone else.
Scenario comparison becomes a dashboard activity, not a rebuild.
Questions like “what if our target were 10% lower?” can be answered while the conversation is still happening. And cases that once required a separate copy of a datasource for every threshold, target, or rate now collapse into one parameterized source: less to build, less to keep in sync, and less that drifts over time.
October expands KODE OS connectivity across lighting and utility metering.
Zencontrol — Lighting
Stream real-time lighting telemetry into KODE OS, including dimming levels, scene changes, color temperature, override states, and connection status.
Smart Meter Texas — Utility Metering
Automatically discover Texas meters and collect 15-minute interval reads plus daily and monthly billing reads, with no more manual portal exports.
More connected systems mean more data arriving automatically, and less of it gathered by hand.
→ Read the October Integrations Drop for the complete breakdown.
Some of October’s most important work happened beneath the surface.
A more modular Cloud BMS. The Cloud BMS architecture is moving to a hexagonal (ports-and-adapters) design, starting with the Virtual Points module. Separating core logic from infrastructure and external integrations makes the platform more stable and testable, accelerates delivery, and prepares it for deeper integration with AI and machine learning services.
Connector health monitoring. A new end-to-end observability pipeline monitors the health of vendor connectors in real time, with automated alerting that helps detect ingest failures, stream issues, and configuration anomalies before they affect the data teams rely on.
Unified assets and devices. The first phase of a unified asset and device model lays the groundwork for maintenance assets and connected devices to share a single foundation across KODE OS.
October’s releases reinforce a simple idea:
Automation should follow what’s actually happening in the building.
Maintenance teams can let live equipment data verify closures, cancel unnecessary work, and bundle dispatches. Analysts can run what-if scenarios without rebuilding dashboards. And new integrations and a stronger underlying architecture keep more data flowing in reliably and automatically.
October was about making every maintenance trip count.
Across maintenance, analytics, connectivity, and the platform itself, this month’s releases help teams spend less on work that doesn’t need doing, and more time on the decisions that matter.
Verified closures. Fewer maintenance trips. Smarter decisions.
News, insights and resources from the world of smart building management.
By clicking "Sign Up" you're confirming that you agree with our Terms and Conditions.
