me_yo/README.md
2026-05-16 18:12:53 +02:00

187 lines
5.8 KiB
Markdown

# Sistema de Riego Automático — ESP8266 + Docker
Stack completo para control y monitorización de riego con ESP8266/Tasmota,
Mosquitto, Python controller, InfluxDB y Grafana.
## Estructura del proyecto
```
└── docs/
├── tasmota-config.md # Comandos de configuración Tasmota
```
## Hardware
| Dispositivo | IP | Detalle |
|---|---|---|
| ESP8266 (Tasmota 15.4.0) | `192.168.1.42` | MAC `18:FE:34:D3:01:BA` |
| Broker Mosquitto | `192.168.1.200:1883` | Docker en este ordenador |
### Cableado GPIO (verificado)
| Pin NodeMCU | GPIO | Función | Notas |
|---|---|---|---|
| D1 | GPIO5 | Relay_i → IN1 | Motor riego (Relay1) |
| D6 | GPIO12 | Relay_i → IN2 | Motor abastecimiento solución (Relay2) |
| D7 | GPIO13 | Relay_i → IN3 | Motor abastecimiento agua (Relay3) |
| D2 | GPIO4 | SR04 Trig | Directo, sin resistencias |
| D5 | GPIO14 | SR04 Echo | Con divisor de tensión 5V→3.3V |
> ⚠️ Tasmota estándar no incluye SR04 — instalar `tasmota-sensors.bin` primero.
> La actualización OTA borra los GPIOs; hay que reconfigurarlos después.
> El módulo SunFounder es activo LOW → todos los relés usan `Relay_i` (inverted).
### Lógica de riego — Tasmota Rules (autónoma)
Los tres motores se controlan mediante una Rule en el propio ESP8266, sin necesitar el broker MQTT.
**Roles de cada motor:**
| Relay | Pin | Motor | Función |
|---|---|---|---|
| Relay1 | D1/GPIO5 | Riego | Distribuye agua a las plantas |
| Relay2 | D6/GPIO12 | Abastecimiento sustrato | Aporta solución nutritiva al depósito |
| Relay3 | D7/GPIO13 | Abastecimiento agua | Aporta agua limpia al depósito |
**Comportamiento:**
| Condición SR04 | Acción |
|---|---|
| Distancia > 30 cm | Relay2 y/o Relay3 ON (según modo) |
| Distancia < 10 cm | Relay2 y Relay3 OFF (Relay1 sigue) |
Relay1 (riego) arranca y para por comando independiente del sensor.
Si se para el riego, los motores de abastecimiento siguen hasta que la distancia baje de 10 cm.
**Rules activas en el ESP8266:**
**Rule1** lógica de sensores y motores + gestión automática de `Mem2`:
```
Rule1 ON SR04#Distance>30 DO if (mem1==1) Backlog Power2 ON; Power3 ON elseif (mem1==2) Power3 ON elseif (mem1==3) Power2 ON endif ENDON ON SR04#Distance<10 DO Backlog Power2 OFF; Power3 OFF ENDON ON Power1#State=1 DO Mem2 1 ENDON ON Power1#State=0 DO Mem2 0 ENDON
Rule1 1
```
**Rule2** reanudación automática tras corte de luz:
```
Rule2 ON System#Boot DO if (mem2==1) Power1 ON endif ENDON
Rule2 1
```
`Mem2` se gestiona automáticamente: se activa al encender el riego y se desactiva al apagarlo. No hace falta incluirlo en los comandos.
**Comandos de operación:**
| Acción | Comando |
|---|---|
| Encender modo completo (agua + sustrato) | `Backlog Mem1 1; Power1 ON` |
| Encender solo agua | `Backlog Mem1 2; Power1 ON` |
| Encender solo sustrato | `Backlog Mem1 3; Power1 ON` |
| Parar solo riego (abastecimiento sigue hasta <10 cm) | `Power1 OFF` |
| Parar todo | `Backlog Power0 OFF; Mem1 0` |
**Variables persistentes en flash:**
| Variable | Función |
|---|---|
| `Mem1` | Modo activo (1=completo, 2=solo agua, 3=solo sustrato, 0=parado) |
| `Mem2` | Auto-reanudación tras corte de luz gestionado automáticamente por Rule1 |
> **Arquitectura final:** esta lógica es autónoma y funciona sin red. El objetivo es
> que el broker **Mosquitto** reciba la telemetría del sensor vía MQTT y el
> **controller Python** envíe los comandos `Power1/2/3` con lógica adicional
> (franjas horarias, niveles mínimos, alertas). Las Rules y el broker coexisten:
> las Rules actúan como capa de seguridad local aunque el broker no esté disponible.
Antes de levantar el stack, configura Tasmota: ver [docs/tasmota-config.md](docs/tasmota-config.md).
## Servicios Docker
| Servicio | Puerto | Descripción |
|---|---|---|
| mosquitto | 1883 | Broker MQTT (accesible desde ESP8266) |
## Variables de entorno clave
Ejemplo de programación:
```json
[{"days":["mon","wed","fri"],"time":"07:00","duration_minutes":20}]
```
## Documentación
- [Configuración Tasmota](docs/tasmota-config.md)
---
## Cómo se encontró el ESP8266
# ESP8266 - Localizar dispositivo en la red local
## Problema
Tienes un ESP8266 conectado a la red WiFi pero no recuerdas su IP.
## Solución: escaneo de red
### 1. Identificar tu red
```bash
ip route | grep default
```
Esto muestra tu puerta de enlace y la IP de tu máquina. En este caso:
- Red: `192.168.1.0/24`
- Tu PC: `192.168.1.41`
- Router: `192.168.1.1`
### 2. Ping sweep para descubrir dispositivos activos
```bash
for i in $(seq 1 254); do ping -c 1 -W 1 192.168.1.$i > /dev/null 2>&1 & done; wait
```
Envía un ping a cada IP posible de la red (`192.168.1.1` hasta `192.168.1.254`) en paralelo. Esto hace que tu sistema guarde en la tabla ARP la MAC de cada dispositivo que responde.
### 3. Consultar la tabla ARP
```bash
ip neigh show | grep -v FAILED | sort -t . -k 4 -n
```
Muestra todos los dispositivos detectados con su IP y dirección MAC. El truco está en identificar la MAC del ESP8266.
### 4. Identificar el ESP8266 por su MAC (OUI)
Los primeros 3 bytes de una MAC identifican al fabricante (OUI). Espressif Systems, el fabricante del ESP8266/ESP32, tiene estos prefijos conocidos:
| Prefijo MAC | Fabricante |
|---|---|
| `18:FE:34` | Espressif Systems |
| `5C:CF:7F` | Espressif Systems |
| `60:01:94` | Espressif Systems |
| `A0:20:A6` | Espressif Systems |
| `84:F3:EB` | Espressif Systems |
En el escaneo apareció:
```
192.168.1.42 lladdr 18:fe:34:d3:01:ba REACHABLE
```
El prefijo `18:FE:34` confirma que es un dispositivo Espressif **es el ESP8266**.
### 5. Verificar conectividad
```bash
ping -c 3 192.168.1.42
```
Responde correctamente con ~120ms de latencia (normal para WiFi).
## Resultado
| Dato | Valor |
|---|---|
| IP del ESP8266 | `192.168.1.42` |
| MAC | `18:fe:34:d3:01:ba` |
| Fabricante | Espressif Systems |