Case study · Warehouse · Wireless sensors
One big warehouse. Eleven radio nodes read the air.
Temperature and humidity every minute, by radio to the cloud.
In the heat of the day the humidity in a warehouse can be 30 % or lower. At night the same air can reach 70 to 80 %.
So the case measures the whole floor, every minute, day and night.
This case describes a wireless monitoring system installed in a warehouse with OpenMote B radio nodes, a Raspberry Pi gateway and a cloud server. It does not name the owner of the warehouse. The requirements, the hardware, the radio timings and the reported results come from the case. The values in the panels are examples, not data from the warehouse.
The challenge
A warehouse this size cannot be measured from one spot.
Workplaces must keep temperature and relative humidity inside a comfort zone. In this warehouse the bands are 23 to 27 °C in summer and 17 to 24 °C in winter, with 23 °C as the usual value, and 30 to 70 % relative humidity all year, with 50 % as the usual value. The ranges must be watched automatically, with sensors spread over a floor of 450 x 250 m, more than 100,000 m².
Humidity changes at night
In the heat of the day the humidity can be around 30 % or lower. At night it can reach 70 to 80 %. A check by day misses it, so the monitoring runs 24/7.
Measure both together
Relative humidity depends on the air temperature: when the temperature goes up, the relative humidity goes down. It tells how close the air is to saturation, so temperature and humidity are read at the same time.
No cables across the floor
Each node reads temperature and humidity every minute, with a resolution of 0.1 °C and 1 % RH. Nodes must run more than a year on batteries and install in less than 15 minutes.
Know when a node fails
With 11 nodes on a large floor, a silent node must be found quickly. Each node also reports the state of its radio link, so a failure shows which node and what kind of failure.
Why the humidity matters
High humidity helps mould, corrosion and rust grow on stored goods. It causes condensation on walls, ceiling and floor, which creates conditions for pests. It can also bring extra insurance costs from mould and mildew claims by customers.
How it works
Three jobs: send each reading, map the floor, watch the links.
Each panel shows one job. Press the buttons. The panels are illustrative simulations: the timings and the bands are the ones of the case, but the values, the losses and the node numbers are examples, not data from the warehouse.
Wake, measure, send nine frames, sleep.
Every 60 s a node wakes up, reads temperature and humidity and builds one small packet. It sends the packet three times, and each time on three modulations: SUN-FSK, SUN-OQPSK and SUN-OFDM. That is nine frames for one reading. Before each frame the node checks the channel (CSMA-CA with CCA) and tries again up to 3 times if it is busy. The gateway needs only one good frame; the cloud server removes the duplicates. Pick a radio condition and wake the node.
- One reading every 60 s, then sleep
- 3 repetitions x 3 modulations = 9 frames
- 21 bytes, AES-128, a 32-byte PSDU
Node events (example)
Illustrative simulation. Example values, not data from the warehouse. One cycle every few seconds here; every 60 s in the case. The timings are the ones of the case: three repetitions at 100, 650 and 1300 ms, each one on SUN-FSK, SUN-OQPSK and SUN-OFDM, 50 ms apart. The losses are examples.
Eleven points, one band for each season.
Each point is checked against the band of the case, not only the floor average. In the afternoon the air is warm and dry; at night the same floor can reach 70 to 80 % humidity. In this example, the points near the dock doors move first. Pick a time of day, change the season and watch the points.
- Temperature: 23 to 27 °C in summer, 17 to 24 °C in winter
- Relative humidity: 30 to 70 % all year
- Every point read every minute, 24/7
Floor events (example)
Illustrative simulation. Example values, not data from the warehouse. Example values, shown faster than real time. The bands are the ones of the case: 23 to 27 °C in summer, 17 to 24 °C in winter, 30 to 70 % RH all year. The day and night humidity follows the case: about 30 % or lower by day, 70 to 80 % at night. The positions of the points are examples.
The network reports on itself.
With batteries and radio, a node can go quiet without anyone noticing. Each node sends the strength of the signal (RSSI) and the noise on the channel when it transmits (CCA RSSI). Each packet carries a counter that only goes up. A weak link, a silent node and a reset node each leave a different mark. Break something and read the log.
- RSSI and CCA RSSI from every node
- Counter gaps show lost packets
- A counter back at 1 shows a reset
Link events (example)
Illustrative simulation. Example values, not data from the warehouse. One tick is one minute of the case. The RSSI values, the losses and the node numbers are examples. The method is the one of the case: each node sends RSSI and CCA RSSI, and the packet counter of each node only goes up, so a gap means lost packets and a counter back at 1 means a reset.
System architecture
How do you monitor temperature and humidity in a large warehouse without cables?
Eleven battery nodes read temperature and humidity and send them by radio, IEEE 802.15.4g, with three modulations. At the gateway, a Raspberry Pi with three OpenMote B radio boards receives the frames on USB. A Python server on the gateway sends the data with MQTT over an LTE modem to a cloud server on Amazon AWS. There, a second Python server removes the duplicate packets and applies the calibration, InfluxDB stores the data, and Grafana and Node-RED show it.
| Signal | Between | Type | Purpose |
|---|---|---|---|
| Temperature and relative humidity | BetweenBosch BME280 → node | TypeOn the sensor board | PurposeResolution of 0.1 °C and 1 % RH, every minute. The BME280 also reads pressure |
| Light | BetweenTI OPT3001 → node | TypeOn the sensor board | PurposeAvailable on the same sensor board |
| Reading packet | Between11 nodes → gateway | TypeSUN-FSK, SUN-OQPSK, SUN-OFDM | Purpose21 bytes, AES-128, 32-byte PSDU, 3 repetitions x 3 modulations |
| Link state | BetweenNodes → gateway | TypeRSSI, CCA RSSI, CSMA retries | PurposeSignal strength and channel noise, and retries for each modulation |
| Packet counter | BetweenIn every packet | TypeCounter that only goes up | PurposeFinds lost packets and node resets |
| Received frames | Between3 OpenMote B → Raspberry Pi 3B+ | TypeUSB serial | PurposeThe Python gateway server reads the frames |
| Uplink | BetweenGateway → cloud | TypeMQTT over LTE (Huawei E3372) | PurposeEvery packet goes to the cloud server |
| Clean data | BetweenPython server on AWS | TypeMQTT in, database out | PurposeRemoves duplicate packets and applies the calibration |
| Storage and dashboards | BetweenInfluxDB, Grafana, Node-RED | TypeAWS T2.micro, Ubuntu 18.04 | PurposeAggregation, storage and graphs of temperature, humidity, RSSI and CCA RSSI |
Why it works
Small radio packets, sent often enough, checked twice.
One reading, nine chances
Three repetitions on three modulations give nine frames for each reading. Noise on one modulation or a short burst at one moment does not cost the reading. The cloud server keeps one copy.
A node that sleeps
The node is awake only to read the sensors and send. Then it sleeps until the next minute. This is why two AA cells of 1500 mAh are expected to last more than a year.
Polite on the air
Before each frame the node checks the channel (CCA) and waits if it is busy (CSMA-CA), up to 3 times. The CSMA retries and the CSMA RSSI travel in the packet, so you can see a noisy area.
Failures you can name
RSSI shows a weak link. A gap in the counter shows lost packets. A counter back at 1 shows a reset. Each kind of failure points to one node.
Calibrate once, correct in one place
Each sensor got a 1-point calibration to remove its own offset. The cloud server applies it, so the nodes stay simple and a correction changes in one place.
Open tools on every layer
FreeRTOS on the radio boards, Python and MQTT on the gateway, InfluxDB, Grafana and Node-RED in the cloud. See an MQTT bridge in Python on a Raspberry PLC and a central Mosquitto MQTT broker.
From the project
The gateway and the first graphs.
The installation took two phases, two weeks apart: the gateway and 5 nodes first, then 6 more nodes. Each node took about 10 minutes at most to install.
Hardware
The gateway today. The nodes of the case.
GateBerry FLEX
The gateway of the case was a Raspberry Pi 3B+ with three radio boards and an LTE modem on USB. Today this role fits on a GateBerry FLEX: a Raspberry Pi on DIN rail with four USB ports for the radio boards and 4G as an expansion board.
- Role in this design
- Gateway: radio boards on USB, Python server, MQTT to the cloud
- Compute
- Raspberry Pi 4 (Raspberry Pi 5 option), 2 to 16 GB RAM
- Ports
- 1 x Gigabit Ethernet, 2 x USB 2.0, 2 x USB 3.0, RS-485, I2C, Wi-Fi, Bluetooth LE
- Expansion
- One board: 4G (LTE-M/NB-IoT or LTE Cat 4), LoRa, CAN, M-Bus or RS-232
- Software
- Debian 64-bit preinstalled; runs Node-RED, MQTT, Python and Docker
- Power and mounting
- 12 to 24 Vdc, UPS with supercapacitors, RTC, DIN rail TS35, IP20, 0 to 55 °C
The case used a Raspberry Pi 3B+ with Raspbian and a Huawei E3372 USB modem. The GateBerry FLEX is the current Industrial Shields equivalent for the gateway role. It has no local I/O. The radio boards are not part of the GateBerry.
OpenMote B radio board (image from the original case)
Each of the 11 measuring points is an OpenMote B radio board with an OpenMote sensor board and two AA cells. The same radio board, three times, receives the frames at the gateway.
- Radio board
- TI CC2538 and Atmel AT86RF215, FreeRTOS
- Sensor board
- Bosch BME280 (temperature, humidity, pressure), TI OPT3001 (light)
- Power
- 2 x AA, 3 V, 1500 mAh
- Radio
- IEEE 802.15.4g: SUN-FSK, SUN-OQPSK, SUN-OFDM
- Calibration
- 1-point calibration to remove the offset of each device
OpenMote B is no longer in the Industrial Shields catalogue. The pattern still applies: low-power radio nodes, a Linux gateway and MQTT. Tell us your floor and your radio needs and we will propose the nodes.
Questions about this case
What temperature and humidity should a warehouse keep?
In this case: 23 to 27 °C in summer and 17 to 24 °C in winter, with 23 °C as the usual value, and 30 to 70 % relative humidity, with 50 % as the usual value. The limits depend on the country, the work and the goods. For example, in Spain RD 486/1997 sets, for closed workplaces, 17 to 27 °C for sedentary office-type work, 14 to 25 °C for light work and 30 to 70 % relative humidity (50 % minimum where there is a risk of static electricity).
Why monitor warehouse humidity 24/7?
Because the humidity changes a lot between day and night. In this case it can be around 30 % or lower in the heat of the day and reach 70 to 80 % at night. A check by day shows a dry warehouse while mould, corrosion and condensation grow at night. Relative humidity also depends on the temperature, so the two are read together.
How long do battery sensor nodes last?
In this case each node runs on two AA cells (3 V, 1500 mAh) and the target is more than a year. The node sleeps most of the time and wakes every 60 s to read and send. The battery life depends on how often it wakes, how many frames it sends and how many retries a busy channel causes.
How do you know if a wireless sensor stops working?
Each node sends its RSSI and CCA RSSI, and every packet has a counter that only goes up. A low RSSI points to a weak link. A gap in the counter means lost packets. A counter back at 1 means the node reset. No packets for a few minutes means a silent node: a flat battery or a node out of range.
Why send each reading on three modulations?
IEEE 802.15.4g defines three SUN radio modes: FSK, O-QPSK and OFDM. They react in different ways to noise and to the building. In this case each reading goes three times on each of them, so one good frame is enough, and the CSMA retries of each mode show which one has a busier channel in each area. The cost is airtime and energy, which the 60 s sleep keeps low. Small packets help too; see payload bit packing (the example uses LoRaWAN; the idea is the same).
From monitoring to control: what is the next step?
This case measures and reports; it does not describe the fans, heaters or dehumidifiers. A typical next step: a PLC next to the HVAC equipment reads the values from the MQTT broker and switches the equipment with a band and a delay, so it does not start and stop all the time. See how Arduino PLCs control humidity and temperature in a greenhouse and a Node-RED MQTT concentrator.
Monitoring a large floor?
Tell us about your floor and your limits. An engineer will answer.
Tell us the size of the building, the variables and their limits, how many points you want and where the data must go. We will propose the nodes, the radio, the gateway and the software.
- You get an answer from our technical team
- Points, radio and gateway for your building
- Arduino, ESP32 or Raspberry Pi based PLCs and gateways