Selecting a temperature and humidity monitoring system for a factory or warehouse in Thailand is not a matter of comparing sensor prices or dashboard screenshots. A defensible system starts with mapping, uses the results to justify permanent monitoring points, defines what people do when an abnormal condition appears, retains evidence through network and sensor failures, and proves acceptance through FAT and SAT. This guide gives procurement, quality, engineering, IT/OT and operations teams a shared method for writing an RFP and moving from a 30-day proof of concept to controlled operation. It uses public WHO, European Commission and NIST material as international references; it is not pharmaceutical legal advice. Each project must derive its requirements from product and process risk, customer contracts, internal policy and the laws or standards that actually apply.
A monitoring system is not merely a sensor installation
The purpose of automated environmental records is not to produce an attractive trend chart. It is to maintain trustworthy evidence that supports product disposition, process stability, maintenance decisions, working conditions or customer audits. The system boundary therefore extends from the sensing element to alarms, clocks, user access, audit trails, backup and recovery.
Thailand is generally hot and humid, with regional and seasonal variation. Thai Meteorological Department information helps teams understand the outdoor context, but outdoor climatological values are not indoor setpoints. TMD reported that July 2026 was influenced by the southwest monsoon, with nationwide rainfall 8% above normal and mean temperature 0.2°C above normal. That can explain why moisture and heat deserve attention; it does not determine an alarm limit, a sensor count or an indoor design condition. Indoor requirements depend on the stored material or process, HVAC capacity, door opening, building envelope, racking and operating pattern.
Separate six activities before the project starts
| Activity | Purpose | Main evidence | When it occurs |
|---|---|---|---|
| Temperature/humidity mapping | Understand spatial variation, hot spots and operating or seasonal influence | Protocol, position map, three-dimensional trends, monitoring-point rationale | Before deployment, after relevant layout/HVAC changes, and when risk calls for reassessment |
| Commissioning/qualification | Confirm installation, configuration and intended function | Installation record, configuration list, tests, deviations and corrective actions | Initial deployment and after significant change |
| Calibration/verification | Establish that measurements provide the required confidence | Certificate, traceability, pass/fail and adjustment record | On a risk- and requirement-based plan |
| Alarm testing | Verify the path from detection through notification and response | Test cases, delivery logs, acknowledgements and escalation evidence | At acceptance, after change and during planned testing |
| Routine monitoring | Record operating conditions and manage excursions | Trends, alarms, review records and incidents | Continuously during operation |
| Continual improvement | Respond to nuisance alarms, gaps, failures and process change | KPIs, change control, remapping decisions and improvement backlog | At the cadence defined by the operating model |
WHO Technical Supplement 6 addresses selection, installation and initial commissioning of fixed-location temperature and humidity monitoring systems. The practical message is clear: purchasing data loggers does not complete a project. The organization must be able to explain what it monitors, why those points matter and which decision each record supports.
Use mapping to select routine monitoring points
WHO describes temperature mapping as recording temperatures across a three-dimensional storage space and considers it integral to storage monitoring. Permanent sensor locations should therefore not be chosen first. A location selected only because it is near power, easy to cable or has a strong radio signal may miss the actual risk location.
What a mapping protocol should capture
- Dimensions, height, racks, stored loads, floor, walls, roof and heat sources
- HVAC units, supply and return air, dehumidifiers, refrigeration, fans and control points
- Loading doors, shutters, emergency exits, anterooms and frequently opened doors
- Operating hours, cleaning, loading activity, shutdowns, full and low-load representative states
- Solar-exposed walls or roof, adjacent rooms, machine heat and potential condensation locations
- Logger identity, calibration status, position, height and start/end time
- A method for noting missing data, moved instruments, door opening and other events
- The planned analysis and decision rule for selecting permanent points
How representative conditions and seasonal variation are addressed should follow the risk of the application. European Commission GDP guidance discusses mapping under representative conditions, considering seasonal variation, and positioning monitors according to the outcome. This is useful as an international reference, but it is not automatically Thai law for every factory. Applicability must be confirmed against the relevant local obligations and customer contract.

