A1SI Engineering Services · Embedded + Mobile
A1SI builds both halves of every connected product — the C / C++ / Rust firmware running on the MCU or SoC and the React Native / Expo iOS + Android app the operator opens to talk to it. Same engineering team on both sides means the GATT spec on the firmware matches the BLE client on the app, the protocol the device speaks matches the parser the dashboard ships, and the bring-up debugging session works because we wrote both halves. Recent work in production includes the CVWS commercial-vehicle weighing app (in closed testing on TestFlight / Google Play), the EMDT emergency-medical-device tracker (in closed testing), and the A1SI Lutron HomeWorks Controller firmware that drops into installed Lutron lighting systems as a direct replacement for the original processor.
Capabilities
Connected products fall apart at the seam between firmware and app — the GATT spec drifts, the protocol parser disagrees with the device, the bring-up engineer and the app engineer hand each other defects all week. A1SI runs both disciplines under one team so the seam stays tight from architecture through production.
Bare-metal and RTOS firmware for Cortex-M and RISC-V targets. Signed over-the-air update partitions, factory-provisioning workflows, watchdog and brown-out recovery, RTC-aware power management. C and C++17 for the established stack; Rust for new builds that need memory-safety guarantees on the device side.
Zephyr 3.x on Nordic and STM32 targets, FreeRTOS on classic Cortex-M, Espressif ESP-IDF v5 on ESP32 / S2 / S3 / C3 / C6. Task partitioning, ISR discipline, priority-inversion protection, RTOS-aware GDB / OpenOCD bring-up, code-size and stack-watermark profiling on the device.
Swift / SwiftUI for cases where native iOS depth is required (BLE central with custom peripherals, CoreBluetooth background modes, Vision / CoreML on-device inference); React Native + Expo SDK 54 for the cross-platform path the CVWS and EMDT apps ship on. TestFlight pipelines, App Store privacy nutrition labels, app review escalation.
Kotlin + Jetpack Compose for native Android depth (foreground-service BLE peripherals, USB-host accessory protocol, MediaProjection capture). React Native + Expo cross-platform path with EAS Build pipelines. Play Console internal-testing tracks, Data Safety form, policy-compliance review handling.
BLE GATT (custom characteristics + Nordic UART Service), Web Bluetooth API for browser-side control surfaces, MQTT 3.1.1 / 5.0 over TLS for cloud-to-device telemetry, Modbus RTU and TCP for industrial integrations, WebSerial for in-browser hardware bring-up. Protocol contract documented as the joint deliverable between the firmware and the app teams.
Operator-readable maintenance surfaces (the engineering posture from our production-floor controllers — savable diagnostic transcripts, live Tx / Rx counters, one-window error reporting), Dynamic Type and accessibility-first layouts for field operators in gloves, WCAG-aware color and focus contracts, dark-mode parity, and offline-first data models for crews working outside cell coverage.
How we engage
We organize every connected-product program around a five-step flow that keeps the firmware team and the app team aligned across the same artifacts — the protocol contract at step 3 is the gate the whole project hinges on.
Embedded and mobile architectures designed together: data model on the device, command set, BLE / cloud transport, security model, OTA strategy. The artifact: a single architecture doc the firmware and app teams both build against.
Firmware skeleton (RTOS, OTA partitions, GATT server, watchdogs) and app skeleton (navigation, BLE / MQTT client, auth, state store) brought up in parallel against stub interfaces. The artifact: both halves compile, run, and exchange canned messages over the wire.
The joint deliverable: a written contract for every wire format the firmware and the app exchange — GATT services, MQTT topics, JSON schemas, byte-level frame layouts. Versioned, regression-tested, and kept in one place. The artifact: a contract doc that survives every refactor on either side.
First-article firmware on real hardware against the app on real phones. End-to-end protocol exchange, battery and thermal profiling on the device, BLE link quality on the app side, observability wiring (Sentry for the app, NVS / coredump for the firmware). The artifact: the full system exchanging real payload under realistic load.
TestFlight + Play Internal Testing tracks, App Store / Play Console privacy and policy compliance, factory provisioning of the production firmware, OTA channel setup, ongoing post-launch support. The artifact: an app live in both stores and firmware that ships with the device.
The bench
We pick the right tool for each half of the stack — the embedded toolchain lives in CMake / Ninja / OpenOCD / GDB, the mobile toolchain lives in Xcode / Android Studio / Metro / EAS — and a small set of cross-cutting tools (Sentry, GitHub Actions, Doppler) holds the two together.
Recent work
Three programs A1SI is shipping right now — two cross-platform iOS + Android apps built on React Native + Expo SDK 54, and one ESP32 firmware that drops into an installed Lutron HomeWorks lighting system.
iOS + Android · React Native + Expo SDK 54 · BLE → Modbus RTU
A1SI's real-time vehicle-weighing app for commercial fleets. The app pairs with a Laumas CLM8 load-cell transmitter over BLE, parses the CLM8's native Modbus RTU register map on-device with CRC-16 validation, captures all eight load-cell channels every weighing session, and dual-writes each timestamped record to local storage and the multi-tenant CVWS cloud. In closed testing on TestFlight and the Google Play test track; the same React Native codebase under Expo SDK 54 runs on both platforms.
iOS + Android · Expo SDK 54 · QR + photo capture · 21 CFR Part 11
A1SI's emergency-medical-device tracker for EMS agencies, fire departments, and clinical engineering teams. Field crews scan a QR code, attach a photo, and the device's full compliance history — last PM date, battery state, recall posture, MDR / CAPA workflow — is in their hand. The React Native + Expo app talks to 88 Django REST endpoints across 8 compliance apps; in closed testing on TestFlight and the Google Play test track. ALCOA+ audit trail and FDA 21 CFR Part 11 e-signatures on the back-end.
ESP32 · ESP-IDF v5+ · StarBus RS-485 · Vareo · local REST API
A1SI's ESP32-based firmware that drops into an installed Lutron HomeWorks Interactive lighting system as a direct replacement for the original Lutron processor. Speaks both native bus protocols — StarBus RS-485 at 9 600 8N1 and Vareo 15 V 120 Hz — so every existing keypad, dimmer, and sensor in the installation keeps working untouched. Adds a modern local REST API on port 80 (Matter support in active development) so a HomeWorks installation joins Home Assistant, openHAB, Node-RED, or any Matter controller. No cloud lock-in, no original-processor remanufacture.
What we deliver
Every program closes with the embedded artifacts (signed firmware, OTA channel, BoM-locked release tag) AND the mobile artifacts (signed app in both stores, observability dashboards, post-launch support runbook) — handed off as one coherent release, not two independent drops.
Why A1SI
The seam between firmware and app is where connected products fail. A1SI runs both sides of every program under one team so the GATT spec on the firmware matches the BLE client on the app, the protocol parser the app ships speaks the same dialect the device speaks, and the bring-up engineer can debug across the seam without throwing a defect over a wall. Same posture we've shipped under since the CVWS pairing flow first lit up.
A1SI has been shipping production-floor controllers and the operator software that drives them since 1992 — Ford FN-145 seat testers, the DVP2 digital multi-printer, the Spartan ActiveRide suspension controller, the GM ATEC EPROM programmer. The same engineering posture — operator-readable maintenance surfaces, savable diagnostic transcripts, openly documented interfaces — shapes every firmware and every app we touch today.
Firmware ships as source and as a signed binary with the OTA channel reproducible from the git tag. Apps ship as source with both store listings handed off to the customer's developer account. No proprietary RTOS lock-in on the device side, no Expo-only lock-in on the app side; if your team needs to take the program in-house tomorrow, every artifact is portable to your toolchain.
A1SI picks up connected-product programs at every stage — concept, joint architecture, parallel scaffolding, protocol contract, bring-up, store review, production OTA, post-launch support. Send the device, the use-case, or the BLE pairing flow you're stuck on; we'll come back with what we'd do next and what the engagement would look like.
"Apple", "iOS", "iPadOS", "Swift", "SwiftUI", "Xcode", "App Store", "TestFlight", "CoreBluetooth", "CoreML", and "Vision" are trademarks of Apple Inc. "Google", "Android", "Google Play", "Kotlin", "Jetpack Compose", "Firebase", and "Crashlytics" are trademarks of Google LLC. "React Native" is a trademark of Meta Platforms, Inc. "Expo" and "EAS" are trademarks of 650 Industries, Inc. "Espressif", "ESP-IDF", and "ESP32" are trademarks of Espressif Systems (Shanghai) Co., Ltd. "Nordic Semiconductor" and "nRF" are trademarks of Nordic Semiconductor ASA. "FreeRTOS" is a trademark of Amazon.com, Inc. or its affiliates. "Zephyr" is a trademark of the Linux Foundation. "Rust" is a trademark of the Rust Foundation. "STM32" is a trademark of STMicroelectronics N.V. "RP2040" is a trademark of Raspberry Pi Ltd. "Sentry" is a trademark of Functional Software, Inc. "Lutron", "HomeWorks", "HomeWorks Interactive", "StarBus", and "Vareo" are trademarks of Lutron Electronics Co., Inc. "Laumas" and "CLM8" are trademarks of Laumas Elettronica S.r.l. "Matter" and "Thread" are trademarks of the Connectivity Standards Alliance. "Modbus" is a trademark of Schneider Electric SE. "MQTT" is a registered standard from OASIS. "Home Assistant" is a trademark of the Home Assistant project. The A1SI Lutron HomeWorks Controller firmware is A1SI proprietary (© A1 Systems Integrators LLC) and is a third-party replacement processor that interoperates with installed Lutron HomeWorks Interactive systems; A1SI is not affiliated with or endorsed by Lutron Electronics Co., Inc. Descriptive editorial use only; A1SI is not affiliated with or endorsed by any other named third party.