Simulador fotovoltaico
Una herramienta que responde cuántos kilovatios de placas y cuánta batería compensan en una casa concreta, con producción solar a partir de datos meteorológicos reales, la tarifa española tal como se factura y estrategias de batería comparables entre sí.
Empezó como una herramienta casera para decidir la mejor configuración de la instalación de casa con mis consumos reales: estudios en Python, después una librería y al final una aplicación web que acabé pensando como producto. En marcha desde octubre de 2026, con una demo pública de solo lectura (viviendas de ejemplo, sin registro) y cuentas propias por invitación en beta. Sigue en evolución, pensada para abrirse a instaladores y asesores con estudios por cliente e informes.
- Simulación física y económica real del autoconsumo: producción con datos meteorológicos típicos, baterías con estrategias y la factura española con su compensación.
- Escenarios calculados con un evaluador compartido y un calendario de referencia, y una comprobación por código del coste anual sin placas frente al comparador de tarifas.
- De herramienta casera a producto: empezó resolviendo una decisión propia con mis consumos reales y hoy tiene cuentas de usuario, catálogo compartido, una demo pública y un camino hacia instaladores.
- Dominio energético de primera mano: una herramienta que aconseja potencia, desplazamiento de consumo y estrategia de batería sobre el perfil real.
- Un producto puesto en marcha de extremo a extremo: demo pública de solo lectura, privacidad pensada desde el diseño y despliegue reversible en una VM compartida.
Decidir cuántos kilovatios pico y cuánta batería instalar es una decisión de varios miles de euros que se toma con la hoja de cálculo del instalador, con supuestos que nadie audita y sin comparar tarifas de verdad. Dos presupuestos no se pueden comparar porque cada uno asume cosas distintas.
Un calendario de referencia y un evaluador compartido por las simulaciones. Consumo, producción y periodos tarifarios se alinean sobre un año de 8.760 horas para comparar escenarios con las mismas bases. El comparador de tarifas mantiene su cálculo propio; un comando contrasta ambos caminos en el caso anual sin placas.
Un evaluador que recibe una configuración sin exigir guardar una simulación: carga el perfil de consumo y reúne producción solar, batería y coste. Lo reutilizan los resultados, los cálculos en vivo y los comparadores de simulaciones, sobre un calendario de referencia de 8.760 horas. El comparador de tarifas tiene su cálculo propio, contrastado con el evaluador en el caso sin placas.
- Producción solar con el año meteorológico típico de PVGIS, temperatura de célula, pérdidas ópticas, recorte del inversor y degradación; caché en disco, cielo despejado si no hay red y alineada a hora civil con el cambio de horario.
- La factura española tal como se calcula: periodos con festivos nacionales, términos de potencia, fijos e impuestos, y tres modos de compensación de excedentes, incluido el mensual que fija la normativa.
- Un evaluador compartido por el comparador de escenarios, los barridos por eje y el panel pareado en vivo, y un comando que contrasta su coste anual sin placas con el del comparador de tarifas.
Las evidencias21
- Modelado y simulaciónDemo · Acceso público
En la demo pública se ejecuta una simulación hora a hora de una instalación concreta: producción con el año meteorológico típico de PVGIS, autoconsumo, excedentes y factura antes y después, y una batería con estado de carga y estrategias de operación —autoconsumo, arbitraje cargando en valle y respaldo— que se comparan sobre el mismo caso. Por dentro, pvlib con modelo térmico de la célula, pérdidas ópticas, inversor con recorte y degradación anual.
- Dominio energético: autoconsumo y tarifas eléctricasMejor ejemplo del portfolioDemo · Acceso público
- Rigor en el análisis de datosCódigo · Bajo petición
- Arquitectura por capas (capa de servicios)Código · Bajo petición
- Tests de regresión y equivalenciaCódigo · Bajo petición
- Visualización de datosDemo · Acceso público
- Desarrollo de productoCódigo · Bajo petición
- ETL e ingesta de datosCódigo · Bajo petición
- Integración de APIs de tercerosCódigo · Bajo petición
- Integridad de datosCódigo · Bajo petición
- Renderizado en servidor (SSR)Código · Bajo petición
- Context engineeringDocumento · Bajo petición
- Aprendizaje rápidoCódigo · Bajo petición
- Administración de servidores LinuxCódigo · Bajo petición
- Despliegues reversibles (rollback)Código · Bajo petición
- Protección de datos y confidencialidadCódigo · Bajo petición
- Seguridad de aplicaciones webCódigo · Bajo petición
- Planificación de capacidadCódigo · Bajo petición
- Tareas programadasCódigo · Bajo petición
- Diseño de UX para usuarios no técnicosEn producción · Acceso público
- Gestión del alcanceDecisión escrita · Bajo petición
Principios que se ven aquí10
- PrincipioCuando migro o refactorizo, verifico la equivalencia con código, no con confianza
- Un comando contrasta el coste anual del comparador de tarifas con el del evaluador sin placas para un perfil, con tolerancia configurable
- PrincipioUna acción existe una vez; todas las interfaces la llaman
- Un mismo evaluador sirve a la simulación, a los comparadores de simulaciones y al panel en vivo
- PrincipioEn producción, lo mínimo que resuelve el problema
- SQLite con WAL, un solo proceso con hilos y tope de memoria, estáticos servidos por la propia aplicación y copia diaria con un temporizador: sin servidor de base de datos ni broker en una VM compartida
- PrincipioNo construyo nada que no haya entendido antes
- Escrito en el contexto del proyecto: si algo funciona y es entendible, se deja en paz
- PrincipioCada dato tiene un solo sitio donde se escribe; el resto lo lee
- El comparador y la simulación daban costes distintos; se resolvió con un único calendario y una única clasificación de periodos tarifarios
- PrincipioLo seguro es el camino por defecto, y se garantiza en un solo sitio
- La demo pública es de solo lectura por construcción: un único middleware bloquea las vistas por prefijo de nombre —crear, editar, eliminar, guardar, aplicar— y cualquier POST fuera de una lista blanca mínima
- PrincipioLas reglas que importan las vigila una comprobación, no la memoria
- El script de despliegue se detiene si la comprobación de despliegue de Django da algún aviso, y verifica la salud de la aplicación antes de dar la versión por buena
- PrincipioConsistente antes que ingenioso: lo nuevo hereda el molde de lo que ya funcionó
- El despliegue en VM —versiones inmutables, vuelta atrás, copia diaria y servicio endurecido— parte del molde de Mindundi, que a su vez sigue el de Ajuntaweb 2.0
- PrincipioEl sistema no promete lo que no hace
- La página de inicio dice qué es y qué no es la herramienta, el catálogo de tarifas se presenta como orientativo y «Próximamente» se reserva a lo que figura en la hoja de ruta
- PrincipioDel dato personal, solo el que sirve a un propósito, durante un plazo y a la vista
- Al subir el consumo se elimina el CUPS, el servicio meteorológico solo recibe coordenadas redondeadas, que no señalan la vivienda exacta, los ficheros de los usuarios no se sirven y las copias caducan; una página pública de privacidad lo cuenta