Turn a map into a decision path
The deliverable is more than a color plot. Convert the study into routine control through this sequence:
- Relate spatial and time variation to door opening, HVAC cycles and recorded events.
- Identify representative and worst-case candidates against the product or process risk.
- Check service access and exposure to water, impact, forklift traffic or accidental movement.
- Approve the permanent locations and rationale, then register them in drawings and the asset list.
- Approve alarm limits, delays, hysteresis and recipients separately, using process risk and response procedures.
- Add change control that determines whether a future layout, HVAC, product or operating change requires remapping.
There is no universal sensor count, mounting height or sampling interval. These depend on spatial complexity, rate of change, product risk, instrument performance and contractual evidence needs. An RFP should not merely ask a vendor for a fixed number. It should ask the vendor to state the survey, assumptions and engineering rationale that justify the proposed count and position.
Select the sensor data collection architecture by failure behavior
Temperature and humidity monitoring can use stand-alone loggers, wireless gateways, PLC/SCADA integration, a cloud service or a hybrid. Compare them by whether the required evidence survives realistic failures, not by architecture name.
| Architecture | Good fit | Weakness to investigate | RFP question |
|---|---|---|---|
| Stand-alone logger | Small areas, temporary studies, sites without networking | Manual collection, missed downloads, limited real-time alerts | Capacity, clock control, export, tamper resistance and battery state |
| Sensors plus local gateway | Continuous multi-point monitoring that must survive WAN loss | Gateway single point of failure and radio dead zones | Offline storage, retransmission, deduplication, redundancy and power-loss behavior |
| PLC/SCADA integration | Correlating environmental and machine operation | Ownership boundary between quality records and control data | Tag definitions, historian, change rights, control impact and support ownership |
| Cloud-centric | Rapid multi-site visibility, notifications and analysis | WAN dependency and exit risk | Data location, export, outage behavior, authorization and backup |
| Hybrid | Local continuity plus enterprise visibility | Greater configuration and support complexity | Authoritative record, sync conflicts, diagnosis and restore testing |
Specify offline buffering, not a vague promise
“It keeps working when the network is down” is not a specification. The data-flow diagram should show whether the sensor, gateway, local server or cloud retains data and in what state. Required capacity is not universal; calculate it from credible outage duration, sample cadence, point count and maintenance response. During PoC and SAT, disconnect the relevant link safely and verify that the original measurement timestamp is preserved, retransmission occurs, duplicates are removed, order is reconstructed and any true gap is visible.
The full-buffer condition also needs a defined behavior. Does the device overwrite the oldest readings, stop recording new ones, or notify an administrator? The appropriate behavior depends on risk, but leaving it undefined makes the offline claim meaningless.
Time synchronization and time zones
Correct values with incorrect time cannot be correlated with a door opening, an HVAC stop or product movement. The RFP should define the time source, loss-of-sync detection, restart behavior, local time display, UTC storage and data-exchange rules. Even when operators see Bangkok time, exchanged records should retain time-zone context for comparison with regional or head-office systems. If an administrator can change time manually, the audit trail should capture who changed it, when and why.
Sensor failure and data-quality flags
Open circuits, low battery, out-of-range measurements, frozen values, rapid drift and weak communications are measurement-system faults, not environmental excursions. A dashboard should distinguish them so operators do not take the wrong action. The procedure for a failed sensor should cover alternate measurement, replacement, assessment of the gap, impact evaluation and annotation. A replacement should have its own asset identity while preserving the relationship to the retired device.
Design abnormal notification for resolution, not delivery
An abnormal notification system creates value only when the right person verifies the condition, assesses product or process impact, takes action and leaves evidence. There is no universal alarm limit, delay, hysteresis or escalation time. Each must be approved from product/process risk, rate of change, response capability and contractual needs.
The complete alarm lifecycle
| Stage | Evidence the system should retain | Operating question |
|---|---|---|
| Detect | Reading, timestamp, sensor ID and rule version | Is it an environmental event or instrument fault? |
| Notify | Recipient, channel and delivery status | Can a failed delivery be detected? |
| Acknowledge | Person, time and comment | Did acknowledgement lead to action? |
| Respond | Site check, product hold or equipment action | Was the approved procedure followed? |
| Escalate | Transfer to management or quality | Does the route work at night and on holidays? |
| Close | Cause, impact, action and approver | Can an auditor reconstruct the decision? |
An alarm test should not stop after temporarily changing a limit and seeing a red screen. Use a safe simulated input or test function and exercise detection, delivery, acknowledgement, escalation and closure. If SMS, email and an app are used, test the failure and fallback behavior of each. Test messages must be clearly separated from real alarms.
Long delays or wide hysteresis do not automatically solve nuisance alarms. They can hide short but important excursions. Conversely, treating every door-opening transient as critical creates alarm fatigue. Mapping, process knowledge and historical data should be used to balance detection performance against an operationally credible response.
RFP checklist for factory data loggers and monitoring
An RFP should become the foundation of the acceptance protocol, not just a device specification. Require vendors to mark each requirement as standard, configurable, custom, excluded or dependent on an assumption rather than answering only “compliant.”
Business and quality requirements
- Area, product/process, monitoring purpose and decisions supported by the data
- Mapping scope and the accountable approver of permanent monitoring points
- Required variables, range, accuracy or uncertainty and the rationale for each
- Sampling cadence, retention, review frequency and report format with requirement sources
- Alarm rules, response procedure and night/holiday escalation
- Calibration/verification method, certificates, reference traceability and expiry behavior
- Audit trail, electronic approval, correction comments and export
- Languages, time zones, units and cross-site reporting
Do not outsource accuracy, sampling, retention or calibration cadence to a vendor default. A vendor default is an available implementation option, not the rationale for your requirement. The owner must derive and approve each value from risk and obligations.
Technical and infrastructure requirements
- Communication methods and responsibility boundaries among sensors, gateway, server and cloud
- Radio site survey, interference and attenuation from walls, racks and stored material
- Power, UPS, battery assumptions, low-battery alerts and replacement procedure
- Offline capacity calculation, retransmission, deduplication and gap indication
- Time synchronization, failed time source and audited manual changes
- API, CSV/PDF export, and MES/WMS/SCADA/BI interfaces
- Backup scope, generations, encryption, restoration process and restore testing
- Development, validation and production environments, configuration migration and rollback
- Service access, remote support, spares and service-window definitions
When factory Wi-Fi is part of the design, do not decide from access-point count alone. Evaluate device density, interference, roaming, VLANs and continuity through power events. The Thailand factory wireless LAN design guide explains the infrastructure issues. For a cost model that includes gateways, wiring, cloud use and maintenance, see factory IoT implementation costs in Thailand.
Required vendor deliverables
State the deliverables explicitly: requirements matrix, system and network architecture, data flow, sensor placement drawing, asset register, configuration baseline, user-role matrix, backup and incident procedures, calibration certificates, FAT/SAT results, training material, editable configuration backup, licenses, known limitations and support contacts. Specify editable source formats as well as final PDFs.
Treat environmental monitoring as OT cybersecurity scope
NIST SP 800-82 Rev. 3 includes systems that monitor the physical environment within OT and emphasizes security that respects performance, reliability and safety. Even if a monitoring platform does not issue control commands, its data can affect product disposition and shipment decisions. It should not be treated as an ungoverned convenience IoT device.
Minimum security design questions
- Segmentation: Keep sensors and gateways away from guest Wi-Fi and general user-device networks; allow only required flows.
- Identity and roles: Avoid shared administrator accounts and separate viewing, configuration, acknowledgement and approval rights.
- Credential lifecycle: Change defaults, protect secrets and remove access after personnel changes.
- Update management: Assess firmware/software updates, test effects, plan rollback and track end of support.
- Logging: Record login, configuration and clock changes, calibration metadata changes, deletion and export.
- Backup and recovery: Protect settings and data and demonstrate restoration, not just backup creation.
- Remote maintenance: Use approval, time limits, strong identity and activity logs rather than permanent open access.
- Incident response: Define how to isolate a suspected compromise while maintaining alternate monitoring and impact assessment.
Cloud-service discontinuation and contract change are availability risks too. Confirm how all records and audit trails can be returned, whether they remain readable without a proprietary viewer and whether vendor-managed encryption obstructs exit.
A 30-day PoC that reduces uncertainty
A PoC is not a dashboard beauty contest. It should reduce the largest uncertainties before rollout. The following 30-day structure is an example; stage duration and acceptance values must be adapted to the site.

