Home
Start page for project state, active incidents, camera health and current warnings.
Details and features
JC Thermal Monitor in detail
This page describes the most important operating pages and system functions for users, integrators and potential customers who want to evaluate JC Thermal Monitor as a monitoring product, pilot installation or temporary diagnostics platform in more detail.
System goal
Monitor thermal states, evaluate test conditions and document findings traceably.
JC Thermal Monitor is an on-premise system for industrial plants and technical diagnostic projects where thermal states need to be observed over time, evaluated and documented as a decision basis. The current target integration is FLIR AX8. The system connects camera and ROI data, digital signals and Modbus-adjacent states with alarm rules, incidents, snapshot evidence, evidence reports, tickets, Viewer monitor access and diagnostic information. It can be installed next to an existing AX8 system because normal monitoring reads camera registers and does not replace the original plant function. Only digital outputs need clear ownership: either the camera/existing system or Thermal Monitor should control the same output.
Spot and box ROIs are still enabled and positioned in the AX8 web interface. After ROI sync, those enabled measurement points appear in Thermal Monitor and can be used in Conditions and Actions. Rules can combine ROIs and DI/DO signals from several separate cameras, creating a true multi-camera system with database history for temperature values, events, incident states, ticket states, reports and exportable Visualization analysis.
Target usersmaintenance, operators, integrators, technical management
CameraFLIR AX8 as the current focus
Installationlocal server with database and background processes
Existing systemsparallel operation, monitoring reads camera registers
ROI setupspot and box in the AX8 web interface, use after sync
Rule logicROIs and digital signals from multiple cameras can be combined
Project typepilot, temporary diagnostics platform or customer-specific plant
Accessrole-based, including Viewer monitor view
User interface
Important pages and their tasks.
The following entries link to the detailed descriptions of each page. The screenshots show the most important interfaces and tasks in the system.
Projects
Management of projects, project status, report data and default sampling.
Locations
Locations, device assignment, endpoint settings, ROI synchronization and ROI storage.
Discovery
Network search, Known state and assignment of reachable devices to free locations.
Rules
Configuration of virtual alarm rules with conditions, filters, actions and runtime state.
Incidents
Handling of active and closed incidents with history, evidence and snapshots.
Tickets
Investigation workflow for incidents with checklist, notes, measurements and attachments.
Users
Admin area for users, roles, active state, editing and password reset.
Snapshots
Snapshot jobs, stored images, annotated evidence and cleanup.
Health
Operational health for camera, ROIs, rules, workers, impulse runtime, system incidents, e-mail and snapshot jobs.
Visualization
Shared timeline for temperature series, digital signals and incident markers.
Settings
Runtime parameters for polling, display, auto-refresh, report data, e-mail and diagnostics.
Screen details
What happens on each page.
JC Thermal Monitor
Home
The Home page is the daily entry point for operators. It shows whether the selected project is thermally stable, whether incidents are open and whether cameras or background processes need attention.
Functions
- check the current project and the most important runtime states at a glance
- quickly identify active incidents and critical warnings
- open latest snapshots and relevant events directly
- include login, logout, password change and Viewer monitor access in the normal operating flow
Visible data
- project name, active incidents, camera status, health warnings
- latest snapshot evidence and timing hints
- notes about password change, login, minimal Home/Login view and Viewer access
Help-based details
These points mirror the current application Help texts and describe the most important fields, buttons and runtime rules of this page.
Login and password
- Username and Password log the user into role-based pages; without login only the minimal Home/Login view is visible.
- On a new local database the first commissioning account is admin with password admin; that password must be changed afterwards.
- Login refreshes the menu and permissions according to the user's role.
- Current password and New password appear for forced or voluntary password changes.
- Change password saves the new password and clears the warning when the current password is correct.
- must_change_password shows a warning in V1, but does not block authorized work.
- Logout clears the session and returns the UI to the minimal Home/Login view.
- Auto logout uses the inactivity limit from Settings for Admin, Operator and Technician; Viewer sessions use the Viewer session lifetime.
- Without login, Home does not load operational project, snapshot, camera, incident or health data.
Dashboard cards
- The cards always use the currently selected project.
- They show active incidents, device status, recent alarm activity, snapshots and health attention items.
- Counts and warning badges are navigation hints to the linked detail pages.
- Top Health Warnings lists the most important worker, device, ROI, rule, action and runtime warnings.
- Latest Snapshots opens stored snapshot files or falls back to the Snapshots page when no direct file link is available.
- Stale workers, offline devices, missing ROI measurements, failed actions and snapshot backlog are normally investigated in Health.
- Changing the project in the top navigation changes the context for Rules, Incidents, Tickets, Health, Snapshots and Visualization.
JC Thermal Monitor
Projects
Projects is the level where customers, plants, locations or pilot installations are separated cleanly. A project bundles locations, rules, incidents, tickets, reports and visualization.
Functions
- create, rename, activate, deactivate or clean up projects
- maintain default measurement interval and project-specific report data
- distinguish active and archived project states
- use Clear Data for disabled projects before final Delete becomes possible
Visible data
- name, description, active state, sampling defaults
- report fields such as customer, department, site, logo, time zone and footer
- external status information and notes about dependent data
Help-based details
These points mirror the current application Help texts and describe the most important fields, buttons and runtime rules of this page.
Top actions and project context
- Refresh reloads the project list and visible project details without changing data.
- The page message area reports create, save, enable, disable, clear data, delete and load errors.
- The global Project Selector controls the current project for project-scoped pages and lists enabled projects only.
- Disabled projects remain visible here for re-enable, Clear Data and final Delete workflows.
- Use as current sets the active project for the top project selector and pages such as Rules, Incidents, Tickets, Health, Snapshot Jobs, Visualization and Settings.
Create and edit project
- Name is required, must be unique and appears in selectors, lists, reports and project-scoped pages.
- Description optionally explains the site, line or monitoring scope.
- Default sample period (s) is the fallback write cadence for measurements when no location-level or ROI-level override exists; the allowed range is 1 to 86400 seconds.
- Create project creates a new project; Edit opens the detail panel; Save stores name, description and default sample period.
- Only one project detail panel is open at a time; editing another project closes the previous panel.
- Close collapses the open detail panel.
- Report identity and project time zone are maintained in Settings for the currently selected project.
Enable, disable, Clear Data and Delete
- Enable returns a disabled project to active lists and runtime eligibility.
- Disable keeps the data but excludes the project from active runtime polling and normal active-project views.
- Clear Data is admin-only, available only for disabled projects and removes measurements, incidents, tickets, snapshots, ticket attachment files, exports, events and runtime state while keeping configuration.
- Delete appears only after Clear Data has run and no runtime data remains.
- Delete then removes the remaining project configuration.
JC Thermal Monitor
Locations
Locations connect real plant areas with cameras and ROIs. This page shows which camera is assigned to a location, whether runtime is active and which endpoint and ROI settings are maintained.
Functions
- assign a device to a location or remove it again
- maintain active camera endpoint data such as name, serial number, IP, ports, username and encrypted stored password status
- synchronize FLIR AX8 ROIs and mark missing ROIs non-destructively
- maintain ROI names, descriptions, active state and measurement storage
- distinguish digital outputs between Level and Impulse mode
Visible data
- location, online/offline status, device, serial, IP, last poll, last seen and last error
- spot, box, DI and DO ROIs with presence state
- Endpoint dialog with HTTP/Modbus port, username and password status
Help-based details
These points mirror the current application Help texts and describe the most important fields, buttons and runtime rules of this page.
Main location table
- New location creates an empty location in the current project.
- Location is the operator-facing name for a place, machine or plant area.
- The overview stays stably sorted alphabetically by location name.
- Status summarizes online, offline, runtime disabled or unassigned state.
- Device, Serial, IP, Last poll, Last seen and Last error show camera and runtime state.
- Open Camera opens the camera web UI in a separate browser window when an IP is available; it does not auto-login with the app-stored password.
- Endpoint opens the active camera endpoint settings for the selected row.
- Rename changes the location name; Sync ROI reads ROI definitions from the camera; ROIs opens the ROI panel.
- Disable runtime keeps the device assignment but excludes the deployment from automatic polling; Enable runtime includes it again.
- Unassign removes the active device assignment from the location.
Endpoint dialog
- Endpoint opens the assigned camera settings for the selected row, not a global app setting.
- Device name and Serial number identify the camera; the serial number belongs to the physical AX8 camera even when the location changes.
- IP address, HTTP port and Modbus port are the current access data for live image, snapshots, polling and Modbus-adjacent runtime.
- Username is used for camera operations when the camera requires authentication.
- Password sets or replaces the camera password encrypted and stored by the app; an already stored password is never displayed again.
- Clear password asks for confirmation and removes only the stored camera password while keeping name, serial number, IP and ports unchanged; normal Save cannot accidentally clear the password.
- The password status only shows whether a password is currently configured: Password: configured or Password: not configured.
- Test torch turns the AX8 LED/Torch on for 5 seconds and then off again with the stored username and password; it does not auto-login to the camera web UI.
ROI panel
- Sync ROI in the panel refreshes the selected location's ROI list from the camera.
- Save all writes all edited ROI rows; Save writes only the respective ROI row.
- Camera ROI shows the camera label, type and index.
- Short name is an optional operator-friendly label; empty short names fall back to the camera ROI label.
- Description stores longer local notes for the ROI.
- Camera status shows whether the ROI currently exists on the camera.
- ROI enabled controls runtime use; missing camera ROIs cannot be enabled.
- History enabled controls measurement storage for charts and reports.
- Store every (s) overrides the measurement storage cadence for this ROI.
ROI sync and digital outputs
- Digital output mode is assigned automatically by Rules: set_output uses Level, set_impulse and stop_impulse use Impulse.
- The backend blocks automatic mode changes when active actions or running impulse runtime would make the change unsafe.
- Discovery only assigns devices; ROI rows appear after device assignment and manual ROI sync.
- Current DO target support is limited to ROI index 1.
- The live AX8 adapter supports Spot, Box, DI and DO; Line ROI is later adapter scope.
Additional UI excerpts
The detail images complement the compact location list with the ROI panel and Endpoint dialog. Passwords are not displayed again; the UI only shows whether one is configured.
JC Thermal Monitor
Discovery
Discovery supports commissioning and maintenance by searching for reachable cameras or devices on the network, matching them with known endpoints and assigning them to free locations.
Functions
- start network scan with configurable timeout and host limit
- check found hosts with Known state and matched device
- assign unknown or known, not actively assigned devices to a free location
- show known-but-not-found devices
Visible data
- scan status, found IPs, open ports and known devices
- assignment selector for unassigned locations
- HTTP server, HTTP title and known-but-not-found notes
Help-based details
These points mirror the current application Help texts and describe the most important fields, buttons and runtime rules of this page.
Scan inputs
- CIDR scans a network range such as 192.168.178.0/24.
- Ports is a comma-separated TCP port list, typically 80 for HTTP, 554 for RTSP and 502 for Modbus.
- From IP and To IP define a smaller explicit IP range; CIDR and From/To should not be used at the same time.
- Timeout (ms) controls how long one probe waits for a response.
- Max results limits how many discovered hosts appear in the results table.
- Start scan runs the scan and fills the result list.
Assignment and results
- Unassigned location selects the existing location that will receive the discovered device.
- Refresh reloads the unassigned location list.
- Camera login data is managed later from the Locations page Endpoint dialog.
- Assign appears on unknown devices and on known devices that are currently not assigned to any location.
- Assign registers the device to the selected location; new assignments are runtime-enabled.
- After a successful assignment, the page scans again so Known state and action buttons are fresh.
- IP, Open ports, Known, Matched device, HTTP server and HTTP title help recognize the camera.
- Known but not found lists known endpoints that were not found in the current scan range.
- ROI rows appear only after device assignment and ROI sync on the Locations page.
JC Thermal Monitor
Rules
Rules is the technical control center of monitoring. Measurements, digital states and time-based conditions are turned into traceable alarm rules with actions.
Functions
- create, activate, deactivate and edit project-related rules
- configure AND/OR logic, thresholds, delta conditions, digital states and edges
- use hysteresis, minimum duration, cooldown and filters such as count windows
- manage actions such as event, output, impulse, impulse stop, torch, snapshot and e-mail as action jobs
Visible data
- rule name, severity, active state, condition mode
- conditions with ROI, metric, operator, threshold and runtime state
- actions, order, trigger mode, action-job status, last error and execution state
Help-based details
These points mirror the current application Help texts and describe the most important fields, buttons and runtime rules of this page.
Rule editor
- Name is required and appears in lists, incidents and e-mails.
- Severity is the rule priority from 1 to 10; new incidents copy this value.
- Conditions logic sets AND or OR for active conditions.
- Cooldown (s) blocks reactivation shortly after clear/deactivation.
- Create rule, Save rule, ENABLED/DISABLED and Delete manage the rule itself.
Condition editor
- + Add condition opens the condition editor; Back to conditions and Cancel return to the list.
- Condition type selects Direct value, Delta or Temperature rate.
- ROI, Metric, Operator and Threshold/value define the measured comparison.
- Delta can compare against a second ROI or a Fixed temperature and uses the absolute difference.
- Temperature-rate uses live ingest samples inside the configured window.
- Threshold time requires a stable duration; Hysteresis reduces rapid switching around analog limits.
- Edge direction reacts to rising or falling digital transitions; very short pulses can be missed with coarse ingest cadence.
Filters
- Filters decide after true conditions whether an incident may open or reactivate.
- V1 supports Schedule, Previous Incident Window and Count Window per rule.
- Schedule allows incidents only on selected weekdays and time windows.
- Previous Incident Window can require activity or non-activity of another rule.
- Count Window counts new false-to-true activations inside a time window.
- The order is fixed: Schedule, Previous Incident Window, Count Window.
- Enabled filters use AND logic; if a filter blocks, no actions run.
Action editor
- + Add action opens the action editor; Back to actions and Cancel return to the list.
- Action type selects create_event, email, set_output, snapshot, set_torch, set_impulse or stop_impulse.
- Trigger mode defines whether an action runs for example on activation or on clear.
- Action order inside the action job is automatic: create_event, set_output, set_impulse, stop_impulse, set_torch, snapshot, then email.
- set_output sets a DO permanently; set_impulse sets a temporary state, can run multiple pulses and reverts automatically.
- stop_impulse shortens the selected DO's running impulse sequence so it finishes after at most one more pulse.
- set_torch controls the camera LED torch at the selected location.
- If set_torch follows a successfully started set_impulse in the same action run, the action worker waits 500 ms before the AX8 web API call.
- For short 2-3 s DO impulses on the same AX8, set_impulse and set_torch should be placed in separate rules with parallel conditions.
- snapshot schedules a snapshot job; overlay values come from trigger-time runtime ROI data.
- email uses recipients, subject/body templates and automatically appends alarm details.
- Action diagnostics show sent, dry_run, write_error, resolve_error, skips, impulse stops, runtime errors and jobs with done_with_errors.
Rules in detail
A Rule connects measurements, digital states, filters and actions into a traceable alarm decision. Operators can define when a state is relevant, when it is intentionally suppressed and which automatic response should follow.
Rule basics
- Name, project relation, severity, active state and cooldown define the rule frame.
- Disabled Rules do not run. Disabled Conditions are ignored during evaluation. Disabled Actions only prevent the respective side effect.
- Cooldown prevents the same rule from activating again immediately after deactivation.
Condition logic
- AND means: all active conditions of the rule must be fulfilled.
- OR means: one fulfilled active condition is enough.
- A rule without active conditions does not trigger.
Runtime safety
- Threshold time requires a condition to remain true for a defined duration.
- Hysteresis prevents rapid switching around analog temperature limits.
- Temperature-rate uses live ingest samples, uses fixed >= logic in V1 and has no hysteresis or threshold time.
- Stale or missing measurements are not treated as cleanly fulfilled conditions.
Examples for Conditions
Direct temperature threshold
Example: Box 2 - Maximum temperature > 80 °C. Optionally with 30 s threshold time and 2 °C hysteresis so short spikes do not immediately open an incident.
Delta between measurement points
Example: |motor bearing left - motor bearing right| >= 12 °C. This makes unusual temperature differences between two ROIs visible.
Fast temperature change
Example: Average temperature rising by at least 5 °C within 60 s. This detects fast heating even before the absolute threshold is reached.
Digital state
Example: DI 1 = on. This allows an external contact, switch or machine state to become part of the same alarm rule.
Digital edge
Example: DI 1 rising edge or falling edge. The rule reacts to a state transition, not only to the current state.
Filters and evaluation logic
Active filters run after the conditions. They use AND logic: if any active filter blocks, no incident is opened and no action is executed. The fixed order is Schedule, Previous incident window, Count window.
Schedule filter
Allows incidents only on defined weekdays and time windows. If the filter is active, unchecked days or times outside the window are blocked.
Previous incident window
Can require that another rule has already triggered within a time window or has explicitly not triggered. This is useful for escalation or dependency logic.
Count window
Opens an incident only after the rule reaches a defined number of new activations within a time window. New false-to-true activations are counted, not every poll cycle.
Actions
Actions are queued by the poller as an action job and executed by the action worker in a defined order: Create event, Set output, Set impulse, Stop impulse, Set torch, Snapshot, then Email. If Set torch follows a successfully started Set impulse in the same action run, the worker waits 500 ms before the AX8 web API call. SMTP failures or later action failures do not automatically undo earlier actions; jobs with write_error or resolve_error finish as done_with_errors.
Create event
Writes a structured rule event with message and optional tags.
Set output
Sets a digital output permanently to on or off. Supports execution on activation and on clear if that response is desired.
Set impulse
Switches a digital output briefly to on or off as one or more timed pulses, optionally pauses between pulses and then resets it automatically.
Stop impulse
Shortens the selected digital output's running impulse sequence so it finishes after at most one more pulse.
Set torch
Switches the camera LED torch on or off at a selected location.
Snapshot
Schedules a DB-backed snapshot job for a location in the project. Trigger states and ROI values remain traceable as evidence while the snapshot worker captures the image asynchronously.
Email
Sends an alarm e-mail to configured recipients. Subject and body can use templates; context such as rule, incident, camera IP, condition results, relevant ROI values and configured actions is appended automatically.
UI excerpts
The small screenshots show the main working areas of the Rules page: Rule, Conditions, Filters and Actions.
JC Thermal Monitor
Incidents
Incidents turns a technical alarm into a traceable case. Operators see what triggered, what has already been acknowledged and which evidence is available.
Functions
- check active, acknowledged, closed and reactivated incidents
- acknowledge, classify, merge and close incidents manually
- open trigger evidence, event history, e-mail status, evidence report and linked snapshots
- create an investigation ticket from an incident
Visible data
- status, severity, trigger time, last activation, deactivation and activation count
- rule details, conditions, ROI values, actions and runtime notes
- snapshot evidence, trigger events, operator notes, report data and ticket links
Help-based details
These points mirror the current application Help texts and describe the most important fields, buttons and runtime rules of this page.
Filters and incident list
- The page follows the current project from the global project selector.
- View switches between open view and closed history.
- Workflow state, Condition, Rule name and Outcome filter the list.
- Rule, Severity, Workflow, Outcome, Condition, Opened, Last active, Last inactive, Count and Ack by summarize each row.
- Ack acknowledges an open incident; Close closes an incident when the workflow allows it.
- A selected row opens the detail panel.
Incident detail panel
- Status updates the workflow state.
- Outcome stores the investigation classification separately from workflow.
- Changed by and Note record the operator and workflow note.
- Incident summary is a longer case summary with findings and follow-up.
- Status, Outcome and Incident summary save automatically without a separate save button.
- Condition List, Action Results, Lifecycle Events and Runtime Diagnosis show the technical cause and effects.
- Linked annotated snapshots compare trigger-time values with the evidence image.
Tickets from an incident
- New ticket title, Priority, Assigned to, Work instruction, Checklist tasks and Required measurements define the investigation ticket.
- Assigned to must be an active technician.
- Checklist tasks creates one task per line; Required measurements creates Measure tasks.
- Create Ticket creates the linked ticket.
- Tickets use the logged-in user from the Home login flow.
- Ticket status changes are completed on the Tickets page in a role- and assignment-aware way.
Runtime states
- Pending waits for threshold timing; Cooldown intentionally blocks quick reactivation.
- Incomplete means missing or stale data; Error means rule evaluation failed.
- Filtered rules can have true conditions without an incident when a filter blocks.
- Action results include output writes, impulse reverts, impulse stops, snapshots, email sent/dry-run, skips and runtime errors.
- Snapshot image time can be slightly later than the trigger because the snapshot worker captures asynchronously.
Additional UI excerpts
The detail images show what appears after selecting an incident: workflow, runtime, evidence and lifecycle records.
JC Thermal Monitor
Tickets
Tickets extends incidents with simple work handling. Operators can hand investigation tasks to technicians, review results and close tickets.
Functions
- create tickets from incidents and assign them to technicians
- maintain priority, work instruction, checklist and required measurements
- allow technicians to add notes, measurement results and attachments
- perform operator review with return to work, completion or cancellation
Visible data
- ticket status, priority, assigned technician, incident reference
- checklist items, work notes, measurement entries and attachments
- review decisions, role permissions and project filtering
Help-based details
These points mirror the current application Help texts and describe the most important fields, buttons and runtime rules of this page.
Roles in the ticket workflow
- Tickets use the logged-in user from the Home login flow.
- Admin can oversee the workflow; assignment is technician-only.
- Operators create work instructions, assign technicians, define tasks, review results and close or cancel tickets.
- Technicians work assigned tasks, measurements, work notes and attachments/evidence.
- Status change shows only allowed next states for the user, ticket state and assignment.
- Admin/operator users can assign new tickets to an active technician in the detail panel.
- Detail actions are role-aware: technicians update assigned task results, measurements, notes and evidence; new checklist tasks remain admin/operator-owned.
- For waiting_operator_review tickets, admin/operator users review the work and either close it or send it back with a review note.
Ticket list
- The list follows the current project and can be filtered by status; there is no separate Tickets scope selector.
- All open hides closed and cancelled tickets.
- Status, Priority, Title, Assigned to, Created and Ticket ID describe each row.
- Open loads the ticket detail panel.
- The list auto-refreshes with the shared UI refresh setting.
Ticket detail workflow
- The header shows title, status, priority, assigned technician, incident ID with report link and ticket ID.
- Assign technician assigns a ticket to an active technician.
- Apply status change saves the selected transition.
- General work note and Add note record general observations.
- Operator review note, Send back to technician, Close note and Close ticket control the review phase; sending back or closing requires a review or close note.
- Work task/Add task adds tasks; Required measurement/Add required measurement adds checklist measurement tasks with the Measure: prefix.
- Task result/note stores task results when the field loses focus; Value, Unit and Save measurement store requested readings directly on the Measure task.
- Additional measurements capture extra measurements outside the checklist.
- Attachments/evidence allows controlled JPG, PNG or PDF files with Open access for existing attachments; Entries shows audit trail, status changes, notes, measurements and attachments.
Limits
- Attachments are limited to 20 MB; JPG, JPEG, PNG and PDF are allowed.
- Closed and cancelled tickets are read-only and protected by backend rules as well.
- Ticket assignment e-mails use the notification service and are log/dry-run by default unless SMTP is enabled.
Additional UI excerpts
The detail images complement the large ticket view with checklist, measurements, notes and history.
JC Thermal Monitor
Users
Users is the administrative user management of JC Thermal Monitor. Viewers, operators, technicians and admins are created and maintained so operation, ticket work and protected system functions remain role-based.
Functions
- create new users with username, display name, temporary password, role, e-mail and phone
- display existing users and edit name, e-mail, phone or role
- reset passwords and force password change at next login
- activate, deactivate or remove inactive users without history references
- protect the last active admin and historical ticket references
Visible data
- role, status, username, display name, e-mail and phone number
- password status such as password set or password change required
- actions for edit, save, reset password, activate, deactivate and remove
Users in detail
Users describes the role-based user administration in JC Thermal Monitor. The page is deliberately administrative: it defines who may configure the system, who works tickets, who may only monitor and which accounts must be retained for security or history reasons.
Roles
Admin
Manages users, roles, password resets, active state and dangerous cleanup actions. Admins can operate configuration, incidents, tickets and protected system functions.
Operator
Runs the normal plant workflow: monitoring, configuration, rules, incidents, snapshots, reports and ticket review within the allowed project context.
Technician / Maintenance
Works assigned investigation tickets and documents work steps, measurements, notes and attachments. Technicians do not finally close tickets themselves.
Viewer
Is intended for read-only monitor views. Viewers can monitor Home and Visualization, but cannot change configuration, tickets or outputs.
Create user
- Username is the unique login name and is not edited later from the UI.
- Display name is the readable name used in workflows, assignments and UI views.
- Temporary password is set by the admin and must be changed on the next login.
- Role defines the permission group: Admin, Operator, Technician/Maintenance or Viewer.
- Email and Phone are optional contact fields for reference, ticket work and configured notifications.
- Create adds the user as active and marks the password as change required.
User list
- Role shows the current permission group.
- Status shows whether the user is active and can log in.
- Username remains the stable technical login name.
- Name, Email and Phone show the maintained profile and contact data.
- Password shows whether a password is set or must be changed on the next login.
- Actions contains the currently allowed operations for that user.
Buttons and actions
Refresh
Reloads the user list, including inactive users. This is useful after changes or when several admins are working.
Edit
Switches a table row into edit mode. Name, Email, Phone and Role can be edited; Username remains unchanged.
Save
Saves the profile fields or role changed in edit mode. The last active admin remains protected.
Cancel
Discards the currently displayed edit state and returns the row to read mode.
Reset password
Sets a new temporary password and forces a password change on the next login.
Deactivate
Blocks login while keeping historical ticket and workflow references. The current active user and the last active admin are protected.
Activate
Re-enables an inactive user so they can log in again and use their role.
Remove
Permanently deletes only inactive users without database history. Users referenced by tickets or workflows remain deactivated instead of deleted.
Safety rules
- Only logged-in admins use this page.
- Users are normally deactivated instead of deleted so reports, tickets and history remain traceable.
- Inactive users cannot log in and do not appear as usable actors in role-based workflows.
- Auto logout for Admin, Operator and Technician is configured globally in Settings; Viewer sessions use the configured Viewer session lifetime.
- The last active admin cannot be deactivated or lose the admin role.
JC Thermal Monitor
Snapshots
Snapshots provides the image evidence for measurements and incidents. Manual and rule-based snapshots are stored, linked and displayed with annotations when needed.
Functions
- trigger manual snapshots per device
- monitor rule-based snapshot jobs
- open stored and annotated snapshot files through protected links
- clean up old or no longer needed snapshot data depending on role
Visible data
- job status, camera, incident, trigger event, capture time
- file paths, annotation status, error code, REST/RTSP capture notes and creation time
- snapshot counters, delete options and read-only access
Help-based details
These points mirror the current application Help texts and describe the most important fields, buttons and runtime rules of this page.
Header and filters
- Delete all snapshots removes visible snapshot records/files only for roles allowed to mutate snapshots and only when evidence is no longer needed.
- Status filters queued, running, done, failed or all.
- Rule id and Incident id narrow the list to one rule or incident.
- Limit loads the newest rows in the range 1 to 200.
- Only failed switches to failed-job troubleshooting mode.
- The list follows the current project and shows backlog/failure counts over time.
Job list and detail
- Created, Status, Rule, Device, Attempts and Result describe each job.
- Result shows file links, error details or cleanup/delete controls depending on job state.
- Job Detail shows started/finished, duration, error text, snapshot links and trigger context.
- Admin and Operator can delete individual failed jobs, stored snapshots or matching bulk cleanup actions.
Job states and evidence
- Queued waits for the snapshot worker; Running is claimed by the worker; Done was stored; Failed needs error analysis.
- Kind current means a rule snapshot followed the camera's current image mode.
- Manual/API snapshots may still show explicit values such as thermal, visual or overlay.
- Annotated snapshot links open the rendered evidence image.
- Overlay values are frozen from trigger-time runtime data; the image can be slightly later because capture is asynchronous.
- Snapshot capture runs in the snapshot worker so alarm and poller processing are not blocked by slow camera capture.
- REST image capture uses the configured timeout before falling back to RTSP when needed.
- Deleted snapshots lose their file reference for evidence views.
- Snapshots still needed for investigation or reporting should not be deleted.
JC Thermal Monitor
Health
Health shows not only whether the web application is running, but whether the entire monitoring operation is fresh, plausible and complete.
Functions
- diagnose camera and Modbus communication
- check ROI freshness, measurement age and rule states
- monitor worker heartbeats for poller, snapshot worker, action worker and impulse worker
- check e-mail action status, Camera Impulse Writes and snapshot runtime
- configure and close system incidents for selected health warnings
- clean health state deliberately when outdated diagnostic data is misleading
Visible data
- device health, ROI freshness, rule runtime, action runtime
- poller load, poller loop, worker heartbeats, action-job status and snapshot job state
- impulse runtime, system incidents, e-mail sent/dry-run, Camera Impulse Writes, last errors and technical diagnostic messages
Help-based details
These points mirror the current application Help texts and describe the most important fields, buttons and runtime rules of this page.
Toolbar and workers
- View switches between Full and Attention only; Attention only hides healthy rows.
- Clean Health deletes stored health rows and runtime diagnostic rows for clean troubleshooting after old diagnostics are no longer useful.
- System incidents turns selected Health warnings into visible Warning rows after the configured delay.
- Background workers shows whether poller, snapshot worker, action worker and impulse worker heartbeats are fresh or stale.
- Poller load shows loop duration, actual interval, targets, OK, failed, backoff, rows written, projects evaluated and finished.
- Backoff means failed status targets are retried less aggressively.
Camera runtime
- Camera Modbus Lock shows waits, extended waits, timeouts, long holds and unlock warnings.
- Recent Camera Modbus Events show camera, operation, event type, wait/hold time and message.
- Camera Measurement Snapshot shows health of the shared measurement cache and refresh errors.
- Recent Camera Measurement Events show cache state, snapshot age, max age and diagnostic message.
- Camera Impulse Writes shows physical DO write attempts, skipped same-state writes and write errors.
- Image live started means the app sent an AX8 resume video command after freeze detection.
Snapshot, impulse and project state
- Snapshot job runtime shows backlog, running jobs, failed jobs, stale running jobs, last success/failure and last error.
- System incidents configures which Health warnings become Warning rows, with severity, show-after delay, cooldown, optional e-mail recipients and a Close action.
- Warning means the configured Health problem is still present; Resolved remains visible until an operator clicks Close.
- Impulse runtime shows target output, health, current impulse, phase, pending impulse, incident relation, output value and last error.
- Impulse Churn Suppression shows intentionally suppressed repeated or already-active impulse activations.
- Devices shows location, device, online/offline, last poll, last seen, age and latest device error.
- ROI freshness shows whether enabled ROIs have fresh enough measurement data.
- Rule runtime shows condition state, incomplete reason, pending, last evaluated and last error.
- Action diagnostics shows health, status, transition, last attempt/success, failure count, last error and action jobs with done_with_errors.
Reading health states
- Pending: threshold timing is running; Cooldown: activation is temporarily blocked.
- Stale: measurements are too old; Missing: measurements are unavailable.
- Skipped action: trigger mode did not match the incident transition.
- Email sent/dry-run: rule e-mail was sent or intentionally logged without SMTP delivery.
- Camera Impulse Writes show successful, redundant and failed AX8 DO writes.
Additional UI excerpts
The detail images complement the large Health view with workers, poller/camera runtime and rule/action diagnostics.
JC Thermal Monitor
Visualization
Visualization is used for analysis. Users can compare thermal measurement series, incident activations and digital states in the same time window.
Functions
- search and select thermal and digital series in the Series Selector
- analyze Thermal History, Incident Timeline and Digital Timeline together
- control the time window by preset, From/To, shifting or double-click drill-down
- inspect incident markers and buckets with tooltip information including highest severity
- use Auto-Refresh and Print / Save as PDF for monitoring and analysis
Visible data
- spot and box metrics such as temperature, minimum, maximum and average
- Thermal History with multiple colored temperature series
- Incident Timeline with activation markers, bucket severity, status and incident timestamps
- Digital Timeline with DI/DO states, edge events, activity markers and stable location/DI/DO ordering
- series colors, current runtime values, time window, resolution and data availability
Visualization in detail
Visualization is the shared analysis view for measurements, incidents and digital states. The page helps users understand what happened before, during and after a rule activation.
Thermal History
- upper chart for selected spot and box temperature series
- multiple series are displayed together in different colors
- the last 15 minutes can use current live buffer values
- longer time windows use a simpler aggregated representation
Incident Timeline
- middle chart with incident activations in the selected time window
- markers show rule, activation time, severity, status, opened and closed
- when many markers are close together, clusters or additional markers are summarized and colored by highest severity
- a double-click on the timeline sets a 15-minute drill-down time window
Digital Timeline
- lower chart for DI and DO states
- short positive and negative pulses remain visible
- up to 15 minutes, observed state changes are reconstructed as a step chart
- for longer time windows, digital activities are shown bucketed
Selection and time window
Series Selector
The left selection shows project-related series by location, ROI and metric. Search filters by these values; the Digital Timeline follows the catalog order by location name, then DI before DO. Current runtime values, stale notes, no value and not present help assess data quality.
Time window
From and To can be set directly. In addition, presets from Last 15 min to Last 365 days and arrows for shifting the currently selected window are available.
Apply and report
Apply reloads the current selection. Print / Save as PDF creates a printable snapshot with report header fields from Settings, selected series, charts, selected time range and project time zone.
Interactions
Double-click on a chart
A double-click in Thermal History, Incident Timeline or Digital Timeline opens a 15-minute drill-down time window around the clicked timestamp.
Inspect incident markers with the mouse
When the cursor is over an incident circle, the browser shows a detail tooltip with rule name, activation time, severity, status, opened and closed timestamp. While a tooltip is active, auto-refresh does not interfere.
Display unit and Viewer mode
The global temperature display unit changes only UI labels and formatting; History API and stored values remain Celsius-based. After inactivity logout, admin, operator and technician users must return through Home/Login; viewer sessions use the configured viewer session lifetime.
Cluster and bucket markers
When several incidents are too close together or a long time window is aggregated, markers show the count and a short breakdown by rules.
Limits and data logic
- maximum 24 Thermal Series at the same time
- maximum 12 Digital Series at the same time
- time windows over 365 days are rejected
- time windows over 6 hours use an aggregated thermal representation
- Digital History depends on observed or stored edge events
- up to 15 minutes, Digital History is reconstructed as a step chart from edge events
- for longer windows, Digital History switches to bucketed activity so short impulses remain visible
UI excerpts
The small screenshots show the Series Selector and the three linked analysis areas: Thermal History, Incident Timeline and Digital Timeline.
JC Thermal Monitor
Settings
Settings collects runtime parameters that do not belong directly to a single rule or location, but influence system operation.
Functions
- configure polling and ingest intervals
- configure auto-refresh times for UI pages
- switch temperature display between Celsius and Fahrenheit
- maintain project-specific Report Settings with customer, department, site, logo, footer and time zone
- test e-mail configuration and check diagnostic values
Visible data
- measurement interval, offline timeout, live history stale limit and measurement-history retention
- UI refresh values, snapshot HTTP timeout, discovery limits
- report settings, e-mail dry-run state, SMTP test response and last update
Help-based details
These points mirror the current application Help texts and describe the most important fields, buttons and runtime rules of this page.
Header and project values
- Refresh reloads app settings, current project sampling, project report settings and e-mail status, discarding unsaved edits.
- Save settings is the single save action for global settings plus current project sampling and report settings.
- Unsaved changes appears after editing a saved field and clears after saving or refreshing.
- Last updated shows when the page loaded or saved.
- The restart note marks settings read by long-running worker processes and may require service restart.
- Default sample period (s) applies to the current project and is used when no location or ROI override exists.
Report Settings
- Customer/company, Department and Site/plant appear in incident evidence reports and Visualization print.
- Logo URL points to a header image; empty means no customer logo.
- Project time zone controls UI and report timestamps.
- Footer text appears at the bottom of generated reports.
- Save settings stores these project-specific report fields together with the other settings on this page.
Polling and runtime defaults
- Device status poll interval controls online/offline status polling.
- Measurement ingest interval (s, DI/DO sampling cadence) controls how often runtime measurement ingest samples camera ROI values.
- Impulse worker poll interval controls output timing and auto-revert of the impulse worker.
- Device offline after is the freshness window for overview and health.
- Polling intervals and the impulse worker poll interval require a worker service restart after saving.
- Temperature display unit changes UI formatting; stored/API values remain Celsius-based.
- UI auto refresh controls the shared automatic refresh.
- Auto logout after inactivity logs out inactive users.
- Virtual alarm edge hold time keeps edge evidence briefly available.
- Live thermal gap join limit controls gaps in the last-15-minute live chart.
- Snapshot HTTP timeout before RTSP fallback controls REST capture before RTSP fallback.
Other, retention, Discovery and e-mail
- Discovery timeout and Discovery max results set the defaults for network scans and the result table.
- Measurement history retention (days) controls how long automatically stored measurement history rows remain in the database.
- Current measurement rows shows the currently counted number of stored measurement-history rows; Refresh reloads this value, but it only grows when ingest actually writes new history rows.
- A value of 0 disables automatic measurement history cleanup.
- Changing and saving the retention value runs the measurement cleanup immediately; the app also checks cleanup at startup and once per day while running.
- Tickets, rules, incidents, trigger evidence and snapshots are not deleted by this setting.
- The Email card shows enabled, dry-run and non-secret SMTP configuration.
- Test recipient and Send test email check the same notification service used by ticket and rule e-mails.
- With dry-run, test and rule e-mails are logged but not sent by SMTP.
- SMTP host, port, username, password, sender, enabled and dry-run come from .env; changes need service restart.
Features
What the system covers functionally.
ROI and measurements
Supports spot and box ROIs, digital inputs and digital outputs. Measurements can be stored per ROI with individual sampling.
Alarm rules
Rules work per project with direct temperature, delta checks, digital states, edges, rate of change, hysteresis and cooldown.
Actions
On activation or clear, action jobs are queued: events, outputs, impulses, impulse stop, snapshot requests, torch control and e-mail run outside live ingest.
Incident evidence
When an incident first triggers, relevant values are frozen. Later linked snapshots add dynamic image evidence.
Evidence reports
Incident and trigger information can be displayed as a printable report view so cause, state and measures remain traceable.
Roles and access
Home and Visualization can serve as Viewer monitor views. Configuration, tickets, interventions and snapshot files are protected depending on role.
Technology
On-premise architecture for local operation.
The application consists of a FastAPI web service, PostgreSQL/TimescaleDB, Alembic migrations and separate background processes. Poller, action worker, snapshot worker and impulse worker run separately so data acquisition, action jobs, image jobs and impulses can be monitored independently.
- Docker Compose runtime with database, migration, app, poller, action worker, snapshot worker and impulse worker.
- Heartbeat-based worker diagnostics instead of pure process checks.
- Local snapshot and runtime state storage.
- Authenticated snapshot delivery and role-based monitor/operator permissions.
- E-mail notifications with dry-run mode and SMTP test.