Changelog

Machine tiles can be arranged in any order within a line instead of alphabetically only. The setting is shared by all users and persisted, and the chosen sort mode (A–Z, Z–A, custom) is remembered between visits.

The name shown under a tile can be overridden for a single machine without changing the profile shared by all of them. Previously the only way was to duplicate the whole profile.

When the numerator or denominator does not come from a measurement (for example the number of units produced, taken from a shift report), the value can be entered for a given snapshot instead of a single constant used for every period. Until now the same figure was applied to every period, which could make the trend point in the opposite direction to reality.

A schedule can create a snapshot and mark it as awaiting a value instead of substituting the constant from the configuration. The snapshot list shows how many periods await completion, and the value can be entered directly from the list.

Per-machine consumption compared across several selected periods at once, with the change versus the previous period and a summary from the first to the last one. Comparing periods of clearly different length is blocked because the result would be misleading.

Automatic signal discovery can be narrowed to a selected MQTT topic instead of scanning everything the broker publishes.

Status profiles and the status list are now saved only after clicking “Save”, not on every field exit. Changed rows are highlighted and closing the dialog with unsaved changes requires confirmation.

The baseline value and the per-machine indicator are separated into framed sections; manual value fields are labelled with the unit from the indicator definition instead of “numerator” and “denominator”.

Every manually entered value records who entered it and when. Manual values cannot be reconstructed from measurements, so they must be traceable during an ISO 50001 review.

The screen displayed at most 30 machines per line; with more than that some tiles were invisible without any warning. All machines of a line are now always shown.

The configured limit was ignored and discovery could collect many times more signals than requested. Filters were also fixed, where an empty rule let everything through or blocked everything.

The maximum range value was silently rounded to an integer. The database column was brought in line with the model, together with missing report columns.

Snapshots without complete data were plotted as zero, creating an apparent drop; a denominator of zero produced an indicator equal to the raw energy with no warning. Incomplete snapshots are now skipped on the chart and blocked in audits and reports.

The “Next run” field used a browser control in which Firefox offered no way to pick the time. All date fields in the schedule now use the same component as the rest of the system.

After choosing a parameter the unit is filled in automatically, with manual override still possible.

Available right after installation: OmniMES exposes a standard MCP endpoint on the factory server. In any MCP-capable AI assistant (Claude Desktop, ChatGPT, Cursor, Copilot) you install the „OmniMES” plugin, paste an access token to your server, and you're done. From any computer on the company network, in natural language, you build complete dashboards and reports, configure the plant structure, machine statuses, alarms and schedules, and read the live production state as well as OmniEnergy measurement sources and points — without knowing the UI and without writing SQL. A real-world example: a single instruction „build a dashboard with availability, failure rate and energy cost per unit for the machine park” has the assistant create a dozen SQL queries, visualizations and a finished Redash dashboard. Choose the model deliberately: commercial (Claude, GPT, Gemini) — when quality matters; free via OpenRouter (Llama, Qwen, DeepSeek) — when cost matters; local (Ollama, LM Studio) — when data must stay inside the factory network.

Counters (indicators) now line up next to each other and wrap automatically depending on the width of the machine card. With the “1 machine per row” setting (wide card) many fit in a single row; with more machines per row they wrap on their own.

Eliminated the growing memory and CPU usage when switching server / line / sorting (previous broker connections were not being closed). The monitoring screen can now stay open for extended periods without hanging the browser, even with a large number of machines.

Resilience against a wrong clock on the gateway or PLC. Timestamps “from the future” (e.g. +1h after a DST change or a wrong timezone) are rejected in favor of the server time, so they cannot corrupt the archive or the displayed machine state.

Instead of relying solely on digital signals from the controller, the machine's working state (running / idle / changeover / stopped) can now be derived from a threshold on any analog measurement — motor current, hydraulic pressure, spindle RPM. Example: motor current > 12 A → machine running; 3–12 A → idle; < 3 A → stopped. Thresholds are defined in the status configurator; classification runs live in Monitoring and is persisted in history, so OEE, MTBF and production reports reflect the real machine state without wiring additional binary signals from the PLC.

Replacing MongoDB — faster queries and noticeably lower storage footprint for telemetry, while keeping the existing functionality intact. Example: one year of telemetry from ~150 machines took roughly 80 GB in MongoDB, and roughly 7 GB in PostgreSQL + TimescaleDB (with hypertable compression) — about 10× less storage for the same source data, plus faster time-window queries.

The OmniMES stream can now ingest measurements directly from MQTT topics — not only from Sparkplug B frames. This simplifies integration with controllers, IIoT gateways and devices that publish in native formats (JSON or plain payload), without requiring a Sparkplug layer on the source side.

Correct status assignment by MQTT topic and tag; fixed incorrect matches and retrieval of the latest events.

Toast-style notifications and per-view state persistence stored locally in the browser.