| Stage | Main work | Exit condition |
|---|---|---|
| Day 1–5: DEFINE | Confirm area, decision purpose, risks, owners, existing instruments and network | Approved PoC requirements, test cases and success criteria |
| Day 6–10: MAP | Review a focused mapping study or existing mapping and choose PoC points | Documented position rationale and constraints |
| Day 11–20: RUN | Exercise routine operation, door activity, link loss, restart, alarms and user actions | Evidence sufficient to assess completeness, delivery and operating burden |
| Day 21–25: CHALLENGE | Safely simulate near-full buffers, disconnected sensors, time-sync loss and recovery | Fault detection, recovery result and gaps are clear |
| Day 26–30: DECIDE | Review evidence, gaps, cost and rollout design | Approved go, conditional go, redesign or stop decision |
Example PoC test cases
- Each sensor can be installed at the mapped point and its asset ID matches the drawing.
- During a network outage, readings retain the original measurement time and synchronize without unjustified gaps or duplicates.
- Sensor disconnection, low battery and potential frozen values are distinguished from environmental alarms.
- Loss of the time source is detected and history remains traceable after recovery.
- Unauthorized users cannot modify alarm logic, users or records.
- An audit trail contains the old and new configuration, actor, time and reason.
- Notification failure is detected and a fallback route or escalation works.
- Dashboard, CSV and PDF outputs agree for the same sensor and time window.
- Representative data and settings are restored from backup and are usable.
- Trained operators can acknowledge, comment and close events according to the procedure.
Acceptance values must be set before testing. Do not copy a temperature threshold, humidity threshold, accuracy, sampling interval or retention period from this article. Approve your values from material specifications, process risk, mapping, contracts and applicable standards.
Build an evidence stack through FAT and SAT
FAT verifies design and major functions in the vendor environment. SAT verifies installation, communication, interfaces and operation in the real factory or warehouse. A system that passes FAT can still fail at site because of walls, racks, radio interference, firewalls, power and user practices. The protocols should cover different risks rather than repeat the same demonstration.

| Acceptance area | FAT evidence | SAT evidence | Record to retain |
|---|---|---|---|
| Requirements traceability | Requirement IDs linked to functions and tests | No unverified requirement in site configuration | Matrix, test number and approvals |
| Sensors/assets | Model, ID, configuration and simulated input | Physical position, tag, calibration state and protection | Register, photos, map and certificates |
| Data collection | Recording, calculations, gap display and time | Real network, outage and retransmission | Raw data, logs and before/after comparison |
| Alarms | Rules, delivery, acknowledgement and audit trail | Real recipients, shifts and site action | Delivery log, response record and deviations |
| Access/audit | Roles, prohibited operations and setting history | Site identities, approvers and leaver process | Role matrix, audit logs and screen evidence |
| Interfaces | API/file transfer and error handling | Live MES/WMS/SCADA/BI connection | Interface logs and reconciliation |
| Backup | Backup generation and encryption | Site procedure, restore and owner execution | Restore result, elapsed effort and approval |
| Operations | Manuals and maintenance functions | Training, out-of-hours contact, spares and SOP | Attendance, competency and handover list |
Every test should state prerequisites, inputs, steps, expected result, actual result, evidence file, executor, reviewer, date and deviation number. Combine screenshots with exported data, system logs, delivery records and site photos so a reviewer can reproduce the conclusion.
If a deviation occurs, do not close it verbally as an “operational workaround.” Record impact, interim control, permanent action, retest, due date and owner. For conditional acceptance, the approver must understand whether an open item affects product disposition, alarm response or quality records.
Integrate calibration, maintenance and change control
There is no universal calibration interval. Set it from sensor stability, environment, manufacturer information, history, required confidence and consequence of failure. The system should show approaching due dates, overdue instruments and failed calibration status appropriately.
When calibration fails, neither automatically invalidate all data since the last successful calibration nor assume no impact. Assess drift direction and magnitude, environmental history, comparison with adjacent or reference sensors, process margin and possible affected period. Retain enough evidence for the accountable quality decision.
Change control should cover relocation, alarm logic, sampling cadence, user roles, firmware, network, HVAC, racks, product and operating hours. For each change, decide whether recalibration, partial retesting, remapping or training updates are needed.
Operational KPIs
Measure the health of the monitoring system itself: data gaps, unacknowledged alarms, nuisance alarms, sensor failures, time-sync failures, backup failures, overdue calibration, open deviations and recovery time. Targets must come from site risk and service expectations. Controls should prevent teams from improving a KPI by weakening alarms or hiding missing data.
Use RACI to close ownership gaps
Environmental monitoring crosses quality, engineering, IT/OT, production, warehouse, procurement and vendors. Broad participation often creates unclear final accountability.
| Activity | Quality | Engineering | IT/OT | Operations/Warehouse | Procurement | Vendor |
|---|---|---|---|---|---|---|
| Approve monitoring purpose and product risk | A/R | C | C | C | I | I |
| Plan and perform mapping | A | R | C | R | I | C |
| Design network, time and identity | C | C | A/R | I | I | C/R |
| Approve alarm logic and response | A | C | C | R | I | C |
| RFP and contract | C | C | C | C | A/R | I |
| Execute FAT/SAT | A | R | R | R | I | R |
| Calibration and maintenance | A | R | C | C | I | R |
| Deviation and impact assessment | A/R | C | C | R | I | C |
| Backup and recovery | C | C | A/R | I | I | C |
A means accountable, R responsible, C consulted and I informed. Adapt this example to actual authority. In particular, do not confuse the person who acknowledges an alarm with the person authorized to assess product impact.
Compare TCO and benefits for automated records
A bid comparison should include more than sensor price: mapping, engineering, installation, network, server or cloud, integration, qualification, training, calibration, maintenance, batteries and spares, cybersecurity, data migration and contract exit.
Use a parameterized model:
TCO = initial equipment, design, installation and verification + licenses, communication, support, calibration and operating labor over the evaluation period + upgrade, migration and disposal
Benefit = reduced manual recording + probability-weighted loss avoided through earlier detection + audit preparation saved + data-driven maintenance improvement
The following is an illustrative calculation only, not a statement of Thai market price or a guarantee. Suppose initial cost is THB 1,800,000 and annual operating cost is THB 240,000 over three years. TCO is THB 2,520,000. If assumed annual avoided loss is THB 750,000 and saved labor is THB 180,000, three-year benefit is THB 2,790,000. Net benefit is THB 270,000 and benefit/TCO is approximately 1.11.
| Illustrative item | Calculation | Result |
|---|---|---|
| Three-year TCO | 1,800,000 + 240,000 × 3 | THB 2,520,000 |
| Three-year benefit | (750,000 + 180,000) × 3 | THB 2,790,000 |
| Net benefit | 2,790,000 − 2,520,000 | THB 270,000 |
| Benefit/TCO | 2,790,000 ÷ 2,520,000 | About 1.11 |
For a real project, replace loss probability, scrap value, downtime and labor with site history. Separate certain benefits from probability-weighted benefits and compare conservative, base and optimistic scenarios. Include less easily quantified value such as faster root-cause analysis and customer-audit readiness without pretending it is guaranteed cash.
Common implementation failures
Selecting sensor positions for convenient wiring
Use mapping and risk first; adapt cabling or wireless design afterward. When installation constraints force a move, document whether the new location represents the same risk.
Testing only the cloud dashboard
Production problems involve network loss, batteries, clock drift, access and recovery. Create safe abnormal cases during PoC and verify the evidence.
Treating delivery as completed alarm response
Staff changes, holidays, failed channels and acknowledgement without action create gaps. Design the alarm lifecycle and RACI together.
Accepting vendor defaults as requirement rationale
Default retention and calibration settings show what a product can do; they do not explain what your operation needs. Approve requirements from risk, contracts, audit needs and history.
Skipping site testing after FAT
The real network, racks, walls, power, recipients and users are different from the vendor environment. SAT must challenge the installed configuration and operating procedure.
Leaving the authoritative record and exit path undefined
State whether the gateway, cloud or another repository is authoritative, how corrections and retransmission are handled, and what data is returned when the contract ends.
Conclusion: select for evidence, not just sensor count
A temperature and humidity monitoring system should begin with the asset, process or product being protected and the decision the record supports. Mapping justifies permanent points; commissioning, calibration, alarm testing and routine monitoring remain distinct activities. A 30-day PoC and FAT/SAT should challenge communication loss, clock problems, sensor failure and recovery. No universal alarm limit, sampling interval, retention period or calibration interval fits every operation. Each value needs approval based on product/process risk, mapping, contracts and applicable requirements. With RACI and audit evidence built in, automated temperature and humidity recording becomes a reliable decision system rather than a dashboard project.
TOMAS TECH can support early-stage discussions for mapping plans, RFP structure, PoC scope and integration with an existing factory network in Thailand. If you want to define site conditions and operating ownership before selecting products, use the TOMAS TECH contact form.
Frequently asked questions
What is a temperature and humidity monitoring system?
It measures temperature and relative humidity, collects readings with time information, stores them and supports display, alarms, reports and audit evidence. A stand-alone logger may be enough for some uses; multi-site visibility, real-time notification, role control or interfaces may require gateways, servers or cloud services.
How many temperature and humidity sensors are required?
There is no universal count. Use mapping that considers height, racks, HVAC, doors, heat sources, operating conditions and product risk. Ask a vendor to justify the proposed number and position rather than applying a generic density.
What sampling interval and retention period should be used?
Set them from the rate of change, consequence of an excursion, event types to detect, storage capacity, contract and audit requirements. Verify search, export and restoration as well as raw retention.
Are temperature mapping and routine monitoring the same?
No. Mapping investigates spatial and time variation so permanent points can be chosen. Routine monitoring continuously measures selected points and triggers operating response. Mapping logger positions do not automatically become permanent sensor positions.
Is email enough for abnormal notification?
The crucial issue is not channel count but delivery-failure detection, acknowledgement, action, escalation and closure evidence. Test the route across nights, holidays, personnel changes and communication failures.
Is data lost if the cloud is unavailable?
That depends on the architecture. Sensors or gateways may buffer readings and retransmit them with original timestamps. Specify capacity, full-buffer behavior, deduplication, gap indication and recovery testing.
Must sensors be calibrated every year?
This article does not prescribe a universal interval. Set one from required confidence, environment, sensor stability, manufacturer information, history and failure impact. Define how failed calibration triggers an impact assessment of earlier data.
What is the difference between FAT and SAT?
FAT verifies design and main functions in the vendor environment. SAT verifies the actual sensor positions, network, power, recipients, interfaces and site procedures. Both should link requirement IDs to tests and retained evidence.
Sources
- WHO: Cold chain equipment and dry store temperature mapping tool (22 Jan 2026)
- WHO: Technical Supplement 6 — Temperature and humidity monitoring systems for fixed storage areas
- WHO: Temperature mapping of storage areas
- WHO: How to temperature map cold chain equipment and storage areas, 2nd ed.
- European Commission: Guidelines on Good Distribution Practice of medicinal products for human use
- NIST SP 800-82 Rev. 3: Guide to Operational Technology Security
- Thai Meteorological Department: Relative humidity
- Thai Meteorological Department: Monthly climate summary