Escenas, scripts y plugins => Escenas Domóticas Fibaro => Mensaje iniciado por: linkey en Abril 08, 2016, 00:58:22 am
-
Un par de dispositivos virtuales que conforman un sistema de control virtual de la climatización basado en control por PID. Se pueden establecer tantas zonas y termostatos como queramos, basta con instalar más dispositivos virtuales y ubicarlos en diferentes habitaciones. El primero es un dispositivo de configuración que establece los parámetros de configuración del PID. El segundo es el propio termostato, cuyo objetivo es ayudar a optimizar el uso de nuestro sistema de climatización.
Bueno esto es el resumen, si os interesa controlar la calefacción sin necesidad de adquirir un termostato comercial, descargar el proyecto H2CLUA-TermostatoVirtual (https://github.com/linkey21/HC2LUA-TermostatoVirtual/archive/v1.0.zip) descomprimir el fichero y seguir leyendo /doc/Termostato Virtual - PID.pdf
-
Gracias @linkey y gracias también a @maestrea por este impresionante desarrollo de meses y meses.
Había leído ya muchas cosas sobre control PID, pero nada mínimamente comparable con esto.
Aquí está el enlace al post en el blog, para los que quieran leerlo antes:
http://www.domoticadomestica.com/termostatos-inteligentes-control-pid/
Un saludo.
-
Alucinante!!, muchas gracias linkey y maestrea.
-
Enhorabuena por el curre!
Enviado desde mi iPhone utilizando Tapatalk
-
Imagino que será la caña, pero no me he enterado de nada.
Es sólo para Fibaro?
FDO: Flipy
-
Lástima que me fuera del HC2 world, Chapeau por lo que habéis hecho!
-
Imagino que será la caña, pero no me he enterado de nada.
Es sólo para Fibaro?
FDO: Flipy
Sip, solo para fibaro HC2
-
Lástima que me fuera del HC2 world, Chapeau por lo que habéis hecho!
Existe algo para eedomus, pero no lo he probado ni sé si es tan completo.
En el idioma de Robespierre.
-
Supongo que te refieres a un tutorial de domo-blog.
Es un sistema muy interesante, pero creo que ni mucho menos tan "experto" en cuanto a PID, como éste.
Pero sí, se podría implementar algo parecido en eedomus, creo yo, como lo demuestra ese post.
-
Estaría bien
FDO: Flipy
-
Magistral! Para quitarse el sombrero...
-
Supongo que te refieres a un tutorial de domo-blog.
Es un sistema muy interesante, pero creo que ni mucho menos tan "experto" en cuanto a PID, como éste.
Pero sí, se podría implementar algo parecido en eedomus, creo yo, como lo demuestra ese post.
Me refiero a "ThermoLearn", no sé si hablamos del mismo porque hay varios. Parece completito...
https://github.com/influman/eedomus_ThermoLearn
Pero esto es otra historia y estamos en la zona de los Fïbaros ;D ;D
-
Si, es lo mismo, viene del post que decía yo de domo-blog.
Pero volvamos a Fibaro ;D
-
Enhorabuena @linkey !!
Me parece un trabajo fantástico de programación.
Quería hacer una pregunta al respecto: entiendo que el sistema hace actuar un relé para que encienda/apague la caldera o radiador (ON-OFF). En mi caso lo que tengo es una única caldera, y fancoils independientes en cada habitación, y para regular la temperatura necesito incrementar/disminuir la velocidad del ventilador (o si fueran válvulas necesitaría abrir/cerrar las mismas), pero no totalmente, sino en pequeños valores.
¿Crees que se podría adaptar el termostato para que hiciera algo así? He estado buscando las fórmulas que aplica el PID, pero no he sido capaz de encontrarlas.
Muchas gracias por haber compartido este trabajo.
-
linkey, lo has probado en la ultima beta 81? lo comento porque lo puse, empece a probarlo y todas las escenas empezaron a retrasarse 3-4 segundos, un lag de la pera, los eliminé y volvió todo a la normalidad.
Me di una vuelta por el foro oficial y leí que alguna gente había tenido el mismo problema de retrasos, aparentemente relacionados con el mail loop (que ademas se cuelga sin motivo aparente) y funciones de tipo loop como while.
claro, podría ser que hayan hecho una cagada haciendo cambios, como el de los eventos de los sensores, o que hayan puesto mas restricciones en el main loop o en este tipo de funciones.
bueno, era por saber si lo habías probado en la 81
-
linkey, lo has probado en la ultima beta 81? lo comento porque lo puse, empece a probarlo y todas las escenas empezaron a retrasarse 3-4 segundos, un lag de la pera, los eliminé y volvió todo a la normalidad.
Me di una vuelta por el foro oficial y leí que alguna gente había tenido el mismo problema de retrasos, aparentemente relacionados con el mail loop (que ademas se cuelga sin motivo aparente) y funciones de tipo loop como while.
claro, podría ser que hayan hecho una cagada haciendo cambios, como el de los eventos de los sensores, o que hayan puesto mas restricciones en el main loop o en este tipo de funciones.
bueno, era por saber si lo habías probado en la 81
No, aún no he probado la beta 81, en cuanto salga versión oficial lo probaré.
-
Enhorabuena @linkey !!
Me parece un trabajo fantástico de programación.
Quería hacer una pregunta al respecto: entiendo que el sistema hace actuar un relé para que encienda/apague la caldera o radiador (ON-OFF). En mi caso lo que tengo es una única caldera, y fancoils independientes en cada habitación, y para regular la temperatura necesito incrementar/disminuir la velocidad del ventilador (o si fueran válvulas necesitaría abrir/cerrar las mismas), pero no totalmente, sino en pequeños valores.
¿Crees que se podría adaptar el termostato para que hiciera algo así? He estado buscando las fórmulas que aplica el PID, pero no he sido capaz de encontrarlas.
Muchas gracias por haber compartido este trabajo.
Eso sería un proyecto para futuro, no es lo mismo un sistema en el que solo puedes controlar encendiendo o apagando que uno en el que regulas la "potencia" de salida. No es tan sencillo como modificar las formulas del PID.
También tengo intención de modificar el PID para que controle errores negativos y poder controlar refrigeración en lugar de calefacción.
De todas formas si crees que te pudiera servir, el cálculo del PID está todo metido en una función mira el código fuente del mainLoop del termostato desde las líneas 60 a 166.
calculatePID(PID)
(table) PID: tabla que representa el estado actual del PID
Calcula el PID y lo devuelve una tabla que lo representa
Tabla PID:
{result = 0, newErr = 0, acumErr = 0, proporcional = 0,
integral = 0, derivativo = 0, lastInput = 0, value = 0, targetLevel = 0,
kP = 250, kI = 50, kD = 25, cyclesH = 12, antiwindupReset = 1, tuneTime = 0,
checkPoint = 0, changePoint = 0, minTimeAction = 30, secureTimeAction = 0,
histeresis = 0.1}
Para integrarlo en un desarrollo propio, tienes que crear una tabla con el PID = {result = 0, newErr = 0, acumErr = 0, proporcional = 0, ntegral = 0, derivativo = 0, lastInput = 0, value = 0, targetLevel = 0, kP = 250, kI = 50, kD = 25, cyclesH = 12, antiwindupReset = 1, tuneTime = 0, checkPoint = 0, changePoint = 0, minTimeAction = 30, secureTimeAction = 0, histeresis = 0.1}
e invocar PID = calculatePID(PID) que te devolverá el PID calculado.
La idea es modificar targetLevel(consigna) y value(temperatura actual) cada vez que se invoca el PID, de forma que cambia el error y devuelve un PID con un result (resultado) diferente.
Actualmente este resultado sería el tiempo que la caldera permanece encendida durante el ciclo. Puede que este valor te sirva para convertirlo en un factor de velocidad para los ventiladores.
-
linkey, lo has probado en la ultima beta 81? lo comento porque lo puse, empece a probarlo y todas las escenas empezaron a retrasarse 3-4 segundos, un lag de la pera, los eliminé y volvió todo a la normalidad.
Me di una vuelta por el foro oficial y leí que alguna gente había tenido el mismo problema de retrasos, aparentemente relacionados con el mail loop (que ademas se cuelga sin motivo aparente) y funciones de tipo loop como while.
claro, podría ser que hayan hecho una cagada haciendo cambios, como el de los eventos de los sensores, o que hayan puesto mas restricciones en el main loop o en este tipo de funciones.
bueno, era por saber si lo habías probado en la 81
La verdad es que me está preocupando, porque tengo varios desarrollos de este tipo que se verían afectados si esto sigue así en la versión definitiva. Lo de que se cuelgan sin motivo aparente ya ocurre ahora, es por esto que recomiendo el uso de escenas como watchDog para reiniciar los VD colgados (está al final del manual).
A que te refieres con "como el de los eventos de los sensores"?.
-
linkey, lo has probado en la ultima beta 81? lo comento porque lo puse, empece a probarlo y todas las escenas empezaron a retrasarse 3-4 segundos, un lag de la pera, los eliminé y volvió todo a la normalidad.
Me di una vuelta por el foro oficial y leí que alguna gente había tenido el mismo problema de retrasos, aparentemente relacionados con el mail loop (que ademas se cuelga sin motivo aparente) y funciones de tipo loop como while.
claro, podría ser que hayan hecho una cagada haciendo cambios, como el de los eventos de los sensores, o que hayan puesto mas restricciones en el main loop o en este tipo de funciones.
bueno, era por saber si lo habías probado en la 81
La verdad es que me está preocupando, porque tengo varios desarrollos de este tipo que se verían afectados si esto sigue así en la versión definitiva. Lo de que se cuelgan sin motivo aparente ya ocurre ahora, es por esto que recomiendo el uso de escenas como watchDog para reiniciar los VD colgados (está al final del manual).
A que te refieres con "como el de los eventos de los sensores"?.
en la beta 81 han cambiado el tipo de disparador, de propiedad a evento
hasta la 80
if (startSource["type"] == "property") then
en la 81
if (startSource["type"] == "event") then
con un 'o una cosa o la otra' se soluciona, pero claro, lo cambiaron sin decir nada, ahora dicen que la próxima versión se podrá utilizar cualquiera de las dos.
ya, el mail loop a mi siempre me dio problemas, hace tiempo los códigos de los main loop los pasé a botones y llamo a todos estos botones cada uno con la frecuencia que quiero desde GEA, desde que hice eso 0 problemas.
-
linkey, lo has probado en la ultima beta 81? lo comento porque lo puse, empece a probarlo y todas las escenas empezaron a retrasarse 3-4 segundos, un lag de la pera, los eliminé y volvió todo a la normalidad.
Me di una vuelta por el foro oficial y leí que alguna gente había tenido el mismo problema de retrasos, aparentemente relacionados con el mail loop (que ademas se cuelga sin motivo aparente) y funciones de tipo loop como while.
claro, podría ser que hayan hecho una cagada haciendo cambios, como el de los eventos de los sensores, o que hayan puesto mas restricciones en el main loop o en este tipo de funciones.
bueno, era por saber si lo habías probado en la 81
La verdad es que me está preocupando, porque tengo varios desarrollos de este tipo que se verían afectados si esto sigue así en la versión definitiva. Lo de que se cuelgan sin motivo aparente ya ocurre ahora, es por esto que recomiendo el uso de escenas como watchDog para reiniciar los VD colgados (está al final del manual).
A que te refieres con "como el de los eventos de los sensores"?.
en la beta 81 han cambiado el tipo de disparador, de propiedad a evento
hasta la 80
if (startSource["type"] == "property") then
en la 81
if (startSource["type"] == "event") then
con un 'o una cosa o la otra' se soluciona, pero claro, lo cambiaron sin decir nada, ahora dicen que la próxima versión se podrá utilizar cualquiera de las dos.
ya, el mail loop a mi siempre me dio problemas, hace tiempo los códigos de los main loop los pasé a botones y llamo a todos estos botones cada uno con la frecuencia que quiero desde GEA, desde que hice eso 0 problemas.
Gracias por la explicación.
Lo de pasar el código de mainLoop a botones ya lo he probado (en una versión del termostato estuvo así) pero luego me obliga a lanzarlo desde un escena ya que si los invocara desde el VD estaría en las mismas.
No uso GEA, pero parece que sería esto mismo, invocar los botones desde una escena. GEA usa bucles while true do, no se verá afectada por este problema de la 081?.
-
linkey, lo has probado en la ultima beta 81? lo comento porque lo puse, empece a probarlo y todas las escenas empezaron a retrasarse 3-4 segundos, un lag de la pera, los eliminé y volvió todo a la normalidad.
Me di una vuelta por el foro oficial y leí que alguna gente había tenido el mismo problema de retrasos, aparentemente relacionados con el mail loop (que ademas se cuelga sin motivo aparente) y funciones de tipo loop como while.
claro, podría ser que hayan hecho una cagada haciendo cambios, como el de los eventos de los sensores, o que hayan puesto mas restricciones en el main loop o en este tipo de funciones.
bueno, era por saber si lo habías probado en la 81
La verdad es que me está preocupando, porque tengo varios desarrollos de este tipo que se verían afectados si esto sigue así en la versión definitiva. Lo de que se cuelgan sin motivo aparente ya ocurre ahora, es por esto que recomiendo el uso de escenas como watchDog para reiniciar los VD colgados (está al final del manual).
A que te refieres con "como el de los eventos de los sensores"?.
en la beta 81 han cambiado el tipo de disparador, de propiedad a evento
hasta la 80
if (startSource["type"] == "property") then
en la 81
if (startSource["type"] == "event") then
con un 'o una cosa o la otra' se soluciona, pero claro, lo cambiaron sin decir nada, ahora dicen que la próxima versión se podrá utilizar cualquiera de las dos.
ya, el mail loop a mi siempre me dio problemas, hace tiempo los códigos de los main loop los pasé a botones y llamo a todos estos botones cada uno con la frecuencia que quiero desde GEA, desde que hice eso 0 problemas.
Gracias por la explicación.
Lo de pasar el código de mainLoop a botones ya lo he probado (en una versión del termostato estuvo así) pero luego me obliga a lanzarlo desde un escena ya que si los invocara desde el VD estaría en las mismas.
No uso GEA, pero parece que sería esto mismo, invocar los botones desde una escena. GEA usa bucles while true do, no se verá afectada por este problema de la 081?.
si, hay que lanzar la pulsación del botón desde una escena, si se hace desde el main loop entramos en main loop :D
invocarlos desde GEA es eso, desde una escena, no se como lo ha programado, no soy programador y solo se cosas básicas, pero no ha fallado nunca, incluso cuando salió la limitación de instancias no le afecta, creo que guarda todas las acciones en una tabla y luego revisa cada x segundos y mira si tiene que hacer algo.
debe de tenerle cogido el punto al tema, porque los dispositivos que hace el menda, por ejemplo el de sonos, mira que le mete código en el main loop y nunca falla, yo le meto 2 lineas estupidas a un main loop y se tuesta :D
-
No he usado GEA, pero he programado mi propio gestor de eventos.
Es una escena que admite declaración de acciones y de eventos en el tiempo como se haría en linux con crontab.
La escena comienza al principio de un minuto y se auto ejecuta cada minuto de forma asíncrona usando setTimeout(), por lo que creo que no puede estar afectada por cuelgues por que no hay ningún bucle while.
De esta forma chequea cada minuto si hay alguna acción programada y la ejecuta. Se puede programar afinando al minuto casi cualquier cosa, un día de la semana, los fines de semana, en primavera y verano, por la noche, tal día concreto a tal hora y tal minuto...
ejemplo declaración de una acción
actionTab['diarioPersianas75'] = {
funcion = 'setValue',
dispositivos = {65,84,101,103,105,107,109,198,212,235},
argumento = '75'
}ejemplo declaración de un evento
-- días de diario a las 07:45
cronTab[#cronTab+1] = {
type = 'crontab',
cronTab = {min={45}, hour={07}, day={'*'}, month={'*'}, wday={2,3,4,5,6}},
acciones = {actionTab['diarioPersianas75']}
}
Por otro lado tengo otra escena para ejecutar acciones según sucesos que se disparan por cambio de valores en propiedades de dispositivos o variables globales.
ejemplo de evento por suceso:
--[[ se abre la puerta y la alarma está armada -------------------------------]]
triggerTab[#triggerTab+1] = {
id = {14},
valor = {'1'},
condicion =
function()
return tonumber(fibaro:getValue(14, "armed")) > 0
end,
retardo = 2,
acciones = {actionTab['enviarPushPuerta'], actionTab['enviarFotos']}
}
A ver si tengo tiempo para documentarlo...
Aún así esto no me sirve para el termostato virtual que, ha de "auto-gestionarse"
-
esta claro que tienes un don ;D, los mortales como yo nos vamos buscando la vida con los if :P
lua desde luego es un lujo para los que tenéis ese don, y para el resto es un lujo que compartáis los que hacéis.
-
esta claro que tienes un don ;D, los mortales como yo nos vamos buscando la vida con los if :P
lua desde luego es un lujo para los que tenéis ese don, y para el resto es un lujo que compartáis los que hacéis.
Yo he ido aprendiendo a programar LUA sobre la marcha desde que tengo el HC2 antes no sabía ni que existía ese lenguaje y sigo sin saber mucho de LUA, voy consultando manuales de referencia según necesito y mirando código de otros, todo es ponerse.
-
Lo primero felicitar a los autores de este Termostato Virtual, buen trabajo!
Yo tenía mi propio sistema programado en LUA pero no tan configurable ni integrado con el Panel del HC2.
He instalado este Termostato PID y por ahora parece que funciona muy bien.
Sólo echo en falta una cosa que tenía en mi desarrollo y es la posibilidad de actuar también sobre los radiadores individuales (uso valvulas Danfoss). La razón es que diferentes habitaciones tienen temperaturas muy distintas (unas que dan al norte y otras al sur, cuando se enciende la chimenea, etc...). Por lo tanto, cuando la habitación más fría demanda la puesta en marcha de la caldera, esto calienta toda la casa, lo que en ocasiones es un inconveniente (imaginad un salón que está con la chimenea encendida).
Quiero extender este desarrollo para que el actuador no sea sólo la caldera sino una lista de radiadores a encender y apagar. (uso los Danfoss sólo como ON/OFF).
Mi pregunta por tanto es, puedo cambiar el actuador por una lista o por un código LUA que haga lo que quiero? cual es la mejor forma? Por supuesto si recomedais otra aproximación soy todo oidos.
Reitero mi agradecimiento a los autores!
-
Hola ruizcubo,
ultimamente estoy un poco descolgado del tema de la domótica por el trabajo, pero a primera vista creo que lo que quieres hacer ya se puede hacer, puedes incorporar todos los termostatos virtuales que necesites y manejarlos desde el Panel de termostatos, cada uno tiene su propia sonda, actuador y controlador PID.
Creo que esta es la solución que planteas, ya que si de otra forma, sustituimos el actuador por una lista de actuadores, todos actuarían al unísono, encendiendo y apagando los danfoss al mismo tiempo.
Para este invierno tengo previsto poner en marcha llaves termostáticas danfoss en los radiadores, cuando me ponga con ello si hago alguna modificación la iré publicando, mi idea era añadir una lista al termostato pero únicamente para enviar la temperatura de consigna a las llaves.
Saludos
-
Gracias Linkey,
Ahora mismo, cada Termostato Virtual (normalmente uno por habitación) tiene una sonda (Termómetro), un Actuador (Switch enceder caldera) y un Termostato o Controlador.
Con esta configuración nada tiene efecto en los Danfoss. Si cada Termostato Virtual tiene una lista de actuadores, ademas de encender la caldera podrías encender el/los Danfoss de la habitación en cuestión. (el resto de Danfoss en otras habitaciones o Termostatos no se afectan). Ahora lo hago con una escena aparte que coloca la temperatura de los Danfoss en función del Target del controlador.
Está funcionando relativamente bien pero es por el comportamiento de los Danfoss. Ahora estoy cambiando el suelo a uno radiante y cada zona tiene electroválvulas que se pueden controlar con un Switch Domótico.
Pero el problema va a ser el mismo, si como actuador del Salón pongo el Switch de la caldera, no puedo poner el Switch del suelo radiante. Lo que quiero es que se activen ambos a la vez. La solución creo que va a ser sencilla, en cada habitación poner como Actuador la válvula correspondiente y activar siempre la caldera dentro del codigo LUA del controlador justo tras activar el Actuador.
Me ha quedado muy largo pero espero haberme explicado :)
Saludos
-
A ver si lo he entendido.
Tu idea es que un termostato virtual actué sobre varios actuadores al mismo tiempo y que uno de ellos sea el de la caldera. Hasta aquí mas o menos bien, si el PID considera que hay que encender la caldera la enciende y ademas enciende varios radiadores.
Para actuar sobre otras zonas, pondrías otro termostato virtual con otro grupo de actuadores en el que también estaría el actuador de la caldera, ERROR!, el sistema PID no funcionaría.
La caldera funciona en ciclos de los cuales una parte del mismo se encuentra encendida y el resto apagada, al finalizar el ciclo se informa al PID con el error (diferencia entre la consigna y la temperatura actual de la sonda) y este realiza un nuevo cálculo en el que determina el tiempo de encendido/apagado del siguiente ciclo. En el cálculo se tienen en cuenta un valor Proporcional al error, otro Integral en el que se tienen en cuenta los errores acumulados y otro Derivativo que tiene en cuenta la diferencia entre los dos últimos errores (además de otras consideraciones).
Si dos PID diferentes actuar sobre la misma caldera, a parte volverla loca, afectarían el comportamiento uno del otro.
Por lo que entiendo tu quieres un sistema multizona, y para esto se tiene que poder actuar sobre cada zona.
Por ejemplo, yo tengo una caldera en la casa del pueblo con dos zonas, para cada zona tengo un actuador, cada actuador actual sobre una electro-válvula correspondiente a su zona y adicionalmente sobre la caldera.
De esta manera se puede instalar un termostato en cada zona (físico o virtual) porque el termostato actual sobre la válvula como si cada válvula tuviera su propia caldera, como no la tiene lo que hace el actuador es encender adicionalmente la caldera (si estuviera apagada) aunque el otro actuador este apagado.
Todo esto evidentemente se puede virtualizar, pero no es tan sencillo como poner varios actuadores en cada termostato virtual. Habría que crear el concepto de actuador de caldera y actuador de válvula (o grupo de válvulas en tu caso).
El el caso que expones del suelo radiante, supongo que si podrás usar el sistema actual, ya que si la instalación es multi-zona tendrá un actuador para cada zona con su termostato (que podrás suplantar con por termostato virtual) y su válvula.
Menudo lío, bueno si me animo y tengo tiempo sería un proyecto bonito.
-
Yo creo que el termostato virtual es un elemento diferenciador a la hora de la comodidad del propietario, y más teniendo en cuenta que elementos como la chimenea ya necesita un mantenimiento específico. Yo he tenido bastantes problemas con esto, especialmente con las rejillas de chimenea (http://www.fumisteria.es/rejillas-de-chimenea-25), que he tenido que cambiar en varias ocasiones