I Simulated a Complete IoT Factory Sensor System Without Any Hardware — Here Is Exactly How I Did It

You do not always need hardware on your desk to develop and test firmware. Simulators let you build and debug logic, state machines, and communication before you plug in a single wire. This post walks through building a complete IoT factory sensor system — temperature and vibration monitoring with alerts and WiFi transmission — using the Wokwi simulator for ESP32. Zero hardware. I will show the firmware architecture, the sensor reading logic, the alert system, and how WiFi transmission is simulated. Every tool and decision is named so you can reproduce it or use the same approach for your own project. This post is for engineers and CTOs evaluating how to develop IoT firmware and for hardware founders who want to see that real systems are built with real engineering discipline.

• •A factory monitoring node that:
• •Reads "temperature" and "vibration" from simulated sensors.
• •Compares them to thresholds and triggers an alert when exceeded.
• •Sends readings and alerts to a simulated backend (or a real one if you point it there) over WiFi.
• •Runs in a loop with configurable interval, so we can test timing and state.

In Wokwi, the ESP32 is simulated; we can attach simulated sensors (e.g. a temperature sensor component) or emulate sensor values in code for speed. The focus here is firmware structure and logic — the same structure runs on real hardware with real sensors.

• •Main loop (or RTOS tasks): One task/loop for sensor read, one for threshold check and alert, one for network (or a simple state machine in a single loop if we keep it minimal).
• •Sensor layer: Functions that "read" temperature and vibration. In simulation they return values from Wokwi components or from test vectors; on hardware they read ADC or I2C/SPI sensors.
• •Alert logic: Compare readings to configurable thresholds. If exceeded, set a flag or push to an alert queue. In a full system we would blink an LED or send to cloud; in sim we log or send a message.
• •Network layer: Connect to WiFi (in Wokwi, WiFi is simulated), then send HTTP or MQTT to a server. For sim we can use a mock server or a real cloud endpoint.

We define a structure for a reading (timestamp, temperature, vibration, unit). The "sensor" read function in sim returns values we inject (e.g. ramp temperature up to test threshold). On real hardware we would read ADC, apply calibration, and convert to physical units. The important part is that the rest of the firmware (threshold check, network) only sees "a reading" — so we can swap sim for real without changing the upper layers.

If temperature > T_max or vibration > V_max, we set an alert state and optionally send an alert payload. We might also implement a debounce (e.g. alert only if threshold exceeded for N consecutive samples) to avoid noise. In the post I would show a minimal version: one threshold check per reading, immediate alert.

In Wokwi, ESP32 WiFi is simulated. We can call the same WiFi and HTTP/MQTT code we would use on device. The simulator can connect to the internet, so we can actually hit a real server or a test endpoint. We send a JSON payload: timestamp, temperature, vibration, alert flag. On the server side we could use a simple Flask or Node server, or a cloud IoT service.

• •Doing this in simulation shows that:
• •We separate layers (sensor, logic, network) so that testing and porting are straightforward.
• •We can run the same logic with simulated or real sensors.
• •We think about state, timing, and failure (e.g. what if WiFi is down?) from the start.

That is how we build production firmware at Hendoi — with clear architecture and testability. If you have a real hardware challenge (factory sensors, industrial IoT, or any embedded product), we can take this discipline and apply it to your design. Contact us for a free technical review.