La batería marcaba un 15% y seguía bajando. Estaba de vacaciones, no tenía cargador donde me alojaba y mi opción habitual para recuperar autonomía no estaba disponible. Abrí la app de recarga pública: todos los puntos cercanos aparecían ocupados.
Ahí estaba el problema. La aplicación permitía reservar una plaza cuando ya estaba libre, pero no avisaba cuando se liberaba. La única alternativa era abrirla una y otra vez, actualizar el mapa y confiar en llegar antes que otra persona.
En vez de pasar la tarde mirando una pantalla, decidí automatizar la espera.
La hipótesis
La idea era sencilla: si podía consultar el estado de varios cargadores cada pocos minutos y detectar el instante exacto en que una toma cambiaba a disponible, una notificación me daría tiempo para reaccionar.
No necesitaba otra app. Necesitaba un vigilante.
El primer workflow
Con n8n, Codex y Jarvis monté un flujo que consultaba varios puntos públicos cercanos cada dos minutos. Cada respuesta incluía el estado de sus conectores: ocupado, conectado, reservado o disponible.
El detalle importante era no avisar por el estado, sino por el cambio de estado. Si una toma permanecía libre durante diez minutos, no quería recibir cinco mensajes. El workflow guardaba el estado anterior y solo enviaba una alerta cuando detectaba una transición a AVAILABLE.
El flujo quedó así:
- Consultar periódicamente los cargadores seleccionados.
- Normalizar el estado de cada toma.
- Compararlo con la lectura anterior.
- Enviar una alerta a un canal privado solo al pasar a disponible.
- Limitar los avisos técnicos para que un fallo temporal no generase ruido.
El obstáculo inesperado
La lógica funcionaba, pero apareció el problema más interesante del experimento: la protección de la web rechazaba las peticiones realizadas directamente por el cliente HTTP de n8n.
La misma consulta sí funcionaba mediante curl. Así que añadimos un pequeño helper local en Python: n8n le pedía los datos, el helper hacía la consulta con curl y devolvía una respuesta limpia al workflow.
Lo ejecutamos como un servicio aislado, accesible únicamente desde la propia máquina y con reinicio automático. La sesión se guardó en las credenciales cifradas de n8n, fuera del código y del workflow.
No era la arquitectura más elegante del mundo, pero sí una solución pequeña, controlada y suficientemente robusta para resolver el problema real.
La prueba de verdad
El monitor quedó activo. Las primeras ejecuciones encontraron todos los conectores ocupados, justo como mostraba la aplicación. Eso era una buena señal: el sistema estaba leyendo datos reales y, como no había transición, permanecía en silencio.
Después llegó el mensaje que estaba esperando: una toma acababa de quedar disponible.
Fui al punto de recarga, conseguí plaza y pude cargar el coche. Además, aquella recarga resultó gratuita.
Resultado
Funcionó. El experimento convirtió una carencia muy concreta de una app —no avisar cuando se libera una plaza— en una automatización útil construida en una tarde.
También dejó dos aprendizajes claros:
- En una alerta, detectar transiciones suele ser más valioso que repetir estados.
- Cuando una capa de protección bloquea un cliente concreto, un adaptador mínimo puede ser más práctico que complicar todo el workflow.
Quedó una limitación: la sesión utilizada para consultar el servicio caduca y hay que renovarla manualmente. Si volviera a desarrollar el sistema, ese sería el siguiente punto a resolver.
Pero como experimento cumplió su objetivo: dejé de vigilar la app, recibí el aviso a tiempo y cargué por 0 €.
Funcionó: recibí el aviso cuando se liberó una toma y pude cargar el coche gratis.
Eliminar la renovación manual de la sesión y convertir el monitor en un sistema reutilizable para otros proveedores.