MQTT data flow
Broker-based publish/subscribe communication for PLC gateways, ESP32 nodes, and browser-ready dashboards.
SCADA • IoT • MQTT
SCADA, IoT & MQTT Dashboard Monitoring
Factory visibility for machine status, alarms, production counters, energy, and process data.
Java Electrindo helps factories connect PLCs, gateways, sensors, and dashboards into one practical monitoring system for operators, technicians, and supervisors.
Solution selector
Start from the operational problem, not the protocol name
Choose the outcome you need. The page will take you to the most relevant section and prepare a focused Javabot question.
Selected focusChoose one option above
Core modules
What the solution covers
The system should not stop at one screen. It should connect field data, alarm visibility, operator use, and practical reporting.
SCADA dashboard visibility
Live status, trends, counters, alarm summaries, and payload tables for operators, engineers, and supervisors.
Display blocks and reporting
Gauge, lamp, trend, event log, payload inspection, and role-based reporting blocks for day-to-day operations.
Key protocols
MQTT and Modbus in one practical view
Both matter. Modbus is practical for reading industrial devices and machine registers. MQTT is practical for distributing that data into dashboards, alarms, and remote visibility.
MQTT for dashboards and remote monitoring
MQTT uses publish/subscribe messaging through a broker. It is a strong fit for dashboard visibility, alarms, event distribution, and browser-based monitoring.
Modbus for device and register integration
Modbus uses register-based communication for PLCs, meters, VFDs, and instruments. It is a practical base layer for local machine data collection before SCADA or MQTT distribution.
Practical data path
How Modbus and MQTT work together
Modbus commonly reads local machine data. A gateway then validates and distributes selected values through MQTT to dashboards, alarms, and reports.
One project may use one protocol or both
The exact design depends on the machine, available register map, network boundaries, update rate, and whether remote visibility is required.
Monitoring scope
What can be monitored?
A practical dashboard should show the values that help operators, technicians, and supervisors act faster.
Machine status
Run, stop, idle, fault, mode, cycle state, and simple production condition visibility.
Production counters
Batch count, output count, reject count, shift target, and simple productivity tracking.
Process values
Temperature, pressure, level, flow, humidity, pH, and other process feedback values.
Energy monitoring
Voltage, current, kWh, load trend, demand pattern, and basic energy visibility.
Alarm tracking
Fault code, alarm time, recovery status, repeated alarm pattern, and maintenance priority.
Operator visibility
Dashboard screens, trend charts, event logs, payload tables, and role-based operation views.
Live dashboard walkthrough
See the full monitoring story in one screen
A useful SCADA and IoT dashboard should combine machine status, process values, counters, energy, alarms, and operator-facing event visibility in one clean operational screen.
- Top summary blocks show whether the area is healthy before the operator reads details.
- Trend and process values help technicians judge behaviour, not just a single number.
- Alarm and event views support quick response, traceability, and maintenance follow-up.
Industry examples
Monitoring systems by industry
Different sectors care about different data points. The monitoring structure should follow the actual process and operating risk.
Agriculture
Monitor irrigation pumps, greenhouse climate, water tank level, flow, and utility alarms for practical field visibility.
Pharmaceutical
Monitor room temperature and humidity, differential pressure, batch status, alarms, and utility condition with stronger discipline.
Textile
Monitor dyeing cycle, machine status, temperature, chemical dosing, batch progress, and alarm visibility across dyehouse operations.
Automotive
Monitor station status, cycle time, torque process, line stoppage, Andon escalation, and repeat downtime patterns.
Incinerator
Monitor burner temperature, chamber pressure, fan status, feed conveyor, and critical alarms so the incinerator runs safely and consistently.
HVAC / Chiller
Monitor chilled water temperature, supply and return, pump status, pressure, room condition, and utility alarms for plant comfort and process stability.
Manufacturing value
Why MQTT-based SCADA & IoT matters
The purpose is practical: make machine conditions easier to see, respond to, and analyze without waiting for manual reports from the production floor.
Real-time visibility
Machine status, counters, alarms, and sensor values can be shown in one dashboard.
Lower downtime risk
Trend and alarm data help technicians notice abnormal patterns earlier.
Practical integration
Data can come from PLC gateways, ESP32, HMI gateways, sensor nodes, or edge devices.
Example dashboard views
A practical deployment usually combines overview KPIs, trend charts, active alarms, and a simple event or payload table.
- Overview KPIs for status, counts, and utility use.
- Trend views for temperature, pressure, or energy behavior.
- Alarm/event tables for troubleshooting and accountability.
Performance and quality
KPI examples for line performance and quality
Not every dashboard stops at visibility. Some projects also need KPI logic such as OEE, reject quality, and counted output for production accountability.
OEE monitoring
Track availability, performance, quality, and total OEE so teams can see whether downtime, speed loss, or rejects are reducing effective output.
Capsule count and reject quality
Useful for pharmaceutical or packaging lines that must count accepted capsules, detect rejects, and review quality trends by shift or batch.
Operational boundary
Monitoring and control are not the same thing
A trustworthy project separates read-only visibility from commands that can affect equipment or production.
Monitoring mode
- Read machine status and sensor values
- Review alarms, counters, and trends
- Export reports without changing machine logic
Controlled action mode
- Acknowledge alarms or send approved commands
- Require role permissions and commissioning
- Validate safety logic, network path, and operating limits
Remote control is enabled only after machine logic, permissions, communication paths, and safety boundaries are validated.
Deployment options
Choose the right operating environment
The best deployment is the simplest architecture that meets operational, network, security, and reporting needs.
Local network
Dashboard runs inside the factory LAN and can support internal visibility without relying on public internet access.
Hybrid
Local operation remains primary while selected summaries or approved data are available remotely.
Cloud-connected
Suitable for selected multi-site or remote reporting use cases with controlled credentials and network planning.
Typical project sizes
Choose a scope that matches the operational need
These are planning references, not fixed-price packages. Final scope depends on devices, protocols, data points, network conditions, and validation requirements.
Starter monitoring
One or two machines with basic values, alarms, local dashboard, simple trends, and export.
- Local visibility
- Basic alarm and trend
- Simple CSV or report export
Production monitoring
Several machines with user roles, alarms, trends, reporting, and gateway integration.
- MQTT or Modbus integration
- Operator and engineer views
- Shift and downtime summaries
Factory visibility
Multi-area or multi-line deployment with OEE, management reports, local server, or hybrid access.
- Cross-area dashboard
- OEE and KPI reporting
- Role and access governance
Integration sources
Supported source devices
The system can be adapted to the available machine, panel, gateway, and network condition.
PLC gateway
ESP32 / sensor node
HMI gateway
Modbus TCP / RTU bridge
MQTT broker
SCADA dashboard
Industrial PC / local server
Cloud or local network deployment
System health and reliability
A dashboard must show whether its data can be trusted
Industrial monitoring should expose communication health, data age, invalid values, reconnection state, and alarm history instead of silently showing an old number.
Gateway connection
Online, reconnecting, offline, and last successful communication.
Data freshness
Timestamp and stale-data limits prevent old values from looking live.
Polling and subscription
Modbus poll failures and MQTT subscription state are visible.
Value validation
Invalid ranges, missing engineering units, and malformed payloads are flagged.
Local buffering
Selected data can queue locally during temporary network interruption.
Audit and acknowledgement
Alarm acknowledgement, recovery, user, and time remain traceable.
Data-quality states
The interface should visually separate these conditions:
LiveCurrent source value
StaleUpdate is overdue
InvalidOutside accepted rules
DisconnectedSource is unavailable
SimulatedTest or demonstration source
ManualEntered by an authorized user
Alarm lifecycle
A complete alarm record follows the condition from detection to reporting.
- 1Normal
- 2Active
- 3Acknowledged
- 4Recovered
- 5Closed and reported
Useful fields include first occurrence, last occurrence, repeat count, priority, acknowledgement user, recovery duration, and maintenance note.
Project estimation checklist
Prepare a clearer starting brief
This checklist does not calculate a price. It organizes the facts needed for a useful technical discussion.
Prepared starting brief
Project readiness
Information that makes integration faster
Complete information reduces assumptions, shortens mapping work, and helps define a realistic scope before commissioning.
What we need from your site
- PLC, HMI, meter, sensor, or gateway model
- Available protocol and network details
- Register map, topic list, or tag reference
- Alarm list and engineering units
- Required users and access levels
- Reporting, retention, and export expectations
Typical project deliverables
- Dashboard layout and tag mapping
- Alarm list and user-role matrix
- Trend and reporting configuration
- Commissioning and validation checklist
- Operator handover notes
- Configuration backup according to project scope
Operations workflow
Roles, access, and reporting rhythm
A public-ready monitoring page should show not only data sources, but also who uses the dashboard and how the reporting cycle supports decisions.
Typical access levels
GuestRead-only access for visitors or management review.
OperatorDaily production view, alarms, counters, and process status.
EngineerDeeper trend review, payload inspection, and troubleshooting context.
SupervisorShift coordination, alarm review, summary approval, and cross-area production visibility.
AdminUser management, dashboard settings, and role control.
Summary and reporting cycle
Daily summaryShift output, active alarms, downtime notes, and urgent follow-up items.
Weekly summaryTrend review, repeat faults, utility use, and machine performance checks.
Monthly summaryManagement view for KPI movement, maintenance patterns, and improvement priorities.
These summaries can be prepared manually or assisted by AI after operators validate the raw production data.
Example role-permission matrix
Final permissions are approved during commissioning. A role should receive only the access needed for its responsibility.
| Capability | Guest | Operator | Engineer | Supervisor | Admin |
|---|---|---|---|---|---|
| View dashboard | ✓ | ✓ | ✓ | ✓ | ✓ |
| Acknowledge alarm | — | ✓ | ✓ | ✓ | ✓ |
| Export reports | — | Limited | ✓ | ✓ | ✓ |
| Edit tag mapping | — | — | ✓ | — | ✓ |
| Manage users | — | — | — | — | ✓ |
| Send approved command | — | Configured | Configured | Approved | Configured |
Useful report outputs
Reporting should match how the operation reviews performance and follows up problems.
Shift handoverDowntime summaryRepeated-alarm reportEnergy-use summaryOEE loss reportMaintenance follow-upBatch / production summaryManagement KPI review
Project flow
Typical implementation flow
A controlled workflow helps avoid unclear data points, unsafe control assumptions, and dashboard confusion.
Site survey and data-point list
List tags, topics, machine status, sensor values, counters, and alarms.
Gateway and protocol mapping
Connect PLC, edge device, ESP32, or HMI gateway to a reliable data path.
Dashboard and alarm design
Create display blocks, gauges, lamps, trends, payload tables, and alarm views.
Testing and commissioning
Validate update behavior, operator flow, alarm logic, and safe permission boundaries.
Handover and documentation
Prepare usage notes, topic references, login roles, and maintenance guidance.
| Stage | Expected output | Acceptance check |
|---|---|---|
| Survey | Device, tag, alarm, and network list | Scope and missing information confirmed |
| Mapping | Register, topic, unit, and engineering map | Values verified against source devices |
| Build | Dashboard, trends, alarms, roles, and reports | Operator workflow reviewed |
| Validation | Tested communication, values, alarms, and permissions | Known failures and recovery paths tested |
| Handover | User access, documentation, backup, and guidance | Responsible users acknowledge receipt |
Frequently asked questions
Practical questions before starting
These answers define the usual starting point. Final compatibility still depends on the actual device, firmware, protocol, and site network.
Can the dashboard work without internet?
Yes. A local LAN deployment can provide internal monitoring. Remote access depends on the approved network design.
Can the dashboard read PLC data?
Yes, when the PLC or gateway exposes a supported and documented data path such as Modbus TCP, Modbus RTU, or MQTT.
Can ESP32 devices be used?
Yes, for selected sensing, logging, prototypes, and gateway tasks. Industrial use still requires proper power, enclosure, network, and reliability planning.
Can users have different access levels?
Yes. Guest, operator, engineer, supervisor, and admin roles can be separated according to the approved responsibility matrix.
Can the system generate reports?
Yes. Daily, weekly, and monthly summaries can be configured when the necessary source data is available and validated.
What should I send Javabot first?
Share the device model, protocol, available register or topic reference, values to monitor, alarm expectations, and deployment preference.
Ready to see the MQTT dashboard demo?
Open the controlled dashboard, enter as guest, and test MQTT display blocks, trends, and payload inspection.
Final compatibility depends on the actual controller model, firmware, register map, protocol, wiring, network condition, and operating requirements. Live control functions require commissioning and safety validation.