Historia zmian

W harmonogramie automatyzacji nowy typ zadania „Porównanie okresów ZWE”. System sam zestawia wybraną liczbę ostatnich okresów konfiguracji ZWE i wysyła mailem tabelę porównania (maszyna i źródło w wierszach, okresy w kolumnach, zmiana procentowa i zmiana łącznie) z załącznikiem CSV. Liczby są identyczne z tymi w oknie porównania w aplikacji. Gdy brakuje okresów o zbliżonej długości, zadanie zostaje pominięte z czytelnym powodem, zamiast zgłaszać błąd.

Raport i porównanie można pobrać jako PDF (format A4 z podziałem na strony) albo PNG, z wykresami dokładnie takimi jak na ekranie. Pliki trafiają też do archiwum na serwerze, tak jak raporty z pulpitów BI.

Przy zmianie procentowej widać sumę zużycia w każdym porównywanym okresie, w nagłówku raportu i w każdej grupie źródeł. Sumy liczone są osobno dla każdej jednostki, więc kWh nie są dodawane do metrów sześciennych.

Listę raportów ZWE można zawęzić do wybranej konfiguracji; wybór jest zapamiętywany razem z pozostałymi filtrami.

Zaznaczone kafelki można wyrównać w jednej linii poziomej lub pionowej, rozmieścić w równych odstępach albo ułożyć w siatce. Wyrównanie liczone jest względem środków kafelków, więc kafelki różnej wielkości układają się równo.

W Konfiguracji ogólnej można wgrać logo klienta (wersję jasną i ciemną); wyświetla się w nagłówku systemu obok logo OmniMES.

Przy dodawaniu parametru w nowym profilu można od razu podać jego jednostkę.

Do OmniMES można się zalogować nazwą użytkownika albo adresem e-mail (bez rozróżniania wielkości liter), czyli tym samym adresem co do Redasha. E-mail jest wymagany i unikalny dla nowych kont, a jego zmiana w panelu użytkownika od razu obowiązuje przy logowaniu. Dotychczasowe loginy działają bez zmian.

Podpowiedź zależy od protokołu: MQTT → 1883, szyfrowany MQTTS → 8883; nazwy protokołów zapisane wielkimi literami.

Filtr nazwy tematu MQTT jest w sekcji „Reguły filtrowania”, z opisem różnicy względem reguł działających na tagach. Zwinięcie sekcji czyści filtry, więc wykrywanie nie zawęża się już po cichu.

Zapytania JSON tworzone kreatorem nie wykonywały się w Redashu w instalacji lokalnej, bo Redash próbował połączyć się sam ze sobą. W konfiguracji Redasha doszło pole z adresem OmniMES dla Redasha, domyślnie ustawione tak, by instalacja lokalna działała bez zmian.

Poprawiono błędy, przez które reguły filtrowania działały inaczej, niż wskazywała konfiguracja.

Widok pokazywał tylko zdarzenia maszyn klasyfikowanych na podstawie pomiarów; teraz pokazuje zdarzenia wszystkich maszyn.

Po użyciu klasyfikacji na podstawie pomiaru pole pozostawało zablokowane nawet po usunięciu zakresu, więc nie dało się wrócić do klasycznej klasyfikacji stanów.

Konfiguracja nowego profilu pokazuje tyle segmentów, ile widać na podglądzie.

Wpisanie nowego rozmiaru kafla w edytorze planogramu powodowało błędy.

Mail z podsumowaniem przychodzi pierwszego dnia miesiąca z danymi za cały poprzedni miesiąc; wcześniej w miesiącach 31-dniowych przychodził 30. dnia.

Kafelki maszyn można ułożyć w dowolnej kolejności w obrębie linii, zamiast wyłącznie alfabetycznie. Ustawienie jest wspólne dla wszystkich użytkowników i zapamiętywane, a wybór sposobu sortowania (A–Z, Z–A, własna) zostaje przy kolejnym wejściu na ekran.

Nazwę wyświetlaną pod kafelkiem można nadpisać dla jednej maszyny bez zmieniania profilu wspólnego dla wszystkich. Wcześniej jedyną drogą było duplikowanie całego profilu.

Jeśli licznik lub mianownik wskaźnika nie pochodzi z pomiaru (np. liczba wyprodukowanych sztuk z raportu zmianowego), można podać wartość dla danej migawki, a nie jedną stałą dla wszystkich okresów. Do tej pory ta sama liczba trafiała do każdego okresu, przez co trend potrafił pokazywać odwrotny kierunek niż rzeczywisty.

Harmonogram może utworzyć migawkę i oznaczyć ją jako oczekującą na wartość, zamiast podstawiać stałą z konfiguracji. Lista migawek pokazuje, ile okresów czeka na uzupełnienie, a wartość można wpisać wprost z listy.

Zestawienie zużycia per maszyna dla wielu wybranych okresów naraz, ze zmianą względem poprzedniego okresu i podsumowaniem od pierwszego do ostatniego. Porównanie okresów o wyraźnie różnej długości jest blokowane, bo dawałoby mylące wyniki.

Przy automatycznym wykrywaniu sygnałów można zawęzić nasłuch do wybranego tematu MQTT, zamiast przeglądać wszystko, co nadaje broker.

Profile statusów i lista statusów zapisują się dopiero po kliknięciu „Zapisz”, a nie po każdym opuszczeniu pola. Zmienione wiersze są oznaczane, a zamknięcie okna z niezapisanymi zmianami wymaga potwierdzenia.

Wartość bazowa i wskaźnik dla maszyn są rozdzielone ramkami; pola wartości ręcznych opisane są jednostką z definicji wskaźnika zamiast określeniami „licznik” i „mianownik”.

Przy każdej wartości podanej ręcznie zapisywane jest, kto i kiedy ją wprowadził. Wartości ręcznych nie da się odtworzyć z pomiarów, więc przy przeglądzie ISO 50001 muszą być identyfikowalne.

Ekran pokazywał maksymalnie 30 maszyn na linię; przy większej liczbie część kafelków była niewidoczna bez żadnego ostrzeżenia. Teraz zawsze wyświetlane są wszystkie maszyny z linii.

Ustawiony limit był ignorowany i wykrywanie potrafiło zebrać wielokrotnie więcej sygnałów, niż wskazano. Poprawiono też filtry, w których pusta reguła przepuszczała lub blokowała wszystko.

Maksymalna wartość zakresu była po cichu zaokrąglana do liczby całkowitej. Kolumna w bazie została doprowadzona do zgodności z modelem, wraz z brakującymi kolumnami raportów.

Migawki bez kompletu danych trafiały na wykres jako zero, tworząc pozorny spadek; mianownik równy zero dawał wskaźnik równy surowej energii bez żadnego ostrzeżenia. Migawki niekompletne są teraz pomijane na wykresie i blokowane w audytach oraz raportach.

Pole „Następne wykonanie” korzystało z kontrolki przeglądarki, w której w Firefoksie nie dało się wybrać godziny. Wszystkie pola dat w harmonogramie używają teraz tego samego komponentu co reszta systemu.

Po wyborze parametru jednostka uzupełnia się automatycznie, z możliwością ręcznej zmiany.

Dostępne po instalacji: OmniMES wystawia standardowy endpoint MCP na serwerze fabryki. W dowolnym asystencie AI wspierającym MCP (Claude Desktop, ChatGPT, Cursor, Copilot) instalujesz wtyczkę „OmniMES”, wklejasz token dostępu do serwera i gotowe. Z dowolnego komputera w sieci firmowej, w języku naturalnym, budujesz kompletne dashboardy i raporty, konfigurujesz strukturę parku, statusy maszyn, alarmy i harmonogramy, odczytujesz bieżący stan produkcji oraz źródła i punkty pomiarowe OmniEnergy — bez znajomości interfejsu i bez pisania SQL. Przykład z praktyki: jednym poleceniem „zbuduj dashboard z dostępnością, awaryjnością i kosztem energii na sztukę dla parku maszynowego” asystent tworzy kilkanaście zapytań SQL, wizualizacji i gotowy pulpit w Redashu. Model dobierasz świadomie: komercyjny (Claude, GPT, Gemini) — gdy zależy na jakości; darmowy przez OpenRouter (Llama, Qwen, DeepSeek) — gdy zależy na kosztach; lokalny (Ollama, LM Studio) — gdy dane muszą zostać w sieci fabrycznej.

Liczniki (wskaźniki) układają się teraz obok siebie i zawijają automatycznie zależnie od szerokości karty maszyny. Przy ustawieniu „1 maszyna w wierszu” (szeroka karta) mieści się ich wiele w jednym rzędzie, przy większej liczbie maszyn w wierszu zawijają się same.

Usunięto narastające zużycie pamięci i procesora przy przełączaniu serwera / linii / sortowania (poprzednie połączenia z brokerem nie były zamykane). Ekran monitoringu może być teraz otwarty przez długi czas bez zawieszania przeglądarki, także przy dużej liczbie maszyn.

Odporność na błędny zegar bramki lub sterownika PLC. Czas „z przyszłości” (np. +1 h po zmianie czasu letniego lub zła strefa) jest odrzucany na rzecz czasu serwera, więc nie zafałszowuje archiwum ani wyświetlanego stanu maszyny.

Zamiast polegać wyłącznie na sygnałach cyfrowych ze sterownika, stan pracy maszyny (praca / praca jałowa / przezbrojenie / postój) można teraz wyznaczać z progu dowolnego pomiaru analogowego — prądu silnika, ciśnienia hydrauliki, obrotów wrzeciona. Przykład: prąd silnika > 12 A → maszyna pracuje; 3–12 A → praca jałowa; < 3 A → wyłączona. Progi konfiguruje się w konfiguratorze statusów, klasyfikacja działa na żywo w Monitoringu i jest zapisywana w historii, dzięki czemu OEE, MTBF i raporty produkcyjne uwzględniają faktyczny stan maszyny bez potrzeby doprowadzania dodatkowych sygnałów binarnych z PLC.

Zamiast MongoDB — szybsze zapytania i wyraźnie mniejsze zużycie miejsca dla telemetrii, przy zachowaniu dotychczasowej funkcjonalności. Przykład: rok telemetrii z ~150 maszyn zajmował w MongoDB ok. 80 GB, po migracji do PostgreSQL + TimescaleDB (z kompresją hypertables) — ok. 7 GB. To ~10× mniej miejsca przy identycznej ilości danych źródłowych i szybszych zapytaniach na oknach czasowych.

Stream OmniMES może teraz przyjmować pomiary bezpośrednio z topików MQTT — nie tylko z ramek Sparkplug B. Ułatwia to integrację ze sterownikami, bramkami IIoT i urządzeniami publikującymi dane w formacie natywnym (JSON lub prosty payload), bez konieczności dokładania warstwy Sparkplug po stronie źródła.

Poprawne przypisywanie statusów po temacie MQTT oraz tagu; naprawiono błędne dopasowania i pobieranie ostatnich zdarzeń.

Powiadomienia w formie Toast oraz zapamiętywanie stanu widoków lokalnie w przeglądarce.