Process

How an idea becomes something people can actually use.

01
A picture of a SmartFactory Micro-Monitor sensor research or spec comparison

Research

SmartFactory Micro-Monitor started with a cost problem, not a technical one: enterprise ESG monitoring tools run upwards of €15,000 a year, putting real-time environmental compliance completely out of reach for small manufacturers. Research meant figuring out which six parameters actually matter for compliance — temperature, humidity, air quality, dust, noise, energy draw — and which sensors could measure them accurately for a fraction of that cost. The constraint wasn't "can this be built," it was "can this be built for under €100."

  • Cost constraints
  • Sensor selection
  • Problem framing
02
A picture of the SmartFactory Micro-Monitor system architecture or GPIO wiring plan

Design

Before wiring a single sensor, I designed a five-layer system: hardware, a polling daemon, a database, a threshold engine, and a dashboard — each with one clear job. I mapped out exactly which GPIO pins each sensor would use, and where an analog sensor like the MQ-135 would need an ADS1115 converter sitting between it and the Pi to translate voltage into a number the software could actually read. Getting this on paper first meant far fewer surprises once the breadboard came out.

  • System architecture
  • GPIO planning
  • Hardware/software mapping
03
A picture of the SmartFactory Micro-Monitor hardware or breadboard

Build

On SmartFactory Micro-Monitor, build meant wiring six sensors to a Raspberry Pi, debugging I2C conflicts between the ADS1115 and a UART serial line, then layering a five-part Python backend — polling daemon, SQLite store, threshold engine, Flask API — before touching the dashboard. Same instinct on web projects: get real data flowing through a real API first, so the frontend is never built against a guess.

  • Python / Flask
  • Hardware debugging
  • API-first
04
A picture of a SmartFactory Micro-Monitor sensor testing or debug log screenshot

Test

I tested every sensor individually before integrating it into the full system — a discipline that paid off when the ADS1115 started throwing I2C communication errors (fixed by dropping to direct register access via smbus2) and when the PMS5003's UART line conflicted with the Pi's Bluetooth (fixed by disabling Bluetooth in config.txt). For a device meant to trigger real alerts on a factory floor, I'd rather catch a wiring conflict on the bench than have a sensor silently go quiet in production.

  • Per-sensor validation
  • Hardware debugging
  • Real-world testing