Alexander P.

Senior IoT Engineer building complete IoT systems: the firmware on the device, the cloud that receives its data, and the tools to run a fleet of them in production. RECENT WORK For several years I've owned the platform behind a fleet of EV energy-management controllers - ARM Linux devices that measure a site's electrical load and allocate current between chargers in real time. Real-time sampling runs as bare-metal firmware on the SoC's real-time core and feeds a multi-threaded C++ application through shared memory. Around it: U-Boot boot flow, device-tree overlays, GPIO/I2C/SPI peripherals, Modbus and OCPP to third-party equipment. An A/B update system that cannot brick a device: two system slots plus a persistent data partition, signed bundles, a bootloader-side attempt counter that falls back before Linux starts, and a health check that confirms a new image or rolls it back by itself. Proven on hardware, including power cuts mid-update. A fleet-wide Debian migration done remotely: repartitioning live devices in place, carrying each unit's identity (certificates, VPN keys, calibration) across, and keeping a working fallback until the new system proved itself. No site visits. Cloud side: MQTT telemetry and commands to AWS IoT, Lambda processing into the fleet database, per-device certificate provisioning, WireGuard access to devices behind customer NAT. WHAT I DO Embedded: C/C++ firmware; embedded Linux (Debian and Yocto - own layers, recipes, images); U-Boot, device tree, kernel configuration, board bring-up; drivers and hardware integration; Modbus, TCP/IP, UART, SPI, I2C; performance work and hard-to-reproduce bugs. Updates: A/B images with automatic rollback; signed bundles and key rotation; staged fleet rollouts; application updates from a private, certificate-protected package repository. AWS: IoT Core and MQTT architecture; Lambda services; cloud databases; device provisioning and certificate management; telemetry and remote monitoring; designs that stay cheap as the fleet grows. Python: backend services and APIs; automation and build tooling; data processing; device-management services. Platforms and remote access: fleet-management web apps and real-time dashboards; remote firmware updates; WireGuard VPN and secure SSH tunnelling; diagnostics for devices with no public address. WHY ME Most IoT problems live between the layers - a device reporting the wrong state, an update that works on the bench and fails in the field, a cloud message nobody can trace back to the firmware that sent it. Instead of coordinating separate firmware, cloud and web developers, you get one engineer who follows a problem from the bootloader to the dashboard and designs the pieces to fit. Let's talk about what you are building and find the shortest path to something production-ready.