Reto Agrotech

Objetivo
Desarrollar una web app responsiva que permita a un agricultor monitorizar en tiempo real sensores ubicados en una parcela (temperatura, humedad del suelo, luminosidad, humedad ambiental, etc.). La solución debe ser un proyecto desarrollado con software libre, usando Python tanto en backend como en frontend (frontend con Reflex), base de datos SQLite, control de versiones con git y código publicado en GitHub.

Público objetivo y premios
Estudiantes: 2.º curso de ciclos formativos de informática.
Alcance: prototipo funcional que conecte/consuma datos de sensores (simulados o reales), muestre datos en tiempo real / casi real y permita visualizar históricos y alertas básicas.

Formación de equipos
Se formarán 5 equipos de trabajo, cada uno compuesto por 5 integrantes, que deberán colaborar para planificar, desarrollar y presentar su propuesta final.
Cada equipo dispondrá de varias semanas para desarrollar el proyecto, siguiendo las fases de análisis, diseño, desarrollo, documentación y presentación.

Premios
Los tres mejores proyectos recibirán los siguientes premios en metálico:
🥇 1.º Premio: 500 €
🥈 2.º Premio: 300 €
🥉 3.º Premio: 200 €
Los ganadores serán seleccionados por un jurado compuesto por profesionales del sector tecnológico, profesores de los ciclos formativos, y expertos del sector agroalimentario, que valorarán la funcionalidad, calidad técnica, innovación, documentación y presentación final del proyecto.

Requisitos funcionales (mínimos)
1. Autenticación básica de usuarios (rol agricultor y rol técnico/visor).
2. Panel principal que muestre datos en tiempo real de múltiples sensores por parcela (dashboard con métricas y gráficos).
3. Listado de parcelas y sensores asociados (crear/editar/borrar).
4. Visualización histórica: gráficos por sensor para rango de fechas.
5. Alertas: definición de umbrales por sensor y notificación visual cuando se excedan.
6. Registro de datos en SQLite.
7. API REST para enviar y leer datos de sensores. Debe quedar documentada.
8. Interfaz responsiva.
9. Código público en GitHub con README claro.
10. Código bien documentado (docstrings, comentarios, guía de despliegue).
11. Uso de git internamente (commits frecuentes, ramas feature, pull requests internas).

Requisitos técnicos (detallados)
Lenguaje: Python (tanto backend como frontend).
Frontend y Backend: Reflex (la tecnología de Python para UI reactivas). Interfaz escrita en Python usando Reflex components.
Base de datos: SQLite (archivo .db). Uso a través del módulo sqlite3 o mediante un ORM ligero (ej. SQLModel/SQLAlchemy) — opcionalmente, pueden usar SQLAlchemy si lo justifican.
Comunicación sensores → backend:
Debe existir un endpoint REST POST /api/sensors/{sensor_id}/data que acepte payload JSON con timestamp y value.
Opcional: WebSocket para streaming en tiempo real ws://…/ws/parcela/{id}.

Formato de dato de ejemplo (JSON):
{
  "sensor_id": "t001",
  "timestamp": "2025-10-10T12:34:56Z",
  "type": "temperatura",
  "value": 23.7,
  "unit": "ºC"
}

Versionado y publicación: repositorio público en GitHub
Documentación: README con instalación, arranque local, endpoints y ejemplos. Comentarios y docstrings en el código.
Pruebas: tests unitarios básicos para la lógica backend (pytest recomendado).
Licencia: MIT (u otra compatible con software libre) y archivo LICENSE.

Entregables (qué deben subir al repo)
1. Código fuente completo (frontend Reflex + backend Python).
2. Archivo SQLite de ejemplo con datos de sensores (o script generador de datos).
3. README.md con: propósito, instalación, cómo ejecutar en local, endpoints, ejemplo de payload, screenshots.
4. Documento corto (PDF o MD) explicando la arquitectura y decisiones técnicas (máx 2 páginas).
5. Licencia y CONTRIBUTING.md (breve) explicando flujo git.

Esquema sugerido de base de datos (SQLite)

Tablas básicas:
users
id (INTEGER, PK)
username (TEXT)
password_hash (TEXT)
role (TEXT)
parcels
id (INTEGER, PK)
name (TEXT)
location (TEXT)
sensors
id (TEXT, PK) -- ej. "t001"
parcel_id (INTEGER, FK parcels.id)
type (TEXT) -- temperatura, humedad_suelo, luminosidad...
unit (TEXT)
description (TEXT)
threshold_low (REAL)
threshold_high (REAL)
sensor_data
id (INTEGER, PK)
sensor_id (TEXT, FK sensors.id)
timestamp (TEXT ISO)
value (REAL)
raw (TEXT) -- opcional JSON
alerts
id (INTEGER, PK)
sensor_id
timestamp
type (TEXT) -- "LOW"/"HIGH"
message (TEXT)
acknowledged (BOOLEAN)

Endpoints sugeridos
POST /api/auth/login → obtiene token (si aplica).
GET /api/parcels → listar parcelas.
GET /api/parcels/{id}/sensors → sensores de parcela.
POST /api/sensors/{sensor_id}/data → enviar dato sensor (permitir fuentes externas o simulador).
GET /api/sensors/{sensor_id}/data?from=&to=&limit= → histórico.
GET /api/dashboard → resumen (último valor, alertas).
WS /ws/parcels/{id} → (opcional) streaming en tiempo real.
Documentar ejemplos de uso en README.

Reglas de calidad del código y documentación
Docstrings en funciones principales y en modelos.
README con INSTRUCCIONES CLARAS: cómo instalar deps (requirements.txt), cómo inicializar DB, cómo ejecutar backend y frontend.
Comentarios donde la lógica no es evidente.
Buenas prácticas git: commits atómicos, mensajes descriptivos, uso de PR para merge a main.

Entrega / formato de presentación para el evento
Repo público en GitHub con README.md principal.
Breve presentación (3–5 diapositivas) explicando idea, arquitectura, demo link.
Demo en vivo.

Cronograma sugerido (4 semanas, adaptable)
Semana 1: Especificación detallada, diseño DB, setup repo, primer endpoint de ingestión de datos y script de simulación.
Semana 2: Desarrollo backend: endpoints de lectura/histórico y almacenamiento. Tests básicos.
Semana 3: Frontend Reflex: dashboard en tiempo real, listado de sensores y gráficos. Integración con endpoints.
Semana 4: Pulido UI, alertas, documentación, README, pruebas y preparación de demo.

Criterios de evaluación
Funcionalidad básica (40 pts): ingestión datos, almacenamiento, dashboard, histórico, alertas.
Calidad del código (15 pts): docstrings, tests, linter, estructura.
UI / UX (15 pts): responsividad, usabilidad, visualización clara de datos.
Documentación y repo (10 pts): README, licencia, instrucciones de arranque.
Uso de git + flujo de trabajo (10 pts): commits, branches, issues y PRs.
Extras (10 pts): despliegue, demo en vídeo.

Pautas sobre sensores y pruebas
Si no tienen sensores físicos, proporcionar un simulador (scripts/gen_sample_data.py) que haga POST periódicos al endpoint POST /api/sensors/{sensor_id}/data.
Simulador: enviará valores realistas (ej. temperatura 5–40ºC dependiendo hora/día).
Indicar claramente en README cómo activar el simulador.

Plantilla corta de README.md (para pegar en el repo)

# Reto Agrotech – Monitorización agrícola (Equipo X)
## Resumen
WebApp responsiva para monitorizar sensores en parcelas agrícolas. Backend en Python, frontend con Reflex, base de datos SQLite.
 
## Requisitos
- Python 3.10+
- Virtualenv
 
## Instalación rápida
```bash
git clone https://github.com/tu-org/agrotech-reto.git
cd agrotech-reto
python -m venv venv
source venv/bin/activate
pip install -r requirements.txt
 
# Inicializar DB
python backend/init_db.py
 
# Ejecutar backend (FastAPI)
cd backend
uvicorn app:app --reload
 
# Ejecutar frontend (Reflex)
cd frontend
python main.py

Licencia
MIT

# Checklist rápido para las estudiantes
- [ ] Repo público en GitHub con licencia.   
- [ ] Backend funcionando localmente (endpoints mínimos). 
- [ ] Frontend Reflex mostrando dashboard. 
- [ ] Script simulador de datos. 
- [ ] README con instrucciones testadas.