Home
Startseite für Projektzustand, aktive Incidents, Kameragesundheit und aktuelle Warnungen.
Details und Funktionen
JC Thermal Monitor im Detail
Diese Seite beschreibt die wichtigsten Bedienseiten und Systemfunktionen für Fachanwender, Integratoren und potenzielle Kunden, die JC Thermal Monitor als Monitoring-Produkt, Pilotinstallation oder temporäre Diagnoseplattform genauer bewerten möchten.
Systemziel
Thermische Zustände überwachen, Testbedingungen bewerten und Befunde nachvollziehbar dokumentieren.
JC Thermal Monitor ist ein On-Premise-System für industrielle Anlagen und technische Diagnoseprojekte, bei denen thermische Zustände über Zeiträume beobachtet, ausgewertet und als Entscheidungsgrundlage dokumentiert werden sollen. Die aktuelle Zielintegration ist FLIR AX8. Das System verbindet Kamera- und ROI-Daten, digitale Signale und Modbus-nahe Zustände mit Alarmregeln, Incidents, Snapshot-Evidenz, Evidence Reports, Tickets, Viewer-Monitorzugriff und Diagnoseinformationen. Es kann neben einem bereits vorhandenen AX8-System installiert werden, weil der normale Monitoring-Betrieb die Kamera-Register liest und die bestehende Anlagenfunktion nicht ersetzt. Nur bei digitalen Ausgängen muss eindeutig festgelegt werden, ob die Kamera beziehungsweise das bestehende System oder Thermal Monitor denselben Ausgang steuert.
Spot- und Box-ROIs werden weiterhin in der AX8-Weboberfläche aktiviert und positioniert. Nach dem ROI-Sync erscheinen die dort freigegebenen Messpunkte in Thermal Monitor und können in Conditions und Actions verwendet werden. Rules können dabei ROIs und DI/DO-Signale aus mehreren getrennten Kameras kombinieren. So entsteht ein echtes Multikamera-System mit Datenbankhistorie für Temperaturwerte, Ereignisse, Incident-Status, Ticket-Status, Reports und exportierbare Visualization-Auswertungen.
ZielgruppeInstandhaltung, Betreiber, Integratoren, technische Leitung
KameraFLIR AX8 als aktueller Schwerpunkt
Installationlokaler Server mit Datenbank und Hintergrundprozessen
Bestandssystemeparallel betreibbar, Monitoring liest Kamera-Register
ROI-SetupSpot und Box in der AX8-Weboberfläche, Nutzung nach Sync
Rule-LogikROIs und digitale Signale aus mehreren Kameras kombinierbar
ProjektformPilot, temporäre Diagnoseplattform oder kundenspezifische Anlage
Zugriffrollenbasiert, inklusive Viewer-Monitoransicht
Bedienoberfläche
Wichtige Seiten und ihre Aufgaben.
Die folgenden Einträge sind Links zu den Detailbeschreibungen der jeweiligen Seite. Die Screenshots zeigen die wichtigsten Oberflächen und Aufgaben im System.
Projects
Verwaltung von Projekten, Projektstatus, Berichtsdaten und Standard-Sampling.
Locations
Standorte, Gerätezuordnung, Endpoint-Einstellungen, ROI-Synchronisierung und ROI-Speicherung.
Discovery
Netzwerksuche, Known-Status und Zuordnung erreichbarer Geräte zu freien Locations.
Rules
Konfiguration virtueller Alarmregeln mit Bedingungen, Filtern, Aktionen und Laufzeitstatus.
Incidents
Bearbeitung aktiver und abgeschlossener Incidents mit Verlauf, Evidenz und Snapshots.
Tickets
Untersuchungsworkflow für Incidents mit Checkliste, Notizen, Messwerten und Anhängen.
Users
Adminbereich für Benutzer, Rollen, Aktivstatus, Bearbeitung und Passwort-Reset.
Snapshots
Snapshot-Jobs, gespeicherte Bilder, annotierte Belege und Bereinigung.
Health
Operational Health für Kamera, ROIs, Regeln, Worker, Impuls Runtime, System Incidents, E-Mail und Snapshot-Jobs.
Visualization
Gemeinsame Zeitachse für Temperaturreihen, digitale Signale und Incident-Marker.
Settings
Laufzeitparameter für Polling, Anzeige, Auto-Refresh, Reportdaten, E-Mail und Diagnose.
Screen Details
Was auf den einzelnen Seiten passiert.
JC Thermal Monitor
Home
Die Home-Seite ist die tägliche Einstiegsseite für Betreiber und Operatoren. Sie zeigt, ob das ausgewählte Projekt thermisch ruhig läuft, ob Incidents offen sind und ob Kameras oder Hintergrundprozesse Aufmerksamkeit benötigen.
Funktionen
- aktuelles Projekt und wichtigste Betriebszustände auf einen Blick prüfen
- aktive Incidents und kritische Warnungen schnell erkennen
- neuste Snapshots und relevante Ereignisse direkt öffnen
- Login, Logout, Passwortwechsel und Viewer-Monitorzugriff im normalen Bedienfluss berücksichtigen
Angezeigte Daten
- Projektname, aktive Incidents, Kamerastatus, Health-Warnungen
- letzte Snapshot-Belege und zeitliche Hinweise
- Hinweise zu Passwortwechsel, Login, minimaler Home/Login-Ansicht und Viewer-Zugriff
Help-basierte Details
Diese Punkte spiegeln die aktuellen Help-Texte der Anwendung wider und beschreiben die wichtigsten Felder, Buttons und Laufzeitregeln dieser Seite.
Login und Passwort
- Username und Password melden den Benutzer für rollenbasierte Seiten an; ohne Login bleibt nur die minimale Home/Login-Ansicht sichtbar.
- Bei einer neuen lokalen Datenbank existiert für die Inbetriebnahme das erste Konto admin mit Passwort admin; dieses Passwort muss anschließend geändert werden.
- Login aktualisiert Menü und Berechtigungen passend zur Rolle.
- Current password und New password erscheinen beim erzwungenen oder freiwilligen Passwortwechsel.
- Change password speichert das neue Passwort und entfernt die Passwortwarnung, wenn das aktuelle Passwort stimmt.
- must_change_password zeigt in V1 eine Warnung, blockiert aber autorisierte Arbeit nicht.
- Logout beendet die Sitzung und kehrt zur minimalen Home/Login-Ansicht zurück.
- Auto-Logout nutzt für Admin, Operator und Technician das Inaktivitätslimit aus Settings; Viewer Sessions verwenden die Viewer Session Lifetime.
- Ohne Login lädt Home keine operativen Projekt-, Snapshot-, Kamera-, Incident- oder Health-Daten.
Dashboard-Karten
- Die Karten verwenden immer das aktuell ausgewählte Projekt.
- Sie zeigen aktive Incidents, Device-Status, aktuelle Alarmaktivität, Snapshots und Health-Hinweise.
- Zähler und Warn-Badges dienen als Navigationshinweise zu den verlinkten Detailseiten.
- Top Health Warnings listet die wichtigsten Worker-, Device-, ROI-, Rule-, Action- und Runtime-Warnungen.
- Latest Snapshots öffnet gespeicherte Snapshot-Dateien oder führt zur Snapshots-Seite, wenn kein direkter Dateilink vorhanden ist.
- Stale Worker, Offline Devices, fehlende ROI-Messungen, fehlgeschlagene Actions und Snapshot-Backlog werden normalerweise in Health untersucht.
- Ein Projektwechsel in der oberen Navigation ändert den Kontext für Rules, Incidents, Tickets, Health, Snapshots und Visualization.
JC Thermal Monitor
Projects
Projects ist die Ebene, auf der Kunden, Anlagen, Standorte oder Pilotinstallationen sauber voneinander getrennt werden. Ein Projekt bündelt Locations, Regeln, Incidents, Tickets, Reports und Visualisierung.
Funktionen
- Projekte erstellen, umbenennen, aktivieren, deaktivieren oder bereinigen
- Standard-Messintervall und projektspezifische Reportdaten pflegen
- aktive und archivierte Projektzustände unterscheiden
- Clear Data für deaktivierte Projekte nutzen, bevor ein endgültiges Delete möglich ist
Angezeigte Daten
- Name, Beschreibung, Aktivstatus, Sampling-Vorgaben
- Reportfelder wie Kunde, Abteilung, Standort, Logo, Zeitzone und Footer
- externe Statusinformationen und Hinweise zu abhängigen Daten
Help-basierte Details
Diese Punkte spiegeln die aktuellen Help-Texte der Anwendung wider und beschreiben die wichtigsten Felder, Buttons und Laufzeitregeln dieser Seite.
Top actions und Projektkontext
- Refresh lädt Projektliste und sichtbare Projektdetails neu, ohne Daten zu ändern.
- Der Meldungsbereich zeigt Create-, Save-, Enable-, Disable-, Clear-Data-, Delete- und Ladefehler.
- Der globale Project Selector bestimmt das aktuelle Projekt für projektbezogene Seiten und listet nur enabled Projects.
- Disabled Projects bleiben hier für Re-enable, Clear Data und endgültiges Delete sichtbar.
- Use as current setzt das aktive Projekt für die obere Projektauswahl und Seiten wie Rules, Incidents, Tickets, Health, Snapshot Jobs, Visualization und Settings.
Create und Edit project
- Name ist erforderlich, muss eindeutig sein und erscheint in Selektoren, Listen, Reports und projektbezogenen Seiten.
- Description erklärt optional Standort, Linie oder Monitoring-Umfang.
- Default sample period (s) ist die Fallback-Schreibfrequenz für Messwerte, wenn keine Location- oder ROI-spezifische Vorgabe existiert; erlaubt sind 1 bis 86400 Sekunden.
- Create project legt ein neues Projekt an; Edit öffnet das Detailpanel; Save speichert Name, Description und Default sample period.
- Es ist immer nur ein Projekt-Detailpanel geöffnet; ein anderes Edit schließt das vorherige Panel.
- Close klappt das offene Detailpanel wieder zu.
- Report-Identität und Project Time Zone werden in Settings für das aktuell ausgewählte Projekt gepflegt.
Enable, Disable, Clear Data und Delete
- Enable macht ein deaktiviertes Projekt wieder für aktive Listen und Runtime zulässig.
- Disable behält die Daten, schließt das Projekt aber von aktivem Runtime Polling und normalen aktiven Projektansichten aus.
- Clear Data ist admin-only, nur für disabled Projects verfügbar und entfernt Messdaten, Incidents, Tickets, Snapshots, Ticket-Attachment-Files, Exporte, Events und Runtime-Status, behält aber die Konfiguration.
- Delete erscheint erst nach Clear Data und nur, wenn keine Runtime-Daten mehr vorhanden sind.
- Delete entfernt danach die verbleibende Projektkonfiguration.
JC Thermal Monitor
Locations
Locations verbinden reale Anlagenbereiche mit Kameras und ROIs. Hier wird sichtbar, welche Kamera einem Standort zugeordnet ist, ob die Runtime aktiv ist und welche Endpoint- und ROI-Einstellungen gepflegt werden.
Funktionen
- Geräte einem Standort zuweisen oder wieder entfernen
- aktive Kamera-Endpoint-Daten wie Name, Seriennummer, IP, Ports, Username und verschlüsselt gespeicherten Passwortstatus pflegen
- FLIR-AX8-ROIs synchronisieren und fehlende ROIs nicht-destruktiv markieren
- ROI-Namen, Beschreibungen, Aktivstatus und Messwertspeicherung pflegen
- digitale Ausgänge zwischen Level- und Impulse-Modus unterscheiden
Angezeigte Daten
- Location, Online-/Offline-Status, Device, Serial, IP, Last poll, Last seen und Last error
- Spot-, Box-, DI- und DO-ROIs mit Präsenzstatus
- Endpoint-Dialog mit HTTP-/Modbus-Port, Username und Passwortstatus
Help-basierte Details
Diese Punkte spiegeln die aktuellen Help-Texte der Anwendung wider und beschreiben die wichtigsten Felder, Buttons und Laufzeitregeln dieser Seite.
Main location table
- New location erstellt eine leere Location im aktuellen Projekt.
- Location ist der Bedienername für Ort, Maschine oder Anlagenbereich.
- Die Übersicht bleibt stabil alphabetisch nach Location-Name sortiert.
- Status fasst online, offline, runtime disabled oder unassigned zusammen.
- Device, Serial, IP, Last poll, Last seen und Last error zeigen Kamera- und Runtime-Zustand.
- Open Camera öffnet die Kamera-Weboberfläche in einem separaten Browserfenster, wenn eine IP vorhanden ist; ein automatischer Login mit dem app-gespeicherten Passwort erfolgt nicht.
- Endpoint öffnet die aktiven Kamera-Endpoint-Einstellungen für die gewählte Zeile.
- Rename ändert den Location-Namen; Sync ROI liest ROI-Definitionen von der Kamera; ROIs öffnet das ROI Panel.
- Disable runtime behält die Device-Zuweisung, schließt das Deployment aber vom automatischen Poller aus; Enable runtime nimmt es wieder auf.
- Unassign entfernt die aktive Device-Zuweisung von der Location.
Endpoint Dialog
- Endpoint öffnet die aktiven Kameraeinstellungen der ausgewählten Zeile, nicht eine globale App-Einstellung.
- Device name und Serial number identifizieren die Kamera; die Seriennummer gehört zur physischen AX8 Kamera, auch wenn die Location wechselt.
- IP address, HTTP port und Modbus port sind die aktuellen Zugriffsdaten für Livebild, Snapshots, Polling und Modbus-nahe Runtime.
- Username wird für Kameraoperationen genutzt, wenn die Kamera Authentifizierung verlangt.
- Password setzt oder ersetzt das verschlüsselt in der App gespeicherte Kamerapasswort; ein bereits gespeichertes Passwort wird nicht wieder angezeigt.
- Clear password entfernt nach Bestätigung nur das gespeicherte Kamerapasswort und lässt Name, Seriennummer, IP und Ports bestehen; normales Save kann das Passwort nicht versehentlich löschen.
- Der Passwortstatus zeigt nur, ob ein Passwort aktuell konfiguriert ist: Password: configured oder Password: not configured.
- Test torch schaltet die AX8 LED/Torch mit gespeichertem Username und Passwort für 5 Sekunden ein und danach wieder aus; es loggt nicht automatisch in die Kamera-Weboberfläche ein.
ROI panel
- Sync ROI im Panel aktualisiert die ROI-Liste der ausgewählten Location aus der Kamera.
- Save all schreibt alle bearbeiteten ROI-Zeilen; Save schreibt nur die jeweilige ROI-Zeile.
- Camera ROI zeigt Kamera-Label, Typ und Index.
- Short name ist ein optionales bedienerfreundliches Label; leere Short names fallen auf das Camera ROI Label zurück.
- Description speichert längere lokale Notizen zum ROI.
- Camera status zeigt, ob der ROI aktuell auf der Kamera existiert.
- ROI enabled steuert Runtime-Nutzung; fehlende Kamera-ROIs können nicht aktiviert werden.
- History enabled steuert Messwertspeicherung für Charts und Reports.
- Store every (s) überschreibt die Messspeicher-Frequenz für diesen ROI.
ROI sync und digitale Outputs
- Digital output mode wird automatisch durch Rules gesetzt: set_output nutzt Level, set_impulse und stop_impulse nutzen Impulse.
- Das Backend blockiert automatische Mode-Änderungen, wenn aktive Actions oder laufende Impulse-Runtime die Änderung unsicher machen würden.
- Discovery weist nur Devices zu; ROI-Zeilen erscheinen nach Device-Zuweisung und manuellem ROI Sync.
- Aktuell wird als DO-Target nur ROI Index 1 unterstützt.
- Der Live-AX8-Adapter unterstützt Spot, Box, DI und DO; Line ROI ist späterer Adapterumfang.
Zusätzliche UI-Ausschnitte
Die Detailbilder ergänzen die kompakte Location-Liste mit ROI-Panel und Endpoint Dialog. Passwörter werden nicht angezeigt, sondern nur als konfiguriert oder nicht konfiguriert markiert.
JC Thermal Monitor
Discovery
Discovery unterstützt Erstinbetriebnahme und Wartung, indem erreichbare Kameras oder Geräte im Netzwerk gesucht, mit bekannten Endpoints abgeglichen und freien Locations zugeordnet werden können.
Funktionen
- Netzwerkscan mit konfigurierbarem Timeout und Hostlimit starten
- gefundene Hosts mit Known-Status und Matched device prüfen
- unbekannte oder bekannte, nicht aktiv zugewiesene Devices einer freien Location zuordnen
- Known-but-not-found Geräte sichtbar machen
Angezeigte Daten
- Scanstatus, gefundene IPs, offene Ports und bekannte Devices
- Zuordnungsauswahl für unassigned Locations
- HTTP Server, HTTP Title und Known-but-not-found Hinweise
Help-basierte Details
Diese Punkte spiegeln die aktuellen Help-Texte der Anwendung wider und beschreiben die wichtigsten Felder, Buttons und Laufzeitregeln dieser Seite.
Scan inputs
- CIDR scannt einen Netzwerkbereich wie 192.168.178.0/24.
- Ports ist eine kommagetrennte TCP-Portliste, typischerweise 80 für HTTP, 554 für RTSP und 502 für Modbus.
- From IP und To IP definieren einen expliziten kleineren IP-Bereich; CIDR und From/To sollten nicht parallel verwendet werden.
- Timeout (ms) bestimmt, wie lange ein Probe auf Antwort wartet.
- Max results begrenzt, wie viele gefundene Hosts in der Ergebnistabelle erscheinen.
- Start scan startet den Scan und füllt die Ergebnisliste.
Assignment und Ergebnisse
- Unassigned location wählt die bestehende Location, die das gefundene Device erhalten soll.
- Refresh lädt die Liste unzugewiesener Locations neu.
- Camera-Login-Daten werden später auf der Locations-Seite im Endpoint Dialog verwaltet.
- Assign erscheint bei unbekannten Devices und bei bekannten Devices, die aktuell keiner Location zugewiesen sind.
- Assign registriert das Device zur ausgewählten Location; neue Zuweisungen sind runtime-enabled.
- Nach erfolgreicher Zuweisung scannt die Seite erneut, damit Known-Status und Action Buttons frisch sind.
- IP, Open ports, Known, Matched device, HTTP server und HTTP title helfen beim Erkennen der Kamera.
- Known but not found listet bekannte Endpoints, die im aktuellen Scanbereich nicht gefunden wurden.
- ROI-Zeilen erscheinen erst nach Device-Zuweisung und ROI Sync auf der Locations-Seite.
JC Thermal Monitor
Rules
Rules ist die fachliche Schaltzentrale der Überwachung. Hier werden aus Messwerten, digitalen Zuständen und zeitlichen Bedingungen nachvollziehbare Alarmregeln mit Aktionen gebaut.
Funktionen
- Regeln projektbezogen erstellen, aktivieren, deaktivieren und bearbeiten
- AND/OR-Logik, Schwellwerte, Delta-Bedingungen, digitale Zustände und Flanken konfigurieren
- Hysterese, Mindestdauer, Cooldown und Filter wie Zählfenster einsetzen
- Aktionen wie Event, Ausgang, Impuls, Impulsstopp, Torch, Snapshot und E-Mail als Action Jobs verwalten
Angezeigte Daten
- Regelname, Schweregrad, Aktivstatus, Condition-Modus
- Bedingungen mit ROI, Metrik, Operator, Grenzwert und Runtime-Zustand
- Aktionen, Reihenfolge, Trigger-Modus, Action-Job-Status, letzter Fehler und Ausführungsstatus
Help-basierte Details
Diese Punkte spiegeln die aktuellen Help-Texte der Anwendung wider und beschreiben die wichtigsten Felder, Buttons und Laufzeitregeln dieser Seite.
Rule editor
- Name ist erforderlich und erscheint in Listen, Incidents und E-Mails.
- Severity ist die Rule-Priorität von 1 bis 10; neue Incidents übernehmen diesen Wert.
- Conditions logic setzt AND oder OR für aktive Conditions.
- Cooldown (s) blockiert eine erneute Aktivierung kurz nach Clear/Deactivation.
- Create rule, Save rule, ENABLED/DISABLED und Delete verwalten die Rule selbst.
Condition editor
- + Add condition öffnet den Condition Editor; Back to conditions und Cancel führen zurück.
- Condition type wählt Direct value, Delta oder Temperature rate.
- ROI, Metric, Operator und Threshold/value definieren den gemessenen Vergleich.
- Delta kann gegen eine zweite ROI oder eine Fixed temperature vergleichen und nutzt die absolute Differenz.
- Temperature-rate nutzt Live Ingest Samples innerhalb des konfigurierten Fensters.
- Threshold time verlangt eine stabile Dauer; Hysteresis reduziert schnelles Umschalten an analogen Grenzen.
- Edge direction reagiert auf rising oder falling digitale Übergänge; sehr kurze Pulse können bei zu grober Ingest Cadence verpasst werden.
Filters
- Filters entscheiden nach true Conditions, ob ein Incident geöffnet oder reaktiviert werden darf.
- V1 unterstützt Schedule, Previous Incident Window und Count Window je Rule.
- Schedule erlaubt Incidents nur an ausgewählten Wochentagen und Zeitfenstern.
- Previous Incident Window kann Aktivität oder Nicht-Aktivität einer anderen Rule verlangen.
- Count Window zählt neue false-to-true Activations innerhalb eines Zeitfensters.
- Die Reihenfolge ist fest: Schedule, Previous Incident Window, Count Window.
- Enabled Filters verwenden AND-Logik; blockiert ein Filter, laufen keine Actions.
Action editor
- + Add action öffnet den Action Editor; Back to actions und Cancel führen zurück.
- Action type wählt create_event, email, set_output, snapshot, set_torch, set_impulse oder stop_impulse.
- Trigger mode legt fest, ob eine Action zum Beispiel on activation oder on clear läuft.
- Die Action-Reihenfolge im Action Job ist automatisch: create_event, set_output, set_impulse, stop_impulse, set_torch, snapshot, dann email.
- set_output setzt eine DO dauerhaft; set_impulse setzt einen temporären Zustand, kann mehrere Pulse ausführen und revertiert automatisch.
- stop_impulse verkürzt die laufende Impulsfolge der ausgewählten DO, sodass sie nach maximal einem weiteren Puls endet.
- set_torch steuert die LED-Lampe der Kamera an der ausgewählten Location.
- Wenn set_torch im selben Action-Lauf auf einen erfolgreich gestarteten set_impulse folgt, wartet der Action Worker 500 ms vor dem AX8-Web-API-Aufruf.
- Für kurze 2-3-s-DO-Impulse auf derselben AX8 sollten set_impulse und set_torch in getrennten, parallel bedingten Rules liegen.
- snapshot plant einen Snapshot Job; Overlay-Werte stammen aus Trigger-Time Runtime ROI Data.
- email nutzt Empfänger, Subject/Body Templates und hängt automatisch Alarmdetails an.
- Action Diagnostics zeigen sent, dry_run, write_error, resolve_error, skips, Impulse Stops, Runtime-Fehler und Jobs mit done_with_errors.
Rules im Detail
Eine Rule verbindet Messwerte, digitale Zustände, Filter und Aktionen zu einer nachvollziehbaren Alarmentscheidung. Betreiber können damit festlegen, wann ein Zustand relevant ist, wann er bewusst unterdrückt wird und welche Reaktion automatisch erfolgen soll.
Rule-Basis
- Name, Projektbezug, Severity, Aktivstatus und Cooldown definieren den Rahmen der Regel.
- Disabled Rules laufen nicht. Disabled Conditions werden bei der Auswertung ignoriert. Disabled Actions verhindern nur die jeweilige Nebenwirkung.
- Cooldown verhindert nach einer Deaktivierung eine sofortige erneute Aktivierung derselben Regel.
Condition-Logik
- AND bedeutet: alle aktiven Bedingungen der Regel müssen erfüllt sein.
- OR bedeutet: eine erfüllte aktive Bedingung reicht aus.
- Eine Regel ohne aktive Bedingung löst nicht aus.
Runtime-Sicherheit
- Threshold time verlangt, dass eine Bedingung eine definierte Zeit lang stabil wahr bleibt.
- Hysterese verhindert schnelles Hin- und Herschalten bei analogen Temperaturgrenzen.
- Temperature-rate verwendet Live-Ingest-Samples, nutzt in V1 feste >=-Logik und hat keine Hysterese oder Threshold time.
- Stale oder fehlende Messwerte werden nicht als sauber erfüllte Bedingung behandelt.
Beispiele für Conditions
Direkter Temperaturgrenzwert
Beispiel: Box 2 - Maximum temperature > 80 °C. Optional mit 30 s Threshold time und 2 °C Hysterese, damit kurze Spitzen nicht sofort einen Incident öffnen.
Delta zwischen Messstellen
Beispiel: |Motorlager links - Motorlager rechts| >= 12 °C. Damit werden untypische Temperaturunterschiede zwischen zwei ROIs sichtbar.
Schnelle Temperaturänderung
Beispiel: Average temperature rising um mindestens 5 °C innerhalb von 60 s. Diese Bedingung erkennt schnelle Erwärmung, auch wenn der absolute Grenzwert noch nicht erreicht ist.
Digitaler Zustand
Beispiel: DI 1 = on. So kann ein externer Kontakt, Schalter oder Maschinenzustand Teil derselben Alarmregel werden.
Digitale Flanke
Beispiel: DI 1 rising edge oder falling edge. Damit reagiert die Regel auf einen Zustandswechsel, nicht nur auf den aktuellen Zustand.
Filter und Auswertungslogik
Aktive Filter laufen nach den Bedingungen. Sie verwenden AND-Logik: blockiert ein aktivierter Filter, wird kein Incident geöffnet und keine Aktion ausgeführt. Die feste Reihenfolge ist Schedule, Previous incident window, Count window.
Schedule filter
Erlaubt Incidents nur in definierten Wochentagen und Zeitfenstern. Ist der Filter aktiv, blockieren nicht angehakte Tage oder Zeiten außerhalb des Fensters.
Previous incident window
Kann verlangen, dass eine andere Regel innerhalb eines Zeitfensters bereits ausgelöst hat oder gerade nicht ausgelöst hat. Das eignet sich für Eskalations- oder Abhängigkeitslogik.
Count window
Öffnet einen Incident erst, wenn die Regel innerhalb eines Zeitfensters eine definierte Anzahl neuer Aktivierungen erreicht. Gezählt werden neue false-to-true Aktivierungen, nicht jeder Poll-Zyklus.
Aktionen
Actions werden vom Poller als Action Job vorgemerkt und vom Action Worker in definierter Reihenfolge ausgeführt: Create event, Set output, Set impulse, Stop impulse, Set torch, Snapshot, danach Email. Folgt Set torch im selben Action-Lauf direkt auf einen erfolgreich gestarteten Set impulse, wartet der Worker 500 ms vor dem AX8-Web-API-Aufruf. SMTP-Fehler oder spätere Action-Fehler verhindern nicht automatisch bereits ausgeführte frühere Aktionen; Jobs mit write_error oder resolve_error enden als done_with_errors.
Create event
Schreibt ein strukturiertes Regelereignis mit Message und optionalen Tags.
Set output
Setzt einen digitalen Ausgang dauerhaft auf on oder off. Unterstützt Ausführung beim Aktivieren und beim Clear, wenn diese Reaktion gewünscht ist.
Set impulse
Schaltet einen digitalen Ausgang als einen oder mehrere zeitgesteuerte Pulse kurzzeitig auf on oder off, pausiert bei Bedarf zwischen Pulsen und setzt ihn danach automatisch zurück.
Stop impulse
Verkürzt eine laufende Impulsfolge am ausgewählten digitalen Ausgang, sodass sie nach maximal einem weiteren Puls endet.
Set torch
Schaltet die LED-Lampe der Kamera an einer ausgewählten Location ein oder aus.
Snapshot
Plant einen DB-basierten Snapshot-Job für eine Location im Projekt. Trigger-Zustände und ROI-Werte bleiben als Evidenz nachvollziehbar, während der Snapshot Worker das Bild asynchron erfasst.
Email
Sendet eine Alarm-E-Mail an konfigurierte Empfänger. Subject und Body können Vorlagen verwenden; automatisch ergänzt werden Kontext wie Regel, Incident, Kamera-IP, Condition-Ergebnisse, relevante ROI-Werte und konfigurierte Aktionen.
UI-Ausschnitte
Die kleinen Screenshots zeigen die wichtigsten Arbeitsbereiche der Rules-Seite: Rule, Conditions, Filters und Actions.
JC Thermal Monitor
Incidents
Incidents macht aus einem technischen Alarm einen nachvollziehbaren Vorgang. Operatoren sehen, was ausgelöst hat, was bereits bestätigt wurde und welche Belege vorhanden sind.
Funktionen
- aktive, quittierte, geschlossene und wieder aktivierte Incidents prüfen
- Incident manuell quittieren, klassifizieren, zusammenfassen und schließen
- Trigger-Evidenz, Eventverlauf, E-Mail-Status, Evidence Report und verknüpfte Snapshots öffnen
- aus einem Incident heraus ein Untersuchungsticket erstellen
Angezeigte Daten
- Status, Severity, Auslösezeit, letzte Aktivierung, Deaktivierung und Aktivierungsanzahl
- Regeldetails, Bedingungen, ROI-Werte, Aktionen und Runtime-Hinweise
- Snapshot-Belege, Trigger-Events, Operatornotizen, Reportdaten und Ticket-Verknüpfungen
Help-basierte Details
Diese Punkte spiegeln die aktuellen Help-Texte der Anwendung wider und beschreiben die wichtigsten Felder, Buttons und Laufzeitregeln dieser Seite.
Filter und Incident-Liste
- Die Seite folgt dem aktuellen Projekt aus dem globalen Project Selector.
- View wechselt zwischen Open-Ansicht und geschlossener History.
- Workflow state, Condition, Rule name und Outcome filtern die Liste.
- Rule, Severity, Workflow, Outcome, Condition, Opened, Last active, Last inactive, Count und Ack by fassen jede Zeile zusammen.
- Ack bestätigt einen offenen Incident; Close schließt einen Incident, wenn der Workflow es erlaubt.
- Eine ausgewählte Zeile öffnet das Detailpanel.
Incident detail panel
- Status aktualisiert den Workflow State.
- Outcome speichert die Investigation Classification getrennt vom Workflow.
- Changed by und Note schreiben den Operator und die Workflow-Notiz.
- Incident summary ist eine längere Fallzusammenfassung mit Befund und Follow-up.
- Status, Outcome und Incident summary speichern automatisch ohne separaten Save Button.
- Condition List, Action Results, Lifecycle Events und Runtime Diagnosis zeigen die technische Ursache und Folgen.
- Linked annotated Snapshots vergleichen Trigger-Time Values mit dem Evidence Image.
Tickets from an incident
- New ticket title, Priority, Assigned to, Work instruction, Checklist tasks und Required measurements definieren das Untersuchungsticket.
- Assigned to muss ein aktiver Technician sein.
- Checklist tasks erzeugt eine Aufgabe pro Zeile; Required measurements erzeugt Measure-Aufgaben.
- Create Ticket legt das verknüpfte Ticket an.
- Tickets verwenden den angemeldeten User aus dem Home Login Flow.
- Ticket Status Changes werden auf der Tickets-Seite rollen- und assignment-bewusst abgeschlossen.
Runtime States
- Pending wartet auf Threshold Timing; Cooldown blockiert bewusst erneute Aktivierung.
- Incomplete bedeutet fehlende oder stale Daten; Error bedeutet fehlgeschlagene Rule Evaluation.
- Filtered rules können true Conditions haben, ohne Incident, wenn ein Filter blockiert.
- Action results enthalten Output Writes, Impulse Reverts, Impulse Stops, Snapshots, Email sent/dry-run, Skips und Runtime Errors.
- Snapshot image time kann etwas später als der Trigger liegen, weil der Snapshot Worker asynchron erfasst.
Zusätzliche UI-Ausschnitte
Die Detailbilder zeigen, was nach Auswahl eines Incidents sichtbar wird: Workflow, Runtime, Evidence und Lifecycle-Belege.
JC Thermal Monitor
Tickets
Tickets erweitert Incidents um eine einfache Arbeitsabwicklung. Operatoren können Untersuchungsaufgaben an Techniker übergeben, Ergebnisse prüfen und Tickets abschließen.
Funktionen
- Tickets aus Incidents erstellen und Technikern zuweisen
- Priorität, Arbeitsanweisung, Checkliste und erforderliche Messungen pflegen
- Technikern Notizen, Messergebnisse und Anhänge ermöglichen
- Operator-Review mit Rückgabe zur Arbeit, Abschluss oder Abbruch durchführen
Angezeigte Daten
- Ticketstatus, Priorität, zugewiesener Techniker, Incident-Bezug
- Checklist Items, Work Notes, Measurement Entries und Attachments
- Review-Entscheidungen, Rollenrechte und Projektfilterung
Help-basierte Details
Diese Punkte spiegeln die aktuellen Help-Texte der Anwendung wider und beschreiben die wichtigsten Felder, Buttons und Laufzeitregeln dieser Seite.
Rollen im Ticketworkflow
- Tickets verwenden den angemeldeten User aus dem Home Login Flow.
- Admin kann den Workflow überblicken; Assignment ist technician-only.
- Operatoren erstellen Work instruction, weisen Technicians zu, definieren Aufgaben, prüfen Ergebnisse und schließen oder canceln Tickets.
- Technicians bearbeiten zugewiesene Aufgaben, Messwerte, Work Notes und Attachments/Evidence.
- Status change zeigt nur erlaubte nächste Statuswerte für User, Ticket State und Assignment.
- Admin/Operator können neue Tickets im Detailpanel einem aktiven Technician zuweisen.
- Detail Actions sind rollenbewusst: Technicians aktualisieren zugewiesene Task Results, Measurements, Notes und Evidence; neue Checklist Tasks bleiben Admin/Operator-Aufgabe.
- Bei waiting_operator_review prüfen Admin/Operator die Arbeit und schließen das Ticket oder senden es mit Review Note zurück.
Ticket list
- Die Liste folgt dem aktuellen Projekt und kann nach Status gefiltert werden; es gibt keinen separaten Tickets-Scope-Selector.
- All open blendet closed und cancelled Tickets aus.
- Status, Priority, Title, Assigned to, Created und Ticket ID beschreiben jede Zeile.
- Open lädt das Ticket Detail Panel.
- Die Liste auto-refreshes mit der gemeinsamen UI Refresh Einstellung.
Ticket detail workflow
- Der Header zeigt Title, Status, Priority, assigned Technician, Incident ID mit Report Link und Ticket ID.
- Assign technician weist ein Ticket einem aktiven Technician zu.
- Apply status change speichert die ausgewählte Transition.
- General work note und Add note erfassen allgemeine Beobachtungen.
- Operator review note, Send back to technician, Close note und Close ticket steuern die Review-Phase; Zurücksenden oder Schließen verlangt eine Review- oder Close-Notiz.
- Work task/Add task ergänzt Aufgaben; Required measurement/Add required measurement ergänzt Checklist-Measurement-Tasks mit Measure:-Prefix.
- Task result/note speichert Aufgabenergebnisse beim Verlassen des Felds; Value, Unit und Save measurement speichern angeforderte Messwerte direkt an der Measure-Aufgabe.
- Additional measurements erfassen zusätzliche Messungen außerhalb der Checklist.
- Attachments/evidence erlaubt kontrollierte JPG-, PNG- oder PDF-Dateien mit Open-Zugriff auf bestehende Anhänge; Entries zeigt Audit Trail, Statuswechsel, Notizen, Messungen und Attachments.
Limits
- Attachments sind auf 20 MB begrenzt; erlaubt sind JPG, JPEG, PNG und PDF.
- Closed und cancelled Tickets sind read-only und zusätzlich backendseitig geschützt.
- Ticket Assignment Emails laufen über den Notification Service und sind standardmäßig Log/Dry-run, solange SMTP nicht aktiv ist.
Zusätzliche UI-Ausschnitte
Die Detailbilder ergänzen die große Ticket-Ansicht mit Checkliste, Messwerten, Notizen und Historie.
JC Thermal Monitor
Users
Users ist die administrative Benutzerverwaltung von JC Thermal Monitor. Hier werden Viewer, Operatoren, Techniker und Admins angelegt und so gepflegt, dass Bedienung, Ticketarbeit und geschützte Systemfunktionen rollenbasiert bleiben.
Funktionen
- neue Benutzer mit Username, Anzeigename, temporärem Passwort, Rolle, E-Mail und Telefon anlegen
- bestehende Benutzer anzeigen und Name, E-Mail, Telefon oder Rolle bearbeiten
- Passwörter zurücksetzen und Passwortwechsel beim nächsten Login erzwingen
- Benutzer aktivieren, deaktivieren oder inaktive Benutzer ohne Historienbezug entfernen
- letzten aktiven Admin und historische Ticketbezüge schützen
Angezeigte Daten
- Rolle, Status, Username, Anzeigename, E-Mail und Telefonnummer
- Passwortstatus wie gesetztes Passwort oder erforderlicher Passwortwechsel
- Aktionen für Edit, Save, Reset password, Activate, Deactivate und Remove
Users im Detail
Users beschreibt die rollenbasierte Benutzerverwaltung von JC Thermal Monitor. Die Seite ist bewusst administrativ gehalten: Sie legt fest, wer konfigurieren darf, wer Tickets bearbeitet, wer nur überwachen darf und welche Konten aus Sicherheits- oder Historiengründen erhalten bleiben müssen.
Rollen
Admin
Verwaltet Benutzer, Rollen, Passwort-Reset, Aktivstatus und gefährliche Cleanup-Aktionen. Admins können Konfiguration, Incidents, Tickets und geschützte Systemfunktionen bedienen.
Operator
Bedient den normalen Anlagenworkflow: Monitoring, Konfiguration, Rules, Incidents, Snapshots, Reports und Ticket-Review im erlaubten Projektkontext.
Technician / Maintenance
Bearbeitet zugewiesene Untersuchungstickets, dokumentiert Arbeitsschritte, Messwerte, Notizen und Anhänge. Technicians schließen Tickets nicht selbst endgültig ab.
Viewer
Ist für reine Monitoransichten gedacht. Viewer können Home und Visualization überwachen, aber keine Konfiguration, Tickets oder Eingriffe ausführen.
Create user
- Username ist der eindeutige Login-Name und wird später in der UI nicht bearbeitet.
- Display name ist der lesbare Name für Workflows, Zuweisungen und Bedienoberflächen.
- Temporary password wird vom Admin gesetzt und muss beim nächsten Login geändert werden.
- Role legt die Berechtigungsgruppe fest: Admin, Operator, Technician/Maintenance oder Viewer.
- Email und Phone sind optionale Kontaktfelder für Referenz, Ticketarbeit und konfigurierte Benachrichtigungen.
- Create legt den Benutzer aktiv an und markiert das Passwort als change required.
User list
- Role zeigt die aktuelle Berechtigungsgruppe.
- Status zeigt, ob der Benutzer aktiv ist und einloggen kann.
- Username bleibt der stabile technische Login-Name.
- Name, Email und Phone zeigen die gepflegten Profil- und Kontaktdaten.
- Password zeigt, ob ein Passwort gesetzt ist oder beim nächsten Login geändert werden muss.
- Actions enthält die aktuell erlaubten Bedienaktionen für den jeweiligen Benutzer.
Buttons und Aktionen
Refresh
Lädt die Benutzerliste neu, inklusive inaktiver Benutzer. Das ist hilfreich nach Änderungen oder wenn mehrere Admins arbeiten.
Edit
Schaltet eine Tabellenzeile in den Bearbeitungsmodus. Bearbeitet werden können Name, Email, Phone und Role; Username bleibt unverändert.
Save
Speichert die im Edit-Modus geänderten Profildaten oder die geänderte Rolle. Der letzte aktive Admin bleibt geschützt.
Cancel
Verwirft die gerade angezeigte Bearbeitung und zeigt die Zeile wieder im Lesemodus.
Reset password
Setzt ein neues temporäres Passwort und erzwingt beim nächsten Login einen Passwortwechsel.
Deactivate
Sperrt den Login, behält aber historische Ticket- und Workflow-Referenzen. Der eigene aktive Benutzer und der letzte aktive Admin sind geschützt.
Activate
Aktiviert einen inaktiven Benutzer wieder, sodass er sich erneut anmelden und seine Rolle nutzen kann.
Remove
Löscht nur inaktive Benutzer ohne Datenbankhistorie dauerhaft. Benutzer mit Ticket- oder Workflow-Bezug bleiben deaktiviert statt gelöscht.
Sicherheitsregeln
- Nur angemeldete Admins verwenden diese Seite.
- Benutzer werden normalerweise deaktiviert statt gelöscht, damit Reports, Tickets und Historie nachvollziehbar bleiben.
- Inaktive Benutzer können nicht einloggen und erscheinen nicht als nutzbare Actors in rollenbasierten Workflows.
- Auto-Logout für Admin, Operator und Technician wird global in Settings konfiguriert; Viewer Sessions verwenden die konfigurierte Viewer Session Lifetime.
- Der letzte aktive Admin kann nicht deaktiviert werden und darf die Admin-Rolle nicht verlieren.
JC Thermal Monitor
Snapshots
Snapshots liefert die Bildbelege zu Messwerten und Incidents. Manuelle und regelbasierte Snapshots werden gespeichert, verknüpft und bei Bedarf annotiert dargestellt.
Funktionen
- manuelle Snapshots pro Gerät auslösen
- regelbasierte Snapshot-Jobs überwachen
- gespeicherte und annotierte Snapshot-Dateien über geschützte Links öffnen
- alte oder nicht mehr benötigte Snapshot-Daten rollenabhängig bereinigen
Angezeigte Daten
- Jobstatus, Kamera, Incident, Trigger-Event, Capture-Zeit
- Dateipfade, Annotation-Status, Fehlercode, REST/RTSP-Capture-Hinweise und Erzeugungszeit
- Snapshot-Zähler, Löschoptionen und read-only Zugriffe
Help-basierte Details
Diese Punkte spiegeln die aktuellen Help-Texte der Anwendung wider und beschreiben die wichtigsten Felder, Buttons und Laufzeitregeln dieser Seite.
Header und Filter
- Delete all snapshots entfernt sichtbare Snapshot Records/Files nur für Rollen mit Mutationsrecht und nur, wenn Evidence nicht mehr benötigt wird.
- Status filtert queued, running, done, failed oder all.
- Rule id und Incident id begrenzen die Liste auf eine Rule oder einen Incident.
- Limit lädt die neuesten Zeilen im Bereich 1 bis 200.
- Only failed schaltet in den Failed-Job Troubleshooting Mode.
- Die Liste folgt dem aktuellen Projekt und zeigt Backlog/Failure Counts über die Zeit.
Job list und Detail
- Created, Status, Rule, Device, Attempts und Result beschreiben jeden Job.
- Result zeigt File Links, Fehlerdetails oder Cleanup/Delete Controls je nach Job State.
- Job Detail zeigt Started/Finished, Duration, Error Text, Snapshot Links und Trigger Context.
- Admin und Operator können einzelne failed Jobs, gespeicherte Snapshots oder passende Bulk Cleanup Actions löschen.
Job States und Evidence
- Queued wartet auf den Snapshot Worker; Running ist vom Worker geclaimed; Done wurde gespeichert; Failed braucht Fehleranalyse.
- Kind current bedeutet, dass ein Rule Snapshot dem aktuellen Kamera Image Mode folgte.
- Manuelle/API-Snapshots können weiterhin explizite Werte wie thermal, visual oder overlay zeigen.
- Annotated snapshot links öffnen das gerenderte Evidence Image.
- Overlay-Werte sind aus Trigger-Time Runtime Data eingefroren; das Bild kann wegen asynchroner Erfassung etwas später sein.
- Snapshot Capture läuft im Snapshot Worker, damit Alarm- und Poller-Verarbeitung nicht durch langsame Kamerabilder blockiert wird.
- REST image capture nutzt das konfigurierte Timeout, bevor bei Bedarf RTSP fallback genutzt wird.
- Gelöschte Snapshots verlieren ihre File Reference für Evidence Views.
- Snapshots, die noch für Untersuchung oder Reporting benötigt werden, sollten nicht gelöscht werden.
JC Thermal Monitor
Health
Health zeigt nicht nur, ob die Webanwendung läuft, sondern ob der gesamte Monitoring-Betrieb frisch, plausibel und vollständig arbeitet.
Funktionen
- Kamera- und Modbus-Kommunikation diagnostizieren
- ROI-Frische, Messwertalter und Regelzustände prüfen
- Worker-Heartbeats für Poller, Snapshot Worker, Action Worker und Impulse Worker überwachen
- E-Mail-Aktionsstatus, Camera Impuls Writes und Snapshot-Runtime prüfen
- System Incidents für ausgewählte Health-Warnungen konfigurieren und schließen
- Health-State gezielt bereinigen, wenn veraltete Diagnosedaten stören
Angezeigte Daten
- Device Health, ROI Freshness, Rule Runtime, Action Runtime
- Poller Load, Poller Loop, Worker Heartbeats, Action-Job-Status und Snapshot-Job-Zustand
- Impuls Runtime, System Incidents, E-Mail sent/dry-run, Camera Impuls Writes, letzte Fehler und technische Diagnosemeldungen
Help-basierte Details
Diese Punkte spiegeln die aktuellen Help-Texte der Anwendung wider und beschreiben die wichtigsten Felder, Buttons und Laufzeitregeln dieser Seite.
Toolbar und Worker
- View wechselt zwischen Full und Attention only; Attention only blendet gesunde Zeilen aus.
- Clean Health löscht gespeicherte Health Rows und Runtime Diagnostic Rows für sauberes Troubleshooting, wenn alte Diagnosen nicht mehr hilfreich sind.
- System incidents macht ausgewählte Health-Warnungen nach konfigurierter Verzögerung als Warning-Zeilen sichtbar.
- Background workers zeigt, ob Poller, Snapshot Worker, Action Worker und Impulse Worker Heartbeats frisch oder stale sind.
- Poller load zeigt Loop Duration, Actual Interval, Targets, OK, Failed, Backoff, Rows written, Projects evaluated und Finished.
- Backoff bedeutet, dass fehlgeschlagene Status Targets weniger aggressiv wiederholt werden.
Camera runtime
- Camera Modbus Lock zeigt waits, extended waits, timeouts, long holds und unlock warnings.
- Recent Camera Modbus Events zeigen Camera, Operation, Event Type, Wait/Hold Time und Message.
- Camera Measurement Snapshot zeigt Health des gemeinsamen Measurement Cache und Refresh Errors.
- Recent Camera Measurement Events zeigen Cache State, Snapshot Age, Max Age und Diagnosemeldung.
- Camera Impuls Writes zeigt physische DO write attempts, skipped same-state writes und write errors.
- Image live started bedeutet, dass die App nach Freeze Detection ein AX8 Resume Video Command gesendet hat.
Snapshot, Impuls und Project State
- Snapshot job runtime zeigt backlog, running jobs, failed jobs, stale running jobs, last success/failure und last error.
- System incidents konfiguriert, welche Health-Warnungen als Warning-Zeilen erscheinen, inklusive Severity, Show-after Delay, Cooldown, optionalen Email-Empfängern und Close Action.
- Warning bedeutet, dass das konfigurierte Health-Problem noch besteht; Resolved bleibt sichtbar, bis ein Operator Close ausführt.
- Impuls Runtime zeigt Target Output, Health, aktuellen Impuls, Phase, Pending Impuls, Incident-Bezug, Output Value und Last Error.
- Impuls Churn Suppression zeigt absichtlich unterdrückte wiederholte oder bereits aktive Impuls-Aktivierungen.
- Devices zeigt Location, Device, online/offline, Last poll, Last seen, Age und neuesten Device Error.
- ROI freshness zeigt, ob aktivierte ROIs ausreichend aktuelle Messdaten haben.
- Rule runtime zeigt Condition state, Incomplete reason, Pending, Last evaluated und Last error.
- Action diagnostics zeigt Health, Status, Transition, Last attempt/success, Failure count, Last error und Action Jobs mit done_with_errors.
Health States lesen
- Pending: Threshold Timing läuft; Cooldown: Aktivierung ist kurzzeitig blockiert.
- Stale: Messungen sind zu alt; Missing: Messungen fehlen.
- Skipped action: Trigger mode passte nicht zur Incident Transition.
- Email sent/dry-run: Rule Email wurde gesendet oder absichtlich ohne SMTP protokolliert.
- Camera Impuls Writes zeigen erfolgreiche, redundante und fehlgeschlagene AX8 DO Writes.
Zusätzliche UI-Ausschnitte
Die Detailbilder ergänzen die große Health-Ansicht mit Worker-, Poller-/Kamera-Laufzeit und Regel-/Action-Diagnose.
JC Thermal Monitor
Visualization
Visualization dient der Analyse. Anwender können thermische Messreihen, Incident-Aktivierungen und digitale Zustände im gleichen Zeitfenster betrachten und miteinander vergleichen.
Funktionen
- thermische und digitale Serien im Series Selector suchen und auswählen
- Thermal History, Incident Timeline und Digital Timeline gemeinsam auswerten
- Zeitfenster per Preset, From/To, Verschiebung oder Doppelklick-Drill-down steuern
- Incident-Marker und Buckets per Tooltip inklusive höchster Severity prüfen
- Auto-Refresh und Print / Save as PDF für Monitor- und Analysebetrieb nutzen
Angezeigte Daten
- Spot- und Box-Metriken wie Temperatur, Minimum, Maximum und Average
- Thermal History mit mehreren farbigen Temperaturreihen
- Incident Timeline mit Aktivierungsmarkern, Bucket-Severity, Status und Incident-Zeitpunkten
- Digital Timeline mit DI/DO-Zuständen, Edge-Events, Aktivitätsmarkern und stabiler Location-/DI-/DO-Reihenfolge
- Serienfarben, aktuelle Runtime-Werte, Zeitfenster, Resolution und Datenverfügbarkeit
Visualization im Detail
Visualization ist die gemeinsame Analyseansicht für Messwerte, Incidents und digitale Zustände. Die Seite hilft zu verstehen, was vor, während und nach einer Regelaktivierung passiert ist.
Thermal History
- oberes Diagramm für ausgewählte Spot- und Box-Temperaturreihen
- mehrere Serien werden farbig übereinander dargestellt
- die letzten 15 Minuten können aktuelle Live-Pufferwerte nutzen
- bei längeren Zeitfenstern wird eine einfachere aggregierte Darstellung verwendet
Incident Timeline
- mittleres Diagramm mit Incident-Aktivierungen im ausgewählten Zeitfenster
- Marker zeigen Rule, Aktivierungszeit, Severity, Status, Opened und Closed
- bei vielen nahen Markern werden Cluster oder zusätzliche Marker zusammengefasst und nach höchster Severity eingefärbt
- ein Doppelklick auf die Timeline setzt ein 15-minütiges Drill-down-Zeitfenster
Digital Timeline
- unteres Diagramm für DI- und DO-Zustände
- kurze positive und negative Impulse bleiben sichtbar
- bis 15 Minuten werden beobachtete Zustandswechsel als Step Chart rekonstruiert
- bei längeren Zeitfenstern werden digitale Aktivitäten bucketed dargestellt
Auswahl und Zeitfenster
Series Selector
Die linke Auswahl zeigt projektbezogene Serien nach Location, ROI und Metrik. Die Suche filtert nach diesen Angaben; die Digital Timeline folgt der Katalogreihenfolge nach Location-Name, dann DI vor DO. Aktuelle Runtime-Werte, stale Hinweise, no value und not present helfen, die Datenqualität einzuschätzen.
Zeitfenster
From und To können direkt gesetzt werden. Zusätzlich gibt es Presets von Last 15 min bis Last 365 days und Pfeile zum Verschieben des aktuell gewählten Fensters.
Apply und Report
Apply lädt die aktuelle Auswahl neu. Print / Save as PDF erzeugt eine druckbare Momentaufnahme mit Report-Headerfeldern aus Settings, ausgewählten Serien, Diagrammen, Zeitbereich und Project Time Zone.
Interaktionen
Doppelklick auf ein Diagramm
Ein Doppelklick in Thermal History, Incident Timeline oder Digital Timeline öffnet ein 15-minütiges Drill-down-Zeitfenster rund um den angeklickten Zeitpunkt.
Incident-Marker mit der Maus prüfen
Wenn der Cursor über einem Incident-Kreis liegt, zeigt der Browser eine Detail-Tooltip mit Regelname, Aktivierungszeit, Severity, Status, geöffnetem und geschlossenem Zeitpunkt. Während ein Tooltip aktiv ist, stört Auto-Refresh nicht.
Anzeigeeinheit und Viewer-Modus
Die globale Temperature Display Unit ändert nur UI-Beschriftungen und Formatierung; History API und gespeicherte Werte bleiben Celsius-basiert. Nach Inactivity Logout müssen Admin, Operator und Technician erneut über Home/Login einsteigen; Viewer Sessions verwenden die konfigurierte Viewer Session Lifetime.
Cluster und Bucket-Marker
Wenn mehrere Incidents zu eng beieinander liegen oder ein langes Zeitfenster aggregiert wird, zeigen Marker die Anzahl und eine kurze Aufschlüsselung nach Regeln.
Grenzen und Datenlogik
- maximal 24 Thermal Series gleichzeitig
- maximal 12 Digital Series gleichzeitig
- Zeitfenster über 365 Tage werden abgelehnt
- Zeitfenster über 6 Stunden verwenden eine aggregierte Thermal-Darstellung
- Digital History hängt von beobachteten oder gespeicherten Edge-Events ab
- bis 15 Minuten wird Digital History als Step Chart aus Edge-Events rekonstruiert
- bei längeren Zeitfenstern wechselt Digital History zu bucketed Activity, damit kurze Impulse sichtbar bleiben
UI-Ausschnitte
Die kleinen Screenshots zeigen den Series Selector sowie die drei verbundenen Analysebereiche Thermal History, Incident Timeline und Digital Timeline.
JC Thermal Monitor
Settings
Settings sammelt Betriebsparameter, die nicht direkt zu einer einzelnen Regel oder Location gehören, aber den Systembetrieb beeinflussen.
Funktionen
- Polling- und Ingest-Intervalle einstellen
- Auto-Refresh-Zeiten für UI-Seiten konfigurieren
- Temperaturanzeige zwischen Celsius und Fahrenheit umstellen
- projektbezogene Report Settings mit Kunde, Abteilung, Standort, Logo, Footer und Zeitzone pflegen
- E-Mail-Konfiguration testen und Diagnosewerte prüfen
Angezeigte Daten
- Messintervall, Offline-Timeout, Live-History-Stale-Grenze und Measurement-History-Retention
- UI-Refresh-Werte, Snapshot-HTTP-Timeout, Discovery-Limits
- Report Settings, E-Mail-Dry-Run-Status, SMTP-Testantwort und letzte Aktualisierung
Help-basierte Details
Diese Punkte spiegeln die aktuellen Help-Texte der Anwendung wider und beschreiben die wichtigsten Felder, Buttons und Laufzeitregeln dieser Seite.
Header und Projektwerte
- Refresh lädt App Settings, aktuelles Project Sampling, Project Report Settings und Email Status neu und verwirft ungespeicherte Änderungen.
- Save settings ist die einzige Save Action für globale Settings sowie aktuelles Project Sampling und Project Report Settings.
- Unsaved changes erscheint nach Änderungen an speicherbaren Feldern und verschwindet nach Save oder Refresh.
- Last updated zeigt Lade- oder Speicherzeitpunkt.
- Der Restart-Hinweis markiert Einstellungen, die von laufenden Worker-Prozessen gelesen werden und ggf. Service-Restart benötigen.
- Default sample period (s) gilt für das aktuelle Projekt und wird genutzt, wenn keine Location- oder ROI-Vorgabe existiert.
Report Settings
- Customer/company, Department und Site/plant erscheinen in Incident Evidence Reports und Visualization Print.
- Logo URL zeigt auf ein Header-Bild; leer bedeutet kein Kundenlogo.
- Project time zone steuert UI- und Report-Zeitstempel.
- Footer text erscheint am Ende generierter Reports.
- Save settings speichert diese projektspezifischen Report-Felder zusammen mit den anderen Settings auf dieser Seite.
Polling und Runtime Defaults
- Device status poll interval steuert Online/Offline-Statuspolling.
- Measurement ingest interval (s, DI/DO sampling cadence) steuert, wie oft Runtime Measurement Ingest Kamera-ROI-Werte abfragt.
- Impulse worker poll interval steuert Output Timing und Auto-Revert des Impulse Workers.
- Device offline after ist das Freshness-Fenster für Overview und Health.
- Polling-Intervalle und Impulse worker poll interval brauchen nach dem Speichern einen Restart der Worker Services.
- Temperature display unit ändert UI-Formatierung; gespeicherte/API-Werte bleiben Celsius-basiert.
- UI auto refresh steuert die gemeinsame automatische Aktualisierung.
- Auto logout after inactivity meldet inaktive Benutzer ab.
- Virtual alarm edge hold time hält Edge Evidence kurz verfügbar.
- Live thermal gap join limit steuert Lücken im Last-15-Minute-Live-Chart.
- Snapshot HTTP timeout before RTSP fallback steuert REST Capture vor RTSP-Fallback.
Other, Retention, Discovery und E-Mail
- Discovery timeout und Discovery max results setzen die Defaults für Netzwerkscans und Ergebnistabelle.
- Measurement history retention (days) steuert, wie lange automatisch gespeicherte Measurement-History-Zeilen in der Datenbank bleiben.
- Current measurement rows zeigt die aktuell gezählte Anzahl gespeicherter Measurement-History-Zeilen; Refresh liest diesen Wert neu, er wächst aber nur, wenn der Ingest tatsächlich neue History-Zeilen schreibt.
- Der Wert 0 deaktiviert die automatische Measurement-History-Bereinigung.
- Wenn der Retention-Wert geändert und gespeichert wird, läuft die Measurement-Bereinigung sofort; zusätzlich prüft die App beim Start und einmal täglich während des Betriebs.
- Tickets, Rules, Incidents, Trigger Evidence und Snapshots werden durch diese Einstellung nicht gelöscht.
- Die Email Card zeigt enabled, dry-run und nicht-geheime SMTP-Konfiguration.
- Test recipient und Send test email prüfen denselben Notification Service wie Ticket- und Rule-Emails.
- Bei Dry-run werden Test- und Rule-Emails protokolliert, aber nicht per SMTP versendet.
- SMTP host, port, username, password, sender, enabled und dry-run kommen aus .env; Änderungen brauchen Service-Restart.
Funktionen
Was das System fachlich abdeckt.
ROI und Messwerte
Unterstützt Spot- und Box-ROIs, digitale Eingänge und digitale Ausgänge. Messwerte können pro ROI gespeichert und mit eigener Abtastung erfasst werden.
Alarmregeln
Regeln arbeiten projektbezogen mit direkter Temperatur, Delta-Prüfungen, digitalen Zuständen, Flanken, Rate-of-change, Hysterese und Cooldown.
Aktionen
Bei Aktivierung oder Clear werden Action Jobs queued: Events, Ausgänge, Impulse, Impulsstopp, Snapshot-Anforderungen, Torch-Steuerung und E-Mail laufen außerhalb des Live-Ingests.
Incident-Evidenz
Beim ersten Auslösen werden relevante Werte eingefroren. Später verknüpfte Snapshots ergänzen die dynamische Bildbeweislage.
Evidence Reports
Incident- und Trigger-Informationen können als druckbare Reportansicht dargestellt werden, damit Ursache, Zustand und Maßnahmen nachvollziehbar bleiben.
Rollen und Zugriff
Home und Visualization können als Viewer-Monitoransicht dienen. Konfiguration, Tickets, Eingriffe und Snapshot-Dateien sind rollenabhängig geschützt.
Technik
On-Premise-Architektur für den Betrieb vor Ort.
Die Anwendung besteht aus FastAPI-Webservice, PostgreSQL/TimescaleDB, Alembic-Migrationen und separaten Hintergrundprozessen. Poller, Action Worker, Snapshot Worker und Impulse Worker laufen getrennt, damit Datenerfassung, Action Jobs, Bildjobs und Impulse unabhängig überwacht werden können.
- Docker-Compose-Runtime mit Datenbank, Migration, App, Poller, Action Worker, Snapshot Worker und Impulse Worker.
- Heartbeat-basierte Worker-Diagnose statt reiner Prozessprüfung.
- Lokale Snapshot- und Runtime-State-Speicherung.
- Authentifizierte Snapshot-Auslieferung und rollenbasierte Monitor-/Bedienrechte.
- E-Mail-Benachrichtigungen mit Dry-Run-Modus und SMTP-Test.