Hola,
Para información y para evitar duplicados, tendré que lanzar mañana a Claude en una integración Daikin 
El video sobre el desarrollo de una integración externa me ha dado muchas ganas de lanzarme 
También puede que necesite probadores 
Os mantendré informados 
Está desarrollado y disponible solo para pruebas por el momento:
Sin embargo, voy a esperar la próxima versión para la salida de este PR para probar la autenticación:
@pierre-gilles ¿Tienes idea de cuándo saldrá la próxima versión con la página de redirección?
Gracias
Voy a intentarlo esta noche 
Ya está en vivo en la 4.84.4:
Gracias
OAuth2 funciona bien y he podido hacer pruebas
Quedan algunos errores en proceso de corrección, pero espero el próximo reinicio de Claude para continuar He usado todos mis tokens 
Debería poder sacar una versión estable mañana
La integración está lista
Debería estar disponible en aproximadamente 1 hora para todos
Para mi información personal, ¿cuáles son los aparatos Daikin que serían compatibles con esta integración?
Los aires acondicionados serán compatibles
¿Qué aparato Daikin tienes?
Puedes ver el readme aquí:
actualmente ninguno ahah
pero seguramente pronto ^^
Atención, aquí solo tratamos los aires acondicionados conectados a la nube de Daikin y que usan la aplicación Onecta
Está disponible
Pequeña corrección porque los valores no se actualizaban después de la primera conexión a la nube:
En una primera instalación, el orden es: el contenedor se conecta a Gladys antes de que exista la cuenta Daikin. El controlador connected (index.js:241) detecta !api.isConnected, muestra «ninguna cuenta vinculada» y retorna — nunca llega al paso 4, startPolling().
Luego, el usuario realiza el OAuth: onOAuthCallback realizaba una lectura única (refreshAndPublish) para poblar la pantalla de Descubrimiento… y nada más. Por lo tanto, el temporizador nunca se activaba. Las únicas formas de iniciarlo eran un reinicio del contenedor o un cambio del intervalo en la configuración (único caso en el que onConfigUpdated llamaba a startPolling()).
De ahí el síntoma exacto: primeros valores correctos, luego ningún refresco cada 900 s.
Versión 1.0.7 disponible
¡Super integración y gracias! Tengo un comentario. Me parece que tu logo/icono es demasiado genérico. Añadiré la marca o el protocolo encima. Será más explícito.
Disponible en la próxima versión que debería estar disponible en la próxima hora:
https://github.com/prohand/gladys-daikin-cloud/blob/main/cover.png
Asegúrate de vaciar tu caché si no ves la imagen correcta después de la actualización
Quería tener su opinión sobre una funcionalidad que comencé a desarrollar con claude, pero que implica una contrapartida en el seguimiento de la energía.
En resumen, vi que en la parte de seguimiento de la energía apareció esto:
Esto también estaba al nivel 0 al principio, pero lo entenderán mejor un poco más tarde 
Me dije que íbamos a explotar la parte de seguimiento de la energía de Gladys con estas informaciones que suben a Gladys:
Le pedí que creara dos funcionalidades que son « Consumo 30 minutos » y « Costo 30 minutos »
Y después de probarlo en el día 08/08, el valor de consumo corresponde exactamente a lo que tengo en la aplicación Daikin (Igual para el 09/09):
El pequeño problema es que en el seguimiento de la energía tenemos « Energía este mes » y « Energía este año » que se queda en el nivel 0 de la integración como indica la documentación aquí:
En resumen, se parece a esto:
Para mí, puedo empujar esta versión a producción con el consumo y el costo de 30 minutos, o hay cosas que revisar?
Gracias
Hola @prohand, excelente trabajo, he revisado el código de la rama y el resultado es coherente con lo que hace el núcleo. Puedes empujar, la mecánica es buena. Tres puntos, sin embargo, dos de los cuales merecen una corrección antes o justo después de la puesta en producción.
1. El padre es un contador que se reinicia, no un índice
Publicas « Energía hoy » en energy-sensor / energy, que Gladys documenta como « el consumo de energía acumulado » y trata como un índice. El trabajo calculateConsumptionFromIndex hace index(t) − index(t−1) y descarta los deltas negativos (« reinicio de contador detectado »). Por lo tanto, nada se cuenta dos veces — es por eso que tu total diario es exacto — pero todo lo que se consume entre la última encuesta antes de medianoche y la primera encuesta después se pierde, cada noche. Con 900 s de encuesta, eso es el último cuarto de hora del día; y si Daikin no llena su cubo 22h–24h hasta después de medianoche, son dos horas las que desaparecen.
La corrección adecuada: que la integración mantenga su propio acumulado (en su almacén, total += max(0, today − today_anterior)) y publique un verdadero energy-sensor / index monotónico. El núcleo deriva entonces exactamente, y el caso de medianoche desaparece.
2. Los cubos de 2 h distorsionan el costo en HP/HC y Tempo
Daikin solo expone 12 intervalos de 2 h. Tu serie de 30 minutos se parecerá entonces a 0, 0, 0, 1.8 kWh, 0, 0, 0, …. El total del día es correcto (de ahí la correspondencia con la aplicación Onecta), pero la distribución durante el día no lo es. Ahora bien, calculateCostFrom tarifica cada ventana de 30 min al precio de esa ventana: en un contrato Base no tiene consecuencias, en horas punta/valle o Tempo el costo puede ser francamente falso, según la hora en que cayó la encuesta.
Dos opciones: documentarlo claramente (« costo fiable en Base, indicativo en HP/HC »), o mejor — saveStates acepta un created_at, por lo que puedes publicar los estados del índice con fecha en los límites de los cubos Daikin en lugar de la hora de la encuesta. El consumo cae entonces en las medias horas correctas.
3. Derivar tú mismo los UUID es mi problema, no el tuyo
Elegir los id de las características para poder apuntar energy_parent_id antes de que existan las líneas, funciona (el device.create inserta las características y luego resuelve los enlaces en una segunda pasada), y tu salvaguardia — nombrar solo las características que Gladys no conoce aún — es la correcta. Pero publicar un id en el payload de descubrimiento no está en la especificación de las integraciones externas: pasa hoy porque nada lo valida, y no quiero que se convierta en un contrato implícito.
Por lo tanto, voy a cablear addEnergyFeatures() (el de Zigbee2mqtt/Tasmota) en las integraciones externas, en getDiscoveredDevices: toda integración que publique un índice tendrá el par de 30 min automáticamente, ids y enlaces gestionados por el núcleo. Mantén tu código bien aislado (featureUuid.js + el bloque en buildDevice) para poder retirarlo de un bloque cuando esté disponible.
La solicitud:
Y dos detalles:
energy de tu escala de capacidades no sirve de nada: energy_parent_id llegó a Gladys en agosto de 2025, mucho antes de las integraciones externas. Toda instancia capaz de ejecutar tu contenedor ya tiene el seguimiento de energía.energy, por lo que aparecen como padres posibles en Configuración → Seguimiento de energía, y un usuario que las cablee contaría los mismos kWh varias veces. Una línea en la documentación para decir « solo conecten el consumo del día » evitará la pregunta.En resumen: adelante para la producción, y yo me encargo del punto 3 en el núcleo.
Vale, gracias por la revisión tan detallada y por el punto 3 que te encargas
Reenvío el tema a Claude el miércoles por la noche
Veo si hago una puesta en producción antes
Lanzamiento de la 1.0.10 con el seguimiento de la energía Gladys
Os invito a ver la documentación directamente para la implementación
Acabo de descubrir este sitio faikin:
Promete un control daikin 100% local
Algo aún más divertido, menciona a gladys como compatible (lógico ya que usan mqtt)
