HeliControl integrates ESP8266 IoT devices for cockpit door access and simulator telemetry, with secure backend communication and monitoring through the mobile application.
Each ESP8266 has a specific role and communicates with its dedicated backend API endpoint. This separation helps maintain clear validation, processing and security boundaries.
Handles cockpit door-state monitoring and access integration with the backend system.
/api/iot/door.php
Submits simulator telemetry to the backend for validation, storage and alert processing.
/api/iot/telemetry.php
IoT data passes through the relevant API and backend processing layer before reaching persistent storage. Telemetry can then feed the alert engine and Flutter monitoring interface.
Door-state reporting or simulator telemetry submission over HTTPS.
The relevant Door API or Telemetry API receives the HTTP request and JSON payload.
Device authentication, request validation, cockpit association checks and server-side business logic.
Validated system information and relevant records are stored through the backend.
The telemetry flow can trigger configured operational alerts and update the monitoring experience through backend services.
The IoT integration uses HTTP requests with JSON payloads and device API-key authentication. The following routes document the known API surface; this page does not execute device commands or modify backend records.
Retrieves the current door state or submits a door-state update, subject to the endpoint's authentication and validation rules.
GET /api/iot/door.php?cockpit_id=1 POST /api/iot/door.phpRetrieves current telemetry or submits a new telemetry payload for backend validation and processing.
GET /api/iot/telemetry.php?cockpit_id=1 POST /api/iot/telemetry.phpDevice requests use HTTPS. POST requests send JSON and authenticate using the assigned device key. Secrets must remain outside public website code.
Content-Type: application/json X-API-Key: [device key kept private]These are documented telemetry field names that describe the type of information the monitoring system may handle. They are not readings retrieved from the live database.
Example schema labels / not live sensor output
IoT security is enforced through the backend API rather than by trusting device requests or exposing database access to the network.
The PHP backend acts as the security boundary between device traffic, persistent data and application services. The public website explains these controls; it does not replace or implement them.
IoT requests supply the expected
X-API-Key header. Missing or
invalid credentials should be rejected by
the existing backend.
The backend checks the registered device and relevant cockpit association before processing an authorised request.
Incoming JSON data must be checked for required fields, expected types and valid values by the server-side implementation.
Device input reaches MySQL through backend logic. Database credentials and direct database connectivity are not exposed to the ESP8266 or public page.
Relevant telemetry can feed the existing operational alert engine. Security events and cockpit operational alerts remain distinct processing categories.
API tests and physical hardware integration are separate milestones. A successful manual HTTP request alone does not prove that an ESP8266 device is fully integrated.
Previous project notes record successful manual Door API state-update scenarios and controlled authentication or payload-validation responses. Retest against the current deployment before final demonstration.
Confirm the actual Door and Telemetry ESP8266 hardware, firmware configuration, real payloads, device connectivity and end-to-end behaviour.
Keep the existing PHP APIs, MySQL data layer, backend validation and relevant Flutter monitoring flows. This website page does not alter them.
Explore the project architecture, application interface and cybersecurity controls to understand how each component contributes to HeliControl.