La opción select devices funciona, gracias por la información @pierre-gilles, me había pasado por alto. ¡Es un simplificador! Pero sigue siendo un recorrido de usuario no óptimo y no sencillo. Porque en resumen el usuario debe:
Modificar la URL en su aplicación
Ir a Descubrimiento y agregar el terminal a Gladys. Pero el terminal está en un estado « inestable » en ese momento. Puede comunicarse con Gladys, pero no con el puente Cloud.
Volver a Configuración para seleccionar el terminal y agregar una URL: pero en una interfaz no vinculada directamente al dispositivo
Para ver una URL configurada por terminal, hay que ir a ver en el dispositivo o en el descubrimiento donde se pueden empujar los parámetros (lo que hago actualmente)
Funciona, es genial. Pero no es lo más sencillo. También, mañana, imagino una opción donde el usuario elija: « sí, quiero usar la nube original » o « no, dejar todo en Gladys ». Y tener, por lo tanto, una interfaz de configuración por terminal un poco más avanzada eventualmente.
Para una V1, podemos conformarnos con el modo de funcionamiento actual. Pero tener una capacidad de gestión un poco más avanzada de las configuraciones por dispositivo (configuración gestionada en el lado del plugin que proporciona la funcionalidad) me parece que podría desbloquear nuevos escenarios.
Para poder avanzar en la integración externa OCPP, ahora necesitaría el merge de la PR que introduce la noción de categoría CHARGING_STATION y los tipos asociados. ¿Qué falta de tu lado para avanzar en esta PR?
@pierre-gilles Hay un error en la parte de integración externa cuando se usa el modo de selección de dispositivos. La validación no funciona. Este código no tiene en cuenta correctamente los dispositivos, utiliza sistemáticamente un array vacío y evita el uso real de la opción propuesta aquí (no había probado la actualización en mi interfaz):
// externalIntegration.validateConfigValue.js:36-41
case 'select': {
const validValues = (field.options || []).map((option) => option.value);
if (!validValues.includes(value)) {
throw new Error422(`config.${key}: must be one of ${validValues.join(', ')}`);
Un nuevo retorno, sería interesante poder decir si sí o no realmente queremos mostrar este botón o no (hoy se muestra automáticamente si he definido un puerto):
Sin embargo, en mi caso, el botón tal cual no tiene sentido. Lo que me interesaría, en cambio, es poder personalizar el mensaje de arriba para acceder a la URL de Gladys en esta pantalla. ¿Podría el SDK exponer el « getHost() »?
Por cierto, un pequeño defecto de visualización del selector aquí:
Actualmente tengo una wallbox Tesla gen3, estoy viendo qué protocolo utiliza porque por ahora recupero la información a través de HA (sin control), y si finalmente pruebo tu integración.
También estoy mirando para cambiarla y tener esta de DEPOW compatible con OCPP (¡y veo que su precio ha bajado 200€ recientemente!).
¡Me encanta meterme directamente en la complejidad con una gestión de múltiples conectores!
Me expresé mal en mi publicación anterior: aún no he hecho pública la v1, falta una actualización de Gladys.
Mi mayor « preocupación sobre el tema »: es la falta de diversas pruebas. Tengo un cargador Autel en casa. Con un solo conector. Teóricamente, el código contempla múltiples conectores. Pero no lo he probado. Tampoco he podido probar el ocpp2.0.1 en una situación real. Mi cargador está en 1.6 (hay una opción 2.0, tengo que ver si funciona).
Por lo tanto, estoy abierto a otros probadores.
Si tienes una instancia de Gladys en funcionamiento en master y no tienes miedo… ¡Me interesa!
Antes de lanzarse de cabeza con el Tesla, me interesan capturas de pantalla para ver lo que puedes configurar (es la parte de ajustes la que me interesa y la noción de servidor ocpp o csms). Si tienes eso a mano, me interesa.
Para el Gen3 está muerto en OCPP, Claude me ha comentado algo al respecto
Buena noticia y mala noticia: efectivamente se pueden obtener muchos datos del Gen 3, pero nada en OCPP, y el control sigue siendo muy limitado. Aquí tienes los detalles.
1. OCPP en el Wall Connector Gen 3: no soportado
Contrario a lo que se podría esperar, solo el Tesla Universal Wall Connector (solo en EE.UU.) soporta OCPP; los Gen 3 y Gen 3 MID no lo soportan y no pueden conectarse a un servidor OCPP. Esto ha sido confirmado por varias plataformas de terceros que gestionan la integración OCPP (Plugchoice, Charge HQ): Charge HQ señala explícitamente que ningún cargador mural (ni móvil) de Tesla soporta actualmente OCPP. PlugchoiceChargeHQ
Hay rumores en la comunidad (especialmente alrededor de la app Monta) que afirman poder conectar un Gen 3 en OCPP, pero son soluciones no oficiales y no fiables — la posición documentada sigue siendo « no soportado » para el Gen 3. Por lo tanto, el protocolo OCPP debe descartarse para tu cargador.
2. ¿Cómo recupera Home Assistant la información entonces?
No a través de OCPP en absoluto: el cargador expone localmente, en tu red Wi-Fi, una API HTTP REST no documentada oficialmente (reverse-engineered por la comunidad desde 2020). Responde sin autenticación a endpoints como http://<IP_del_cargador>/api/1/vitals, /api/1/wifi_status, /api/1/lifetime y /api/1/version. Tesla Motors Club
El endpoint /api/1/vitals es el más completo: tensiones y corrientes por fase, potencia, temperaturas internas, estado de carga, datos de la sesión en curso, etc., accesible fácilmente a través de un navegador o curl y devolviendo un objeto JSON completo. Tesla Motors Club
La integración oficial « Tesla Wall Connector » de Home Assistant Core se basa exactamente en esto:
disponible desde HA 2021.12, descubrimiento automático posible a través de la red local, expone entidades como la energía total y la energía de la sesión de carga en curso. Home Assistant
Su « IoT class » es « Local Polling » — por lo tanto, no hay dependencia de la nube de Tesla, todo se hace interrogando la IP local del cargador a intervalos regulares. Home Assistant
Técnicamente, se basa en una pequeña librería Python dedicada, « tesla-wall-connector », diseñada para el consumo local y la integración con Home Assistant, que expone una API asíncrona alrededor de estos mismos endpoints.
De hecho, puedes probar esto tú mismo sin instalar nada: encuentra la IP local de tu cargador (enrutador, o nombre de host tipo TeslaWallConnector_XXXXXX.localdomain) y abre http://IP/api/1/vitals en un navegador.
3. ¿Y el control (inicio/parada, amperaje)?
Aquí es no — esta API local es estrictamente de solo lectura.
Por ahora no puedo probar nada, pero estoy siguiendo el tema de cerca
Gracias, estos comentarios son muy útiles, los tomaré en orden.
El botón « Open »: tienes razón, es un punto ciego. Este enlace se pensó para el caso de Frigate, donde un puerto publicado = una interfaz web para abrir. Tu caso es el primero en el que el puerto publicado es un endpoint para máquinas (tus terminales) y no para un navegador, y por lo tanto el botón envía al usuario a una página de error. La respuesta correcta es una bandera en la declaración del puerto en el manifiesto, para decir « este puerto no es navegable, no mostrar enlace ». Es un pequeño cambio aditivo, lo voy a añadir a la especificación y luego implementarlo.
El getHost(): la necesidad es clara y quiero cubrirla, pero no en esta forma, y te explico por qué. Tu contenedor no puede conocer la dirección de Gladys tal como la terminal la ve en la LAN. Del lado del servidor solo se puede resolver la vista desde el contenedor (la gateway del bridge, el alias interno…), y Gladys mismo no conoce de manera confiable su propia IP LAN (multi-interfaces, reverse proxy, VPN…). Un getHost() en el SDK devolvería a menudo un valor falso, y prefiero no tener una API que una API que mienta.
El que conoce la dirección correcta es el navegador del usuario, que está en la LAN. De hecho, ya es así como se construye el enlace « Open ». La pista que retomo es la de placeholders en los textos declarativos del manifiesto, resueltos por el front al mostrar: un bloque section que contiene, por ejemplo, {{gladys_host}} y {{port:ocpp}}, y el usuario ve una URL completa y copiable del tipo ws://192.168.1.50:32768. Esto resolvería de paso el primer paso de tu proceso de 4 pasos: seguirá siendo manual, pero se volverá guiado. Única limitación, asumida y ya verdadera para el enlace « Open »: si el usuario navega a través de un túnel Gladys Plus o un reverse proxy, el hostname mostrado no será la IP LAN.
El error de visualización del selector: bien visto, ¡lo reviso!
La V1 está publicada.
Está limitada en sus capacidades: solo puede leer datos por el momento, y en la versión 1.6 de OCPP (el único equipo que tengo a mi disposición para las pruebas).
Probado solo en un tipo de cargador (un Autel Charge).
Me pondré a trabajar en la versión 2.0.1 del protocolo en un segundo momento (finales de agosto)
En cuanto a las acciones… habrá que ver, depende quizás de los cargadores. También probaremos abordarlo.
Estoy abierto a cualquier tipo de prueba adicional.
¡Hola @Sescandell y gracias por tu trabajo en esta integración!
También tengo una estación de carga Autel en casa y he intentado conectarla, pero sin éxito. Cuando añado la dirección de Gladys, sigue los tres pasos de la configuración y se bloquea en el último durante la prueba de conexión. Tampoco encuentro la estación de carga en la pestaña « Descubrimiento » durante y después de la configuración de la nube de esta.
¿Tendrías más información sobre el proceso de añadirla?
El ID de mi terminal para mí es del formato AEXXXXXXXXXXXXXXXX donde XXXXXXXXXXXXXXXX son números y letras (lo he recuperado de las configuraciones al lado).
¿Cuál es tu contexto de red? ¿Estás seguro de que el puerto es accesible en tu red desde otra máquina? Especialmente si tienes un FW en la máquina que ejecuta Gladys, hay que asegurarse de que el puerto en cuestión esté abierto.
El « problema » debe estar ahí: no debes poner una URL más.gladysassistant.com, sino la IP de tu caja Gladys en tu red local. Normalmente, tu router y tu caja domótica están en la misma red local.
¿Es así?
meterme directamente en la complejidad con una gestión de múltiples conectores!
