ESP32 Wi-Fi and Bluetooth Gateway Integration | Obeita
Delivered project. The completed hardware and software met the customer’s agreed requirements in testing. Specifications for a new project must be agreed separately.
Obeita delivered this ESP32 Wi-Fi and Bluetooth gateway project for a customer requiring a defined connection between local devices and a host network. The work covered customer requirements, contract scope, hardware and software design, physical testing and delivery. Its main engineering distinction was the separation of Wi-Fi/IP access from Bluetooth SIG Mesh message exchange.
Turning connection requirements into a gateway role
The project began with the required device-to-host communication path. Wi-Fi access and Mesh command exchange place different demands on firmware, so the requirements and contract scope established which gateway behaviour the customer needed. This kept the hardware interfaces, software role and expected application behaviour aligned.
The documented ESP32 architecture includes a wired LAN connection and STA, AP or combined STA/AP Wi-Fi roles. It is oriented toward device telemetry and configuration traffic rather than broadband routing. Client count and forwarding load must be validated with the selected firmware for a new deployment; the interface list alone does not establish those limits.
Hardware and software work around two protocol paths
Hardware and software design were carried through for the agreed gateway scope. The IP side concerns local network access, while the documented Bluetooth path uses a PB-series module, SIG Mesh and AT-command exchange. The technical focus was the relationship between a selected communications role and the data the application needed to exchange.
For a similar Mesh integration, node models, uplink fields and downlink commands need an explicit mapping. Arbitrary Bluetooth audio products, BLE sensors and proprietary profiles are outside a SIG Mesh compatibility assumption. Simultaneous Wi-Fi gateway and Mesh gateway operation also needs an explicit firmware scope.
Documented architecture and configuration
The table records the documented architecture, configuration directions and selection boundaries for this case. Optional items, firmware-dependent choices and expansion directions are not independent guarantees that every listed option was delivered. The agreed project hardware, software and functional scope define the actual delivery.
| Item | Configuration |
|---|---|
| Processor | ESP32 platform |
| Wired link | One LAN port |
| Wi-Fi | 802.11 b/g/n; STA / AP / STA+AP roles |
| Bluetooth path | PB-series module; SIG Mesh; AT-command exchange |
| Provisioning | SmartConfig / AirKiss concepts; selected firmware to be confirmed |
| Development access | Flashing and Ethernet development interfaces |
Delivery outcome and test scope
The agreed gateway hardware and software were completed and delivered. Physical functional testing confirmed that the delivered project met the customer’s requirements.
This completion applies to the agreed project functions. It does not establish universal Bluetooth interoperability, combined operation of every firmware role, or a published throughput or load rating. SmartConfig and AirKiss remain documented provisioning directions subject to the selected firmware.
Discuss a similar project
Send Obeita the Wi-Fi equipment or Mesh node details, example uplink and downlink messages, LAN connection requirements and any need for combined operation. These inputs allow a new gateway project to be scoped around the required application path.