Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/GaelCeballos/Smart_Enviro_Backend/llms.txt

Use this file to discover all available pages before exploring further.

A device in Smart Enviro Backend represents a physical ESP32 microcontroller registered in the database with a unique mac_address and device_token. Devices start unassigned — they have no user_id — and must be claimed by a user before they can be controlled. Once claimed, the owner has full control over the device’s state and configuration.

Device Lifecycle

1

Provisioning

An admin registers the ESP32’s MAC address and generates a unique 64-character device_token in the database. The device receives this token via firmware configuration before it is deployed.
2

Boot & Sync

On every power-up, the ESP32 calls GET /api/device/sync with its device_token. The backend verifies the token, confirms the device is active, and returns the current command (ON, OFF, or STANDBY) together with all stored configuration properties.
3

Discovery

The ESP32 appears in GET /api/devices/available — the list of devices with no user_id that are active and waiting to be claimed. Authenticated mobile clients poll this endpoint to show a “nearby devices” list.
4

Claiming

A user calls POST /api/devices/{id}/add to assign the device to their account. The backend sets user_id on the device record and creates a DEVICE_ADDED log entry in device_logs. After this step the device no longer appears in the available list.
5

Control

The owner can toggle the actuator state via POST /api/my-devices/{id}/toggle (accepts ON, OFF, or STANDBY) and update configuration properties via PUT /api/my-devices/{id}/properties. Both endpoints are protected by Laravel Sanctum and enforce ownership.
6

Decommission

Devices support soft-delete via the deleted_at column. A soft-deleted or inactive device (is_active = false) receives a SLEEP command on the next sync call, signalling the ESP32 to enter deep sleep mode and stop reporting.

Device States

The current_state column is an enum with three possible values. It is set by the device owner through the toggle endpoint and returned to the ESP32 on every sync and sensor-data response.
StateMeaning
ONActuator is active (e.g. pump is running)
OFFActuator is inactive
STANDBYDefault idle state — device is online but not commanded; the ESP32 should evaluate its own automation logic

Device Fields

These columns are defined in the devices migration and are available on the Device model.
FieldTypeNotes
idbigintAuto-incrementing primary key
user_idbigint (nullable)Foreign key to users; null until the device is claimed
mac_addressstring(17)Unique hardware identifier, e.g. AA:BB:CC:DD:EE:FF
device_tokenstring(64)Unique secret used by the ESP32 to authenticate — never exposed to end users
namestringHuman-readable label; defaults to "Dispositivo Smart Enviro"
typestring(50)Free-form device type string, e.g. bomba, sensor_multi
is_activebooleanSoft-disable flag; inactive devices receive SLEEP on sync
is_onlinebooleanSet to true automatically when the device pushes a sensor reading
current_stateenumOne of ON, OFF, STANDBY
last_seen_attimestamp (nullable)Updated every time the device successfully pushes sensor data

Device Types

The type field is a free-form string used by mobile clients and the web frontend to determine which UI components to render for a given device. The backend does not validate or restrict its value beyond a 50-character limit.
Use consistent, lowercase snake_case type strings across firmware, backend seeds, and mobile app code. Agreed-upon values in the current project include bomba (pump actuator) and sensor_multi (multi-sensor node). Documenting these in a shared constant file prevents UI mismatches when new device types are introduced.

Device Logs

Every significant device event is recorded in the device_logs table. The DeviceLog model disables updated_at (logs are append-only), stores a log_type, a human-readable message, and an optional payload JSON object. Logs are created automatically by the API in two situations:
Triggerlog_typeDescription
POST /api/devices/{id}/addDEVICE_ADDEDRecords which user claimed the device, including their user_id and email
PUT /api/my-devices/{id}/propertiesCOMMANDRecords which property key was changed and stores new_value in the payload
The payload JSON object can hold any additional context relevant to the event, such as the old or new value of a property.

ESP32 Integration

Step-by-step guide for connecting your ESP32 firmware to the backend — boot sync, sensor push, and actuator command handling.

Device Properties

Full reference for the key-value property store: standard property keys, update API, and how properties flow back to the ESP32.

Build docs developers (and LLMs) love