Changelog

A new task type in the automation schedule: „SEU period comparison”. The system compares the chosen number of most recent periods of an SEU configuration and emails the comparison table (machine and source in rows, periods in columns, percentage change and total change) with a CSV attachment. The numbers are identical to those in the comparison window in the app. When there are not enough periods of similar length, the task is skipped with a clear reason instead of reporting an error.

The report and the comparison can be downloaded as PDF (A4, split into pages) or PNG, with charts exactly as on screen. Files are also stored in the server archive, just like BI dashboard reports.

Next to the percentage change you now see total consumption in each compared period, in the report header and in each source group. Totals are calculated separately for each unit, so kWh are never added to cubic metres.

The SEU report list can be narrowed down to a selected configuration; the choice is remembered together with the other filters.

Selected tiles can be aligned on one horizontal or vertical line, distributed at equal spacing or arranged in a grid. Alignment uses tile centres, so tiles of different sizes line up neatly.

In General configuration you can upload the customer's logo (light and dark version); it is shown in the system header next to the OmniMES logo.

When adding a parameter to a new profile, you can set its unit right away.

You can sign in to OmniMES with your username or email address (case-insensitive) — the same address you use for Redash. Email is required and unique for new accounts, and changing it in the user panel applies to sign-in immediately. Existing logins keep working.

The hint depends on the protocol: MQTT → 1883, encrypted MQTTS → 8883; protocol names are written in capitals.

The MQTT topic name filter now sits in the „Filtering rules” section, with an explanation of how it differs from rules applied to tags. Collapsing the section clears the filters, so discovery is no longer narrowed silently.

JSON queries created with the wizard did not run in Redash in local installations, because Redash tried to connect to itself. Redash settings now include a field with the OmniMES address for Redash, set by default so that local installations work without changes.

Fixed bugs that made filtering rules behave differently from what the configuration specified.

The view showed only events of machines classified from measurements; it now shows events of all machines.

After using measurement-based classification the field stayed locked even after removing the range, so it was impossible to go back to classic state classification.

The configuration of a new profile shows as many segments as the preview.

Typing a new tile size in the planogram editor caused errors.

The summary email arrives on the first day of the month with data for the whole previous month; previously, in 31-day months it arrived on the 30th.

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.