Current plan
M-01 running
- Energy over 30 min
- 31.1 kWh
- Peak power
- 64.7 kW
Software / AIoT TH Cloud
Readings, history and alerts in one place
Factory monitoring with dashboards, history and alerts, plus project-scoped SCADA, factory control and OEE integration.
AIoT TH Cloud
Details and scope
Group measurements by area or asset and choose what your team needs to follow on a dashboard. Available capabilities and quotas depend on the package assigned to each site.
- Access
- Web browser on desktop, tablet and mobile
- Organization
- Organization → Site → Area → Asset, linked to gateway data points
- Views
- Point values, historical charts and connectivity status
- Alerts
- Configured thresholds and device-offline events, with LINE and email channels as configured
- Users
- Role-based access within the organization
- Subscription
- Monthly package per site; current quotas and conditions are listed on the pricing page
Working with site data
Prepare the data before building a dashboard so each reading has a clear meaning.
- Create the site structure and register the gateway
- Name data points, set units and link them to assets
- Compare incoming values with the source equipment
- Configure dashboards, thresholds and responsible recipients
History and packages
The current offer retains detailed data for 30 days. Aggregated history, additional retention and point quotas depend on the package. Confirm the quotation before starting a project.
- Lite, Standard, Professional and Enterprise
- Select around gateway count, data points and required capabilities
- The demo uses simulated data to demonstrate the interface
Capabilities in development
External APIs, advanced dashboards, flows and AI insights are on the roadmap; they are not all currently available.
- AI examples in the demo are scripted scenarios
- ERP/MES and control-system integrations require an agreed project scope
- Review capabilities and status on the platform page
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
ILLUSTRATIVE SYSTEMMonitor pumps, tanks and distributed measurement points
Example system: factory water tanks and pump stations
Give teams the latest readings, update times and connectivity context before deciding which location needs an on-site check.
This illustrative site has a tank and pump stations in separate locations. Wired devices may use an industrial gateway. LoRaWAN sensors need a compatible gateway, network server and payload decoder before data reaches the agreed application.
Problems and practical approaches
Staff travel to each point to check level or pressure
Routine visits take time and may miss events between inspections
Approach · Select suitable sensors and connectivity, group readings by station and retain appropriate physical inspection routines
A value remains visible after the device disconnects
Users may mistake an old reading for the current condition
Approach · Display timestamps and connectivity, distinguishing threshold events from missing data
No one is clearly responsible after an alert
Data exists without an investigation and coordination process
Approach · Assign station owners, recipients and checking procedures, then test them with the actual team
Equipment and components
- Level, pressure or flow sensors selected for the task
- A wired gateway or LoRaWAN system suited to the sensor network
- Site-appropriate power, mounting and uplink equipment
- Cloud station views with scoped history and notifications
Data to monitor
- Level, pressure, flow or other values exposed by the equipment
- The last update time for each point
- Gateway connectivity and data completeness
Data journey
- Sensors / meters
- Wired or LoRaWAN + network server
- Available site uplink
- Cloud stations
- Operator review
Workflow and responsibilities
Survey installation points
Utilities and IT
Identify stations, power, access, antenna positions and connectivity constraints
Connect sensor readings
Installer
Verify interfaces or frequency plans and decode values into correct units
Test continuity
Site team
Check actual readings, disconnection and recovery under an approved site test plan
Review values and time
Station operator
Read values together with update times; do not treat stale values as current evidence
Notify and inspect
Incident owner
Identify the event and coordinate an on-site check; use approved procedures for pump control
Review site maintenance
Utilities manager
Use history to support inspection planning and record network or equipment issues
How each factory team benefits
Utilities
Prioritize checks using missing-data and measurement context by station
Maintenance
Prepare site visits with relevant readings and timestamps
IT and networking
Separate sensor acquisition issues from uplink or access problems
Multi-site operators
Coordinate using consistent station names and ownership rather than verbal descriptions alone
Who this is suitable for
- Factories with distributed tanks, pumps or utility systems
- Sites where suitable power and a data uplink can be provided
- Teams with assigned recipients and inspection capacity, without replacing safety controls with cloud monitoring
Acceptance checks
- Readings and units match the actual measurement point
- Operators can distinguish stale values during disconnection
- Alert recipients can identify the station and follow the agreed check procedure
DETAILS & PLANNING
Turn readings into shared operational information
Organize data before building dashboards
Align sites, areas and assets with operational responsibilities. Use consistent point names and engineering units so that teams can interpret charts from different machines without relearning the naming scheme. Review the structure before importing a large number of measurements.
- Separate sites according to operations and subscriptions
- Group assets by machine or circuit
- Check units, timestamps and data sources
Design alerts around a response owner
Every threshold should have an operational reason, a responsible recipient and a verification procedure. A value exceeding its limit is different from a disconnected device. Consider sampling intervals and network behavior when defining conditions to reduce unnecessary notifications.
- Identify the monitored point and relevant limits
- Distinguish measurement conditions from connectivity loss
- Test notification channels and recipient access
Systems related to this page
Review each system’s scope before opening it or using the example to plan your project.
Organization platform · Sign-in required
AIoT TH Cloud
Sign in to manage organization sites, devices, data points and packages. Confirm access rights and feature availability before operational use.
Demonstration with simulated data
Demo Center
Explore energy, machine monitoring and OEE examples with a 3D factory to understand data and workflows before planning a project.
Questions about this topic
Can the software send control commands?
Phase 1 focuses on reading and monitoring data. Control commands need additional design and scope; a dashboard should not replace site safety controls.
Must every site use the same package?
No. Each site selects a package for its gateway count, points and features. One site’s entitlements do not automatically extend to data from every other site.
Choose hardware and software that work together
Start with your equipment and data points, then define the right site scope.