# Entorno y despliegue Inventario observado el 2026-09-10: | Componente | Resultado | |---|---| | PHP CLI | 8.3.14 | | PDO | drivers mysql y sqlite disponibles | | Apache | 2.4.62 | | Cliente MariaDB | 11.4.4 | | Node / npm | no disponibles en PATH | La versión del cliente MariaDB no confirma la versión ni disponibilidad del servidor. No se probaron credenciales ni se crearon bases de datos. El desarrollo usa `127.0.0.1:8091` con el servidor integrado de PHP. La prueba arranca una instancia temporal en un puerto libre y la detiene. El servidor integrado es únicamente para desarrollo. Para publicar, preparar un virtual host con DocumentRoot apuntando a `backend/public`, TLS, ejecución PHP y reescritura al front controller. La configuración debe impedir servir el resto del repositorio, incluidos archivos ocultos y documentación. Los archivos `.htaccess` incluidos requieren AllowOverride apropiado y mod_rewrite; no sustituyen la validación del virtual host. El API usa rutas desde `/api/v1`, no desde `/homecore/`. No se modificaron virtual hosts, certificados, firewall ni servicios. No hay despliegue público validado. El proxy `/ws` se configurará cuando exista el servicio Node, siempre escuchando en localhost. ## Actualización de desarrollo — 2026-09-11 Se usa MariaDB aislado con socket privado y sin TCP mediante `deployment/scripts/database-dev.sh`. Su directorio predeterminado es `~/.local/share/homecore-dev`; también contiene sesiones privadas. El arranque PHP aplica migraciones y sirve la interfaz y API en localhost. La instancia existente del servidor no se configura ni se usa para pruebas. La publicación pública y el navegador móvil real aún deben validarse. ## Piloto público — estado actual El usuario eligió https://transbook.mx/homecore/ y ESP32 DevKit V1 de 30 pines. Se publicó bajo ese prefijo, sin inicializar Git. El virtual host HTTPS transbook.conf incluye deployment/apache/transbook-homecore.conf. La ruta /homecore/ws se enruta con ProxyPass HTTP Upgrade a 127.0.0.1:8080/ws; el resto de /homecore pasa al front controller por FastCGI en 127.0.0.1:9074. Se creó virtual host HTTP transbook.mx/www que redirige al HTTPS existente. La raíz HTTPS de Transbook conserva su DocumentRoot. PHP-FPM es un proceso independiente para HomeCore, con cuatro workers máximos, usuario bitnami, entorno production, cookie Secure/HttpOnly, SameSite=Lax y Path=/homecore. Sus sesiones están en pilot-sessions, separadas de las sesiones de desarrollo. Las cuentas y hogares no se recrearon. Servicios instalados/habilitados: homecore-database, homecore-php, homecore-websocket y homecore-telemetry-cleanup.timer. Copias de referencia en deployment/systemd. El MariaDB privado inicial ahora está gestionado por systemd; no usar database-dev.sh stop mientras el piloto esté activo. Node es 24.21.0, ws 8.21.3, mysql2 3.24.4. Los puertos internos no se abrieron al exterior. No se modificó el PHP-FPM que usan otros sitios. Credenciales reales solo en ~/.config/homecore/app.env y websocket.env, con permisos 0600. PHP usa homecore_app con DML sobre la base del piloto; Node usa homecore_transport con SELECT/UPDATE devices y SELECT/INSERT sensor_readings. Las migraciones usan root local fuera del proceso web. Las copias anteriores a migraciones/configuración están fuera de htdocs, en ~/.local/share/homecore-dev/backups. El procedimiento de reconstrucción debe restaurar esa base y suministrar nuevamente los EnvironmentFile; los archivos del proyecto no contienen secretos. Validación: Apache Syntax OK, página principal Transbook 200, HomeCore HTTPS/API/assets, cookie Secure bajo prefijo, WSS con certificado validado, telemetría persistida y acceso por API. La prueba pública creó y eliminó solo sus propios registros temporales. Los tests de integración usan otras bases. El firmware se compila con Arduino ESP32 3.3.11 para DOIT ESP32 DEVKIT V1; la validación física queda pendiente de cargar la placa del usuario. Rollback de publicación: retirar el Include de HomeCore en transbook.conf y el vhost transbook-homecore-http.conf, validar Apache y recargar graceful; detener/deshabilitar los servicios de HomeCore solo si se retira todo el piloto. No eliminar la base ni sus respaldos. Mantener la migración permite seguir usando la aplicación en desarrollo. ## Evaluación de alertas Migración 004 y `homecore-alerts.timer` instalados tras copia privada de la base. El timer ejecuta un servicio PHP oneshot cada 10 segundos, usando `app.env`. No requiere reiniciar la ESP32 ni modificar el servicio WebSocket. Guía, reglas, permisos y recuperación en [alerts.md](alerts.md). ## Control LED GPIO23 Migración 005 aplicada con respaldo privado previo. Transporte reiniciado y validado por HTTPS/WSS con dispositivo de prueba virtual, sin actuar sobre la placa real. homecore_transport ahora tiene SELECT/UPDATE sobre device_commands y SELECT sobre home_members para comprobar autorización al despachar. Paquete HomeCoreLED.zip compilado para DOIT ESP32 DEVKIT V1 con DHT11 y GPIO23. La placa del usuario requiere cargar ese paquete para anunciar capacidad LED. ## Fichas de dispositivos por habitación Migración 006 aplicada con respaldo privado previo. room_devices almacena nombres y componentes de sensor/tira separados. Node requiere INSERT sobre room_devices para crear la ficha LED cuando se anuncia esa capacidad. No cambia firmware ni credenciales. Los datos del piloto se completaron solo para el controlador 4 con las especificaciones facilitadas por el usuario. Migración 007: ubicaciones independientes por room_device, aplicada tras respaldo. No modifica ubicaciones del piloto hasta que el propietario elija moverlas. Node crea nuevas fichas LED en la ubicación del controlador, sin sobrescribir la ubicación de fichas existentes al reconectar. No necesita firmware nuevo. ## HC-SR501 y automatización local Migración 008 tras respaldo privado; añade ajustes y estado PIR, sin nuevas credenciales ni privilegios de DB. Transporte reiniciado, compatibilidad LED anterior validada y paquete HomeCorePIR.zip compilado para ESP32 3.3.11. Guía física/instalación firmware/esp32-reference/PIR-HC-SR501.md; protocolo local y cloud docs/pir-automation.md. Pruebas remotas solo con dispositivos virtuales; el usuario conecta el PIR y carga el nuevo firmware.