¿Estás seguro de que has instalado la integración con el manifiesto correcto para el botón « Forzar la actualización »?
¿Has copiado el manifiesto del build?
Sí, en este caso, seguro al 100%.
La única vez que el manifiesto cambió, en este caso, me pareció lógico y por instinto lo eliminé y lo recreé. De hecho, si es posible en desarrollo, poder modificar el manifiesto directamente desde la integración o mejor aún que lo verifique/recargue solo sería aún mejor (especialmente para los probadores), pero aquí solo planteo la cuestión de la viabilidad ^^
Y en este caso:
-
Si no hay imagen de producción (Tuya), la actualización de desarrollo crea un error:
-
Si una imagen de producción está activa (Zendure), la actualización del contenedor carga la imagen de producción y sobrescribe el desarrollo (molesto ^^) => Ver la versión de la imagen de Docker a continuación después de hacer clic en actualizar vs la dirección
http://10.5.0.227:1444/dashboard/integration/device/external/ext-dev-zendure-2/configque indica que estaba en la imagen de desarrollo
=> la dirección de producción eshttp://10.5.0.227:1444/dashboard/integration/device/external/ext-terdious-gladys-zendure/config
Ay ^^ 
Concretamente, todos los fabricantes de baterías para el gran público (Anker, Zendure, EcoFlow, Marstek, Bluetti…) ofrecen:
- baterías solares (con entradas PV),
- baterías simples (sin entrada PV).
Por lo tanto, la categoría no es específica de Zendure (el nombre en el título es solo la integración que originó la necesidad) — al contrario, la hacemos reutilizable para todas las baterías de almacenamiento. La PR se centró en las baterías solares, pero podemos cubrir los dos casos.
Y efectivamente, los comentarios de GPT5.6.
Actualizo la PR en este sentido.
Para información:
Nombres genéricos (ningún término Zendure), alineados con VE/Gladys.
Estado de carga
| Tipo | Sentido | Unidad |
|---|---|---|
battery-level |
Estado de carga | percent |
Potencias (instantáneas, ≥ 0)
| Tipo | Sentido | Unidad |
|---|---|---|
charge-power |
Potencia que entra en la batería | watt / kilowatt |
discharge-power |
Potencia que sale de la batería | watt / kilowatt |
solar-input-power |
Entrada PV | watt / kilowatt |
output-power |
Total hacia la casa (PV directo + descarga) | watt / kilowatt |
grid-power |
Importación de la red | watt / kilowatt |
off-grid-power |
Salida fuera de la red (respaldo) | watt / kilowatt |
Energías (contadores acumulados) + estado
| Tipo | Sentido | Unidad |
|---|---|---|
charge-energy |
Energía total cargada | kilowatt-hour |
discharge-energy |
Energía total descargada | kilowatt-hour |
solar-energy |
Energía solar total | kilowatt-hour |
output-energy |
Energía total suministrada a la casa | kilowatt-hour |
grid-energy |
Energía total importada | kilowatt-hour |
off-grid-energy |
Energía total salida fuera de la red | kilowatt-hour |
available-energy |
Energía disponible actual (instantánea) | kilowatt-hour |
→ UNITS_BY_CATEGORY['battery-storage'] = [PERCENT, WATT, KILOWATT, WATT_HOUR, KILOWATT_HOUR], por defecto por tipo : percent (level), watt (potencias), kilowatt-hour (energías) — lo que resuelve el punto de caída del revisor. Y categoría añadida a isSensorCategory.
- Almacén de integración actualizado con el nuevo formato de manifiesto, por lo que puedes proceder @Terdious si quieres publicar Tuya o Zendure
- SDK actualizado a v0.5.0 ( listas de cambios )
- Plantilla JS actualizada con el SDK v0.5.0
- Gladys actualizada en #2665 con todas las últimas novedades, y una corrección para el botón « Forzar la actualización »
No dudes en preguntar si tienes alguna pregunta
Pequeña novedad para evitar tener que esperar 1 hora entre cada paso de la tienda de integración, he creado una pequeña herramienta npx para validar localmente (o dejar que su agente de IA valide) que una integración pase bien las reglas de validación:
npx github:GladysAssistant/integration-store
Para leer en el README de la tienda.
Actualizo la plantilla JS
@Terdious, ¿te falta algo más para las integraciones de Zendure, Tuya, Netatmo, Shelly u otras?
Mi objetivo es lanzar una primera versión V1 la próxima semana. La idea no es cubrir todos los casos desde el principio, sino tener una base sólida sobre la que podamos iterar. ¡Sería genial si ya pudiéramos ofrecer algunas integraciones en ese momento! 
« Nosotros » pensamos que sí !! Al menos para las v1 sin duda ^^ ¡Muchas gracias !!
¡Obviamente soy consciente de ello, de todos modos sería imposible determinar todas las necesidades actuales y futuras sin iterar sobre ellas ^^ !
Creo que para una V1 todo lo que ya se ha propuesto es suficiente. ¡La prueba es que hago que casi todo funcione !!
Escucha, estoy en SDK 0.5.0, ¡y funciona !!^^
Bueno, ha hecho muchas modificaciones desde entonces, así que parto del principio de que era de nuestro lado. UDP funciona en 6 dispositivos de 10 y los demás tendremos que añadirlos manualmente. Y ya era así en la integración de Tuya Core, así que ¡estamos bien !!
Editar: Bueno, eso era yo, ahora le dejo la palabra a Claude 
Es inteligente, eso vuelve a dar trabajo 
:
SÍ, he leído el SDK 0.5.0 en su totalidad (a través de tu fork, en mi ámbito) — y es enorme: PG ha industrializado casi todo lo que habíamos dicho. Tres cambios de juego que afectan directamente a nuestra hoja de ruta:
| Novedad SDK 0.5.0 | Qué hace | Resuelve |
|---|---|---|
publishTransports() + DEVICE_TRANSPORTS + manifest transports:["local","cloud"] |
Insignia local/nube/inaccesible por dispositivo (pegatina) renderizada por el núcleo; y cuando los dos canales están declarados, el núcleo muestra un interruptor estándar « Preferir local » proporcionado como clave reservada GLADYS_PREFER_LOCAL |
#8 + nuestro punto 3 (nuestro local_mode personalizado se convierte en estándar) — ¡es exactamente lo que argumentamos a PG |
publishDiscoveredDevices ahora hace un UPSERT de los parámetros de un dispositivo ya creado (IP DHCP que cambia, nube→local…) sin tocar el nombre/funciones; un cambio de estructura muestra el botón « Actualizar » |
Ya no es necesario eliminar/recréar | C (la falta de « actualizar parámetros ») + el churn DHCP |
Manifest actions + onAction(key, cb) con el ejemplo detect_protocol (IP ingresada manualmente → detección de protocolo, timeout_seconds hasta 120 s) |
Botón de acción con resultado mostrado | #7 (dispositivos no vistos por UDP: IP manual + detección) |
Bonus también disponible: onGetImage/publishCameraImage (cámaras/timbres), OAuth2 (onOAuthAuthorizeUrl/onOAuthCallback, estilo Netatmo), sub-contenedores (getContainers/startContainer + onHardwareUpdated), setConnectionStatus (estado de conexión de la aplicación).
Qué implica esto para nosotros (grande pero en el buen sentido)
Deberíamos migrar al modelo estándar :
- reemplazar nuestra configuración
local_modepersonalizada portransports:["local","cloud"]+ lectura deGLADYS_PREFER_LOCAL(mi modelo « toggle live » de antes se conecta directamente a esto); - llamar a
publishTransportsen cada encuesta para mostrar la insignia local/nube/inaccesible (y nuestro circuito de protección →inaccesible); - añadir la acción
detect_protocolpara los dispositivos no escaneados; - aprovechar el upsert de parámetros: nuestro re-escaneo en el toggle ahora actualiza realmente los dispositivos existentes (incluida la IP) → podremos eliminar el contorno
resolveDevice/mergeParams a largo plazo.
PERO esto depende de lo que la rama principal que estás ejecutando implemente realmente (transports, GLADYS_PREFER_LOCAL, onAction, upsert). Antes de migrar, quiero leer tu núcleo.
¡Excelente! 
Me encantaría conocer tus comentarios sobre Netatmo y Frigate después
Netatmo debería estar cubierto, hay toda una gestión de OAuth.
Frigate también está gestionado con una gestión de subcontenedores.
@ProtZ ¿Crees que la integración de Nuki podría convertirse en una integración externa?
@cicoub13 ¡Lo mismo para TP-Link!
@bertrandda ¡A ver qué hacemos con Airplay y Google Cast!
Si alguien quiere probar las integraciones externas, aquí hay un build de Docker (solo amd64):
ghcr.io/gladysassistant/gladys-preview:claude-magical-turing-qhh7q2
La imagen se actualiza automáticamente con todos los desarrollos que hago
¡La documentación está actualizada!
En francés:
En inglés:
¡Bravo por todo el trabajo realizado en esta arquitectura que va a desbloquear muchos mundos!
Hay solo un detalle que me molesta 
Antes, una integración desarrollada por alguien era integrada en Gladys y otros desarrolladores o tú @pierre-gilles podían venir a hacer un fix o una evolución si el desarrollador principal no tenía tiempo o ya no respondía.
En el futuro, con estas integraciones externas, ¿qué pasa si una integración ya no se mantiene? ¿Se vuelve inutilizable? ¿Hay que hacer un fork y pedir a la gente que migre manualmente?
¿Y una pregunta de bonus? ¿Cómo se decide si una integración debe ser externa o interna?
Sí, en este caso se puede imaginar perfectamente un fork. Y si una integración se vuelve muy utilizada con una verdadera demanda de migración simplificada, podremos considerar un proceso de migración para acompañar a los usuarios.
La idea también es que la comunidad pueda retomar fácilmente una integración abandonada: como todo está abierto y desacoplado del núcleo, el mantenimiento ya no depende únicamente de mí.
Aparte de las integraciones realmente « universales » (Matter, Zigbee, MQTT…), para mí, casi todo lo que puede ser externo debería serlo.
Lo que más me sorprende de este nuevo sistema es lo idéntica que es la experiencia del usuario a una integración nativa. Con Fable 5, hemos logrado crear una experiencia en la que, desde el punto de vista del usuario, apenas hay diferencia entre una integración interna y una integración externa.
En cambio, para el proyecto, la diferencia es enorme: las contribuciones pueden hacerse en paralelo sin requerir mi tiempo, y la experiencia está estandarizada entre las integraciones.
Honestamente, no me sorprendería que llegáramos a cientos de integraciones en los próximos meses gracias a este enfoque.
Vale, gracias por las respuestas.
Tengo un poco de miedo por la calidad de las integraciones externas y, en consecuencia, por la experiencia del usuario con Gladys. Una de las fortalezas de Gladys es su estabilidad.
Aunque la instalación se realice apuntando a un repositorio externo (y los contenedores Docker estén blindados para no afectar a la instancia de Gladys), los usuarios llegarán aquí diciendo que Gladys no funciona.
HA ha implementado un sistema de calificación de integraciones para guiar a los usuarios sobre su calidad. ¿Vamos hacia eso también?
Es una preocupación legítima, y habrá que estar efectivamente vigilante al respecto. Pero hoy tenemos más bien el problema contrario: la falta de integraciones 
Desde el inicio de la v4, probablemente este es el reproche número 1 que se repite: muchos usuarios quieren usar Gladys, pero sus dispositivos simplemente no son compatibles.
A largo plazo, si logramos tener cientos de integraciones externas, creo que habrá que implementar mecanismos para ayudar a los usuarios a hacer su elección: calificaciones, comentarios, indicador de mantenimiento, número de usuarios, última versión publicada, etc.
Pero no pongamos el carro delante de los bueyes 
La prioridad hoy es tener un ecosistema de integraciones mucho más amplio. Luego podremos construir las herramientas necesarias para mantener una buena calidad global.
Vale, he avanzado en las integraciones de tipo « Comunicación » (ej: Telegram), y está disponible en el SDK v0.6.0.
Acabo de migrar la integración de Telegram con Fable de una sola vez, y funciona perfectamente.
Incluso me parece que la experiencia es mejor que con la integración que tenemos en Gladys
El repositorio de Github:
¿Es posible tener un build para arm v8?