Descripción de la función
Tras mi compra de un termostato conectado, me he dado cuenta de que Gladys aún no admite la gestión nativa del calefacción:
Votad todos hoy para que esto sea así antes de que termine el invierno 
De lo que he entendido, los votos no cambiarán nada mientras no haya nadie disponible o ningún desarrollador equipado, y esto a pesar del número de votantes.
Cf :
https://community.gladysassistant.com/t/ajout-enceinte-sonos/5504/5?u=spenceur
Quizás podamos hablar de esto en otro lugar, pero si los votos tienen un gran interés: esto le da a la comunidad una indicación de lo que se solicita/no se solicita.
Personalmente, cuando desarrollo una nueva funcionalidad, tomo la lista de funcionalidades relacionadas con el núcleo, las ordeno por votos y desarrollo la más solicitada. No es una regla de oro, por supuesto, a veces también desarrollo funcionalidades poco solicitadas que considero importantes según mi criterio.
En cualquier caso, históricamente en el último año, he desarrollado las 30 funcionalidades más solicitadas (ver archivo: Demandes livrées - Gladys Assistant community)
En el caso de las integraciones, ya te respondí @spenceur en otro tema.
Además, quizás la línea entre el desarrollo del núcleo y el desarrollo de integración es delgada, pero este problema (gestión de calefacción nativa) está claramente relacionado con el desarrollo del núcleo, ¡no es una integración!
No se necesita hardware para esta solicitud de función.
Por lo demás, @lmilcent si quieres que este problema avance, el 90% del trabajo aquí es la especificación funcional.
Creo que ya tienes experiencia, lo hago en cada solicitud de funcionalidad, pero habrá que hacer:
- Estudio de las diferentes soluciones de calefacción (vamos a hacer un desarrollo que será el mismo independientemente de las integraciones, no solo Zigbee)
- Las especificaciones funcionales: ¿qué queremos?
- Los bocetos: ¿a qué se parecerá?
- Finalmente, el desarrollo
En resumen, escribir código será el último 10%.
Si no te sientes capaz de hacer todo esto, a menos que alguien más se ponga a ello, personalmente hay docenas de otras solicitudes más votadas que esta, por lo que es probable que tarde en llegar a esta función 
(¿Varios años? 
)
Edición: Ejemplo de especificación/bocetos: Multi-utilisateurs - #6 par pierre-gilles
Hace unos dos años compré dos cabezales termostáticos enocean y uno está guardado en un cajón, y el otro está instalado pero se usa en modo desconectado. Siempre he tenido en mente tener un sistema de gestión de calefacción completo bajo Gladys.
No me importaría dedicarme a desarrollarlo, pero las especificaciones que tengo en mente son bastante completas/complejas. Sabiendo que actualmente tengo muchas dificultades para dedicar (mucho) tiempo. Tengo miedo de pasar otro invierno con mi antiguo sistema ^^
Como dice @pierre-gilles, ya estoy disponible para discutir estas especificaciones.
Por mi parte, en general, ya veía un sistema de « Declaración de su calefacción ».
-
Es decir, una conexión entre los equipos termostáticos, las válvulas del radiador o la válvula central (pienso en mi caso) con sensores de temperatura.
-
Cada válvula está acoplada con su/sus sensores.
-
Un sistema de consignas para cada par de válvula/sensor.
-
Un exceso del umbral en un sensor conectado a una válvula activaría la demanda en la válvula o la detendría.
-
Por supuesto, la gestión visual de un horario.
-
Sin olvidar un posible acoplamiento de las válvulas con los sensores de ventanas, si se abre una puerta/ventana en la habitación donde hay una válvula, se detiene para no calentar en vano.
-
De la misma manera, si la casa está vacía, se puede decidir apagar la calefacción, con un retraso… a ver… o bien iniciar a distancia cuando un usuario llega o lo decide…
Gracias por sus respuestas. Como @Jean-Philippe, siempre tengo dificultades para encontrar tiempo mental en este momento, pero eso no me impide empezar algo. Entre todos, lograremos hacer un rendimiento completo para facilitar el desarrollo.
Es cierto que no había identificado que se trataba principalmente de especificaciones, pero eso permite luego desarrollar fácilmente.
Mientras tanto, @Jean-Philippe, creo que hay node-red, que puede permitir hacer bricolaje hasta que sea compatible. No lo he probado todavía, no sabría decir si funciona 
Así que, seguiremos en contacto, empezaré una versión de trabajo tan pronto como pueda. No duden en proponer también información, completar, revisar, dar sus escenarios, etc.
Especificación funcional
Como usuario de Gladys, quiero poder controlar mi calefacción. Para ello, veo algunas posibilidades:
- Mediante un calendario, o programación estática
- Mediante un calendario con prioridad a los sensores
- Manualmente, mediante una especie de termostato o control central
- Automáticamente, con la ayuda de otros sensores
1. Mediante un calendario
Una interfaz tipo « calendario » en una semana, permite elegir de qué hora a qué hora la calefacción está encendida o apagada, con un ajuste de calefacción adicional.
Ejemplo:
- Lunes: 21°C de 7h a 9h, apagado de 9h a 17h, 19°C de 17h a 21h, 17°C de 21h a 7h.
- Martes: etc. hasta el domingo
2. Mediante un calendario con prioridad a los sensores
La interfaz de calendario siempre está activa, pero si una escena modifica las temperaturas de ajuste, entonces es ella la que tendrá prioridad. Tan pronto como se retire esta temperatura de ajuste o se apague la calefacción, es el calendario el que vuelve a tomar el control.
Ejemplo:
- El calendario calienta todos los días entre las 6h y las 9h y entre las 16h y las 21h. Durante el día, la calefacción está apagada.
- Una escena detecta mi presencia a las 9h (#teletrabajo) y activa la calefacción aumentando la temperatura de ajuste. A pesar de la desactivación prevista en el calendario, es la escena la que mantiene el control de la calefacción.
- A las 17h, la escena desactiva la calefacción y envía una señal a Gladys para « ceder el control » y dejar que el calendario siga su curso.
3. Manualmente
Un termostato en el panel de control permite controlar la temperatura de calefacción por habitación. No hay automatización aquí, es el usuario quien elige a través de Gladys cómo quiere calentar sus diferentes habitaciones.
Si se añade un termostato físico a Gladys, puede utilizarse vinculado o en lugar del mostrado en el panel de control. Siempre tendrá prioridad el termostato físico.
Si el calendario de gestión de la calefacción está en uso, pero el usuario modifica el termostato a través del panel de control, entonces es él quien tiene el control. Un pequeño mensaje de advertencia (en modo información) podrá recordar que el calendario (o una escena) estaba gestionando la temperatura de ajuste.
4. Automáticamente (WIP)
¿Cuál es la mejor solución para utilizar sensores exteriores de manera práctica y no a través de 25.000 escenas, un poco de calendario, etc.?
TODO
Un enlace entre los equipos termostáticos, las válvulas del radiador o la válvula central (pienso en mi caso) con sensores de temperatura.
Cada válvula está acoplada con su/sus sensores.
Un sistema de ajustes para cada par de válvula/sensor.
Un exceso del umbral en un sensor conectado a una válvula activaría la solicitud en la válvula o la detendría.
Por supuesto, la gestión visual de un horario.
Sin olvidar un posible acoplamiento de las válvulas con los sensores de ventanas, si se abre una puerta/ventana en la habitación donde hay una válvula, se detiene para no calentar en vano.
De la misma manera, si la casa está vacía, se puede decidir apagar la calefacción, con un retraso… …a ver… o bien iniciarla a distancia cuando un usuario llega o lo decide…
¡Excelente descripción!
Si me lo permites, me gustaría ver también la posibilidad de suspender el uso de la programación a más largo plazo (no calentar durante el verano aunque tengamos un « frío repentino ») y una reactivación programada (estoy de viaje/vacaciones toda la semana, pero reactivo la programación del calefacción el viernes a las 15h).
… Y una funcionalidad práctica también es « calentar durante X horas más » y a la inversa « no calentar durante X horas » porque « tengo invitados que se van a quedar, pero puedo olvidar apagar la calefacción al irme a dormir » (o no saber cómo se hace) y « tarde de compras, no hace falta calentar durante 2 horas » (reales, sentidas 8h).
Hola @lmilcent,
Es muy interesante, pero, como dice @pierre-gilles, tiene que funcionar sin importar la integración.
Por mi parte, tengo módulos Z-wave Qubino ZMNHJD1 para la calefacción por suelo radiante, el toallero calefactable y otros, aún no instalados, para los convectores. También tengo radiadores de inercia programables que se integrarán en Gladys si el Z-wave se vuelve funcional.
Todo lo que se utiliza funciona con Domoticz desde hace varios años.
El hecho de que no pueda gestionar la calefacción es LA razón por la que no paso a Gladys Plus…
Gracias por tu respuesta @gaetanb76, en efecto, aún queda trabajo por hacer para completar esta descripción y tener en cuenta la mayoría de los casos de uso.
Por mi parte, mientras tanto, he comprado cabezales conectados Zigbee, que controlo con Zigbee2MQTT y Node-Red. Me he encontrado con muchas dificultades y he pasado mucho tiempo en ello, actualizaré mi mensaje principal para modificarlo en función de mi experiencia posterior
Acabo de empezar a integrar mis válvulas https://ubiwizz.com/l-offre-produits-ubiwizz/9636-vanne-thermostatique-enocean.html en mi integración enOcean (no fusionada con Gladys por el momento).
Y en mi caso, pueden interfazarse nativamente con sensores de apertura de ventana y un sensor de temperatura externa si no se quiere usar el sensor interno.
En general, una gestión nativa del calefacción que gestione todos los casos sin errores, como indica @gaetanb76, puede resultar bastante compleja de escribir, pero creo que efectivamente sería un factor de adopción de Gladys, el calefacción en una casa es uno de los principales impulsores para la domótica.
Creo que una vez que pueda gestionar mis válvulas, haré algo estático y dejaré que mi caja gestione las consignas, hasta que también la domotice, pero sin prisa 
¡Genial, quería mirar el lado de EnOcean para mi domótica, especialmente por sus botones sin pilas!
Pero viendo el mastodonte Zigbee, me había decantado por el más soportado en todas partes.
¡Espero tu versión 1 en Gladys 
Hola, me permito volver a la carga porque, efectivamente, sería genial como integración. Así que se trata de definir la especificación funcional.
Para mí, la noción de calefacción debe ser específica de una habitación.
Hay dos tipos de calefacción:
- Los On/Off simples
- Las cabezas termostáticas
Cabeza termostática
En el caso de las cabezas termostáticas, tienen un sensor de temperatura y se encargan de alcanzar esta temperatura de la habitación. Solo hay que poder transmitirle este valor.
Creo que este es el caso de uso más simple y uno que ya cubre el 80% de las necesidades de todos los usuarios, creo.
La integración desde un calendario se puede hacer con escenas desde la 4.8
Se puede gestionar en función de las personas presentes en la casa, etc… En resumen, ya hay muchas cosas que se pueden hacer.
Para las cabezas termostáticas, queda poder modificar el valor de la temperatura desde el Dashboard. Para ello, veía un diseño parecido a esto:
Calefacción On/Off
La cuestión de la calefacción On/Off es más compleja.
Idealmente, sería posible crear un enlace entre un sensor de temperatura y el interruptor con encendido automático y apagado automático alrededor del valor objetivo.
Creo que el hecho de tener un valor objetivo se ajusta a la demanda de funcionalidad en Gladys de tener variables ficticias. Porque claramente sería el caso para este valor.
Esto permitiría transformar cualquier calefacción On/Off en una cabeza termostática y, por lo tanto, controlarla de la misma manera.
Ir más allá
- Introducir una noción de prioridad en las modificaciones,
- interruptor general on/off para toda la casa, para ciertas habitaciones, etc… (el uso de variables virtuales, con las que se interactúa en las escenas).
- Poder decir en una escena, apagar la calefacción de esta habitación en lugar de declarar una por una las calefacciones (igual, otra variable virtual).
¿He resumido bien las funcionalidades deseadas?
No me parece un trabajo enorme para la integración Core de las cabezas termostáticas, habrá un poco de trabajo en Zigbee2Mqtt y otras integraciones, creo.
Por otro lado, la integración de los On/Off me parece más complicada, especialmente si en algún momento no se puede recuperar la información del sensor de temperatura y la habitación se sobrecalienta…
No duden en hacer comentarios o reflexiones.
Gracias, está muy bien resumido. Después de mi experiencia este invierno, confirmo tu reflexión sobre las cabezas termostáticas y la posibilidad de acoplarlas con un sensor de temperatura externo a la cabeza. Fue una de las ideas que abandoné con NodeRed.
Hay que pensar en poder ajustar el valor de actualización (o verificación de la temperatura), porque no hay que hacerlo cada 10 segundos, sino cada 10 minutos, debido a la inercia.
Otro punto, la posibilidad de un ajuste manual en la cabeza o en Gladys que tenga prioridad sobre la programación.
Es el funcionamiento de nuestras cabezas Moes, llamado « temporary manual ». Toma tu nueva condición de temperatura hasta el próximo ciclo de programación.
Ejemplo: 18°C programado entre las 20h y las 6h. Si a las 21h pido a la cabeza conectada o a Gladys a través del panel de control (o Telegram) que pase a 21°C, se aplicará hasta las 6h.
Sí, después de ver, creo que hacer una lista de las funcionalidades, de la más importante a la menos importante, y ya estaremos contentos si podemos hacer las cosas básicas de eso, pero vamos a por las funcionalidades más avanzadas.
Por lo tanto, está la funcionalidad que acabas de describir, también está el hecho de poder encender/apagar la calefacción fácilmente porque pensé en un caso.
Si abro la ventana, entonces apago la calefacción. En estos casos, nos interesa no modificar el valor de la temperatura deseada para poder volver al modo normal fácilmente.
Vale, entonces vamos a avanzar, ya que parece que no hay mucha resistencia.
Primera necesidad: las cabezas termostáticas
Integraciones:
- En Zigbee2Mqtt corresponde a los topics:
occupied_heating_setpointocurrent_heating_setpointde los dispositivos - ¿Alguien tiene una cabeza termostática Z-Wave para que podamos entender cómo integrarla?
Después:
- Cada habitación puede tener un estado de calefacción encendida o apagada para evitar cambiar la temperatura y perder la temperatura que pudo haber sido decidida en una de las escenas.
(por ejemplo: todas las mañanas de 8 a 10 horas calienta a 20 grados. Si una ventana se abre, corta la calefacción. Cuando se cierra, pone la temperatura anterior (por lo tanto, enciende la calefacción)).
Esto se traduce en las escenas:
- Una acción para definir la temperatura de calefacción de una habitación y esto se refleja en las diferentes calefacciones de la habitación
- Una acción para encender/apagar la calefacción de una habitación
- Una condición: si la calefacción de una habitación no está encendida
En el panel de control:
- Un interruptor para la calefacción de la habitación
- Un contador para definir la temperatura deseada en la habitación.
Creo que estas son las 5 necesidades más fundamentales y a partir de ahí podemos empezar a construir algo cada vez más interesante. ¿Opiniones?
@lmilcent pequeña pregunta, ¿te ha pasado a menudo que añades un grado o dos manualmente en tu radiador?
En Gladys creo que esto se gestionaría naturalmente poniendo la temperatura a 18 grados, un usuario modifica directamente en la válvula, la próxima vez que haya una temperatura definida en las escenas, se vuelve a poner el valor definido en la escena. ¿Te parecería bien este modo de funcionamiento?
¡Sí, en casi todas mis habitaciones!
¡De momento no tengo nada que decir!
@pierre-gilles, ¿te basta este nivel de detalle para las especificaciones funcionales? ¿Quieres más detalles?
@jgcb00 tu último mensaje está muy bien, pero creo que una vez que están de acuerdo en todo, sería genial tener un mensaje « resumen » con la especificación completa en un mensaje de tamaño razonable, con la misma organización que hiciste está muy bien:
Dashbaord
…
Escenas
…
Integraciones
…
Por favor, piensen en eso, es algo sencillo, pero lo que hacen es la mayor parte del desarrollo Programar es solo el último metro, es técnica, es todo simple.