A cloud-enhanced smart speed breaker
My main IoT project is a two-tier pipeline that splits responsibilities between a Raspberry Pi and an Arduino. The Pi handles vision-based vehicle classification, the Arduino Nano drives servo actuation over UART, and MQTT streams telemetry to the cloud for dashboards.
The split matters. Trying to do classification and actuation on the same MCU was a non-starter; trying to do real-time PWM from the Pi was unreliable. Two brains, one bus, one cloud sink — the architecture has held up across every iteration.
What I did not expect is how much the MQTT layer would change the project. The moment every classification, every actuation, and every error showed up on a live dashboard, debugging stopped being guesswork. Edge cases that would have taken weeks to reproduce on a bench got caught in the first demo because I could see exactly what the system saw.
Energy harvesting for IoT nodes
Vibro-Volt is the other half of my IoT story. PVDF piezoelectric elements feed a full-wave rectifier and a BMS, letting low-power IoT nodes scavenge energy from ambient vibration. The dream — and the next step — is a sensor node on a bridge or a piece of machinery that never needs a battery swap.
The energy budget changes how you write firmware. You stop polling. You sleep aggressively. You design your communication windows around when the harvester actually has charge to spare. It is a fun discipline because it punishes laziness — every wasted milliamp shows up as downtime.
For a city like Pune with old bridges, busy roads, and factories everywhere, that kind of self-powered sensing is genuinely useful. Not glamorous. Just useful. Which is usually a good sign.
Protocols and hardware
ESP32, Arduino, Raspberry Pi 4. MQTT for telemetry, UART/I²C/SPI between boards, GPIO and PWM for actuation. This is the everyday toolkit for IoT in Pune, and the projects on this site are built almost entirely with it.
I keep the protocol picks boring on purpose. MQTT instead of a custom WebSocket layer. UART instead of a homemade serial scheme. JSON payloads with a stable schema instead of bit-packed structs I will forget in three months. Future me has bailed present me out enough times that I have stopped trying to be clever about wire formats.
What I have learned about IoT
IoT projects fail at the seams, not at the parts. The model works, the cloud works, the actuator works — and then the UART drops a byte at 3 a.m. and nobody knows. The investment that pays off the most is observability: logs, telemetry, and the ability to watch the system live during a demo so you catch the seams before they catch you.
The second thing I have learned is that 'cloud-connected' is not free. Every new MQTT topic is a contract you have to maintain. Every retained message is a future surprise. I now design the topic tree before I write the firmware, and I treat it like an API, because that is what it is.
If you are starting out in IoT, build one small project end-to-end before you build anything fancy. Sensor → MCU → broker → dashboard, all glued together with the boring tools. Once that loop feels routine, everything else is just bigger versions of it.