Current plan
M-01 running
- Energy over 30 min
- 31.1 kWh
- Peak power
- 64.7 kW
Hardware / Industrial 4G LTE Router
Industrial 4G LTE Router
A gateway for control cabinets, PLCs and meters, with Ethernet, RS485, 4G LTE and Node-RED.
Industrial 4G LTE Router
Details and scope
Details are based on supplier reference images. Confirm the model, specifications, included accessories and AIoT TH Cloud integration before quotation.
- Interfaces
- 1 WAN + 1 LAN · 2 RS485
- I/O
- 1 DI + 1 DO
- Power
- 9–36 V DC
- Software
- Node-RED · Linux / OpenWrt · Python
- Data path
- RS485 / Ethernet → Gateway → Cloud
- Before ordering
- Confirm variant, firmware, accessories and destination integration
- Reference operating temperature
- −40°C to 85°C, as stated in the supplier image
- Reference enclosure
- Metal · IP30
Interface and feature references
More images and details
Suitable device connections
For factories, electrical cabinets and wired measurement points.
- PLCs and meters with supported communication interfaces
- Control cabinets and RS485 / Ethernet collection points
- Confirm the protocol and values exposed for reading
Installation preparation
Have the site owner confirm power, installation position and networking before selecting accessories.
- Check model-specific power requirements and cabinet space
- Survey antenna placement and 4G or LAN access
- Prepare a point list and compare readings with source devices
Software and delivery scope
DO is a hardware capability. AIoT TH Phase 1 reads data; device control and optional software require a separate project scope.
- Exact variant, firmware and preinstalled software
- Antennas, cables, power supply and mounting parts specified in the quotation
- Agreed cloud setup, testing and handover documentation
FACTORY APPLICATIONS
From a site problem to a practical system
Illustrative system designs with equipment, data, responsible teams and project conditions. These are not customer case studies.
DIGITAL TWIN · SIMULATED
Simulated digital twin: site, equipment and events in one view
This simulated digital twin is a model running in your browser. It does not mirror a PLC or customer site and does not control equipment.
Loading 3D map…
Live (simulated) · 08:00:00
Illustrative 3D layout, not surveyed coordinates. Scene labels show values from the simulated twin. Select equipment on the scene or in the twin tree.
Total power62.0 kW
M-02 temperature46.0 °C
M-02 vibration2.10 mm/s
WHAT-IF · SIMULATED
Current plan vs alternative · next 30 simulated minutes
Alternative
M-01 stopped
- Energy over 30 min
- 17.4 kWh
- Peak power
- 36.2 kW
Computed from the browser simulation to compare choices; not a prediction for a real site.
Inspection and command history
Select a scene device, then inspect or control it
Data path
PLC / Meter → Modbus TCP / RS485 → Gateway → MQTT TLS :8883 → Monitor
CCTV uses IP over PoE / NVR independently of LoRaWAN. This scene is illustrative and has no live video.
Operator view
Connect power readings and machine states to site locations for maintenance inspection.
ILLUSTRATIVE SYSTEMUnderstand where and when the factory uses energy
Example system: main switchboard, production line and compressed air
Move from a monthly total to area-level meter readings that engineering teams can use to investigate loads and plan improvements.
Suppose a factory wants to monitor three metering points. Start with readings and history for each point. Cost calculations or energy per unit require additional data and agreed formulas; they are not automatically included.
Problems and practical approaches
The monthly bill does not identify high-load areas
Teams investigate several cabinets and may act on the wrong source
Approach · Define main and submeter boundaries, collect readings by point and compare periods with similar production conditions
Manual readings are recorded at different times in separate files
Differences may reflect timing rather than actual load changes
Approach · Read supported meters through a gateway, standardize names, units and timestamps, and compare values with the meter display
An unusual load is discovered only after the shift
The team lacks event-time data to prioritize equipment checks
Approach · Agree site-specific thresholds, enable scoped notifications and assign a person to investigate the equipment
Equipment and components
- Three compatible meters: main, production line and compressor
- An industrial gateway with matching interfaces, power and connectivity
- Cloud points organized by site, area and asset
- Dashboards, history and notifications within package scope
Data to monitor
- Power in kW and cumulative energy in kWh
- Voltage, current and power factor where exposed by the meter
- Last update time and connectivity status
Data journey
- Electricity meters
- RS485 / Ethernet
- Industrial gateway
- AIoT TH Cloud
- Dashboard / alerts
Workflow and responsibilities
Define circuit boundaries
Electrical engineer
Select comparison points and identify main versus submeter boundaries to avoid double counting
Configure acquisition
Equipment owner
Verify registers, units, CT ratios and polling intervals for the actual meter
Validate source readings
Installer and site team
Compare the dashboard with the meter at matching times and record discrepancies
Monitor load patterns
Energy engineer
Read current values and history alongside operating schedules, not totals alone
Investigate notifications
Maintenance
Check equipment and production conditions before deciding on an operational change
Review changes
Production manager
Compare similar operating periods and record changes and remaining data gaps
How each factory team benefits
Energy engineering
Identify periods and areas that merit further load investigation
Maintenance
Use timestamped readings when checking notified equipment
Production
Review machine-start schedules and shift changes with supporting data
Management and cost planning
Support improvement proposals with measurements; cost formulas still require separate validation
Who this is suitable for
- Factories with multiple circuits or buildings that need separate energy readings
- Engineering teams with readable meters and an owner for source validation
- Projects starting with critical points before a wider rollout
Acceptance checks
- Dashboard values match meter units and scaling
- Stale or missing data and timestamp meaning can be identified
- Owners can find a known event and test notifications within scope
ILLUSTRATIVE SYSTEMSee machine states and investigate events with history
Example system: a packaging line with several stations
Connect PLC or sensor signals so production and maintenance use the same observations before developing performance analytics.
This illustrative line has feeding, filling and packing stations. Start with run/fault states and counters exposed by the PLC. Existing controls are not automatically modified, and an offline gateway is not treated as evidence of a machine stop.
Problems and practical approaches
Staff must walk the floor to see which machines are running
Shift leaders lack a shared view across multiple machines
Approach · Define readable PLC states and display them by machine with update timestamps
Stop records rely on memory or retrospective notes
Investigations begin without reliable times and source signals
Approach · Retain relevant states and readings to identify investigation periods; a person still confirms the actual cause
OEE is requested, but only a run signal is available
A calculated number may not represent production correctly
Approach · Separate acquisition from analytics and define shifts, counts, good units and ideal cycle times before agreeing OEE formulas
Equipment and components
- PLCs or sensors exposing agreed states
- A gateway with matching Ethernet, RS485 or digital-input interfaces
- Cloud assets separated by station
- Dashboard values and history shared by production and maintenance
Data to monitor
- Run, stop or fault values defined with the machine owner
- Production counters, temperature or current where a data source exists
- Gateway connectivity and update time, separate from machine state
Data journey
- PLC / sensor
- Readable values or states
- Gateway
- Cloud assets
- Production view
Workflow and responsibilities
Define machine states
Production and PLC owner
Agree run, stop and fault meanings, including changeovers and planned stops
Prepare a signal list
Automation engineer
Document addresses, types, units and a read method that does not interfere with control
Check actual events
Installer and operator
Compare displayed states with machine behavior during an agreed test
Monitor the shift
Shift leader
Check states and freshness, using history to select periods for investigation
Investigate on site
Maintenance
Inspect the machine and record causes through the factory process rather than assuming them from one signal
Review analytics inputs
Production engineering
Validate counts, shifts and formulas before adding downtime or OEE analysis
How each factory team benefits
Shift leaders and production
Coordinate using station-level readings and event timestamps
Maintenance
Use historical signals as evidence rather than relying only on recollection
Automation engineering
Maintain and extend the system using shared point definitions
Factory management
Identify available and missing inputs before investing in performance analytics
Who this is suitable for
- Factories with readable PLC values or accessible state signals
- Production and maintenance teams willing to agree state definitions
- Teams collecting reliable inputs before separately scoped downtime or OEE analytics
Acceptance checks
- Dashboard states match the agreed machine test cases
- Machine stops can be distinguished from gateway disconnections
- Machine owners accept the documented signal definitions
DETAILS & PLANNING
Before connecting the router to industrial equipment
RS485 communication needs matching settings
RS485 defines an electrical interface, not universal protocol compatibility. For Modbus RTU, verify baud rate, parity, stop bits and slave IDs against the correct register map. Port count alone does not establish practical device capacity without reviewing the bus and polling configuration.
- Check data types and byte ordering
- Agree polling intervals and timeouts
- Have the responsible installer verify wiring and terminations
Scope Node-RED and Python maintenance
The reference images advertise Node-RED and Python customization. Confirm the firmware, resources and packages of the delivered variant, plus who maintains the flows or code. Adding gateway logic does not authorize PLC control without a separate design.
- Confirm firmware and bundled software
- Record configuration and recovery procedures
- Separate data acquisition from control work
Systems related to this page
Review each system’s scope before opening it or using the example to plan your project.
Simulated data · No physical PLC commands
Factory Operations
Explore machine states, energy, simulated readings and alarms with a 3D scene and example event history.
Live public observations · Read-only
Flood Monitoring
View rain, water-level and road-water observations on a station map with timestamps and source attribution.
Questions about this topic
Are all pictured VPN options included?
The images are supplier references. Confirm the delivered variant, firmware and network requirements before specifying VPN capabilities for a project.
Can the DO port immediately control devices through AIoT TH?
No. DO is a hardware capability; Phase 1 of the platform focuses on reading data. Control requires a separately agreed design.
Choose hardware and software that work together
Start with your equipment and data points, then define the right site scope.