Cambios en los productos de Zennio

Hola Kike,

la actualización del firmware de los dispositivos Zennio para la función "full-duplex" ya es vieja (concretamente en marzo del 2011 ya todos los dispositivos zennio tenían esta funcionalidad). Esta funcionalidad creo que la deberían tener todos los productos KNX por exigencias del estandar.
Para los que no entiendan muy bien qué es lo que hace o significa esta funcionalidad "full-duplex" ponemos un ejemplo: si un dispositivo KNX (única dirección física) envía una determinada dirección de grupo al bus, al mismo tiempo, dicho dispositivo actúa como si la acabase de recibir desde el bus desde otro dispositivo distinto. Por ejemplo, un dispositivo con entradas y salidas binarias, un pulsador en una entrada y una bombilla en una salida, al ejecutar una pulsación, dicho dispositivo envía una dirección de grupo "ON" que se emite en el bus pero sólo es útil para ese mismo dispositivo, que al mismo tiempo que la emite la está recibiendo y por lo tanto enciende la bombilla de su salida.

Una cosa que me gustaría recomendar es que SIEMPRE se debería utilizar el objeto de comunicación de "estado" de todas las salidas. No se debería utilizar una misma dirección de grupo para actuar sobre una salida y al mismo tiempo actualizar una visualización. Recomiendo siempre utilizar el objeto "estado" para lo que es. Aunque requiera una direción de grupo a mayores es una buena práctica. Además si no lo haces así puede provocar muchísimos problemas de funcionalidad y visualización en programaciones más avanzadas.

con respecto a la pregunta de programación de la programación de termostato, ¿podrías exponerla un poco más detallada? No te entiendo muy bien.

Un saludo.

Buenas a todos,


Este post es sólo para comentar una pequeña comida de cabeza que he tenido últimamente con mi forma de programar cuando actualizaba algún aparato de Zennio con las últimas versiones del propio aparato y del programa de aplicación.

Zennio ha actualizado sus dispositivos y con el cambio, ha mejorado la comunicación interna de objetos, eliminado también los tediosos enlaces internos, lo cual es de agradecer porque era bastante engorroso tenerlo todo controlado para que la instalación funcionase como se pretendía. Esto que quiere decir, que ahora si que se actualizan los objetos "provenientes" del mismo aparato pudiendo producir efectos no deseados que antes no se daban, como en este caso:

Mi forma de programar una salida, para una luz o para un control on/off era creando una dirección de grupo llamada "Luz X", en esa dirección enlazaba los objetos de Estado y el propio control ON/OFF del actuador, para así tener siempre el control de la luz y el estado para las visualizaciones en la misma dirección de grupo (ya se que no es muy normal, pero para mi quedaba una programación más limpia y coherente....cosas mías XD).

Hasta ahí ningún problema, todo funcionaría igual en la versión antigua y en la moderna.

El problema viene cuando añadimos una temporización a esa luz o carga. Supongamos que queremos tener el control ON/OFF fijo, pero además temporizar la salida. Pues me creaba otra dirección que fuera "Luz X TEMP" y enlazaba el objeto de temporización perfectamente configurado a las funcionalidades y tiempos que necesitaba.

Pues ahí está el problema. Si ahora desde un pulsador o desde el mismo monitor de grupos del ETS ejecutaba la temporización, esta se activará, pero nunca la terminará.

En las versiones viejas esta solución funcionaba perfectamente, pero en la nueva no, precisamente por la actualización interna de objetos. ¿Que está pasando para que no concluya?

1-. Activamos la temporización, por ejemplo de una función escalera para nuestra "Lux X TEMP", obviamente se enciende, pero además el objeto de estado actualiza mandando un "1" u "on" a la dirección de grupo "Luz X" donde estaban ambos objetos, el del actuador ON/OFF y el estado. Con esta nueva situación los enlaces internos ahora se actualizan....osea que el objeto de estado "enciende" de nuevo la luz, pero esta vez sin temporizar, quedándote con cara de tonto esperando que la luz se apague.

Como se seguro que tiempo atrás pude haber recomendado a la gente programar de esa forma, igual alguien está teniendo el mismo problema si "ha calcado" una programación vieja que tenía al sustituir un actuador viejo por uno nuevo.

De todas formas, la solución es bien sencilla, crear direcciones de grupo diferentes para conmutar y para el estado.

Algo parecido me pasa con el nuevo software de la pantalla InZennio para los termostatos, donde también usaba sólo una dirección de grupo para los 2 objetos de funciones como la consigna, o el termostato o ahora el modo (han actualizado para controlar los modos de clima con objetos de 1 byte, según el estándar KNX. Aunque también mantienen el funcionamiento clásico de objetos de 1 bit). De esta forma creaba un bucle infinito de retroalimentación al cambiar por ejemplo, el modo.

La solución es sencilla, duplicar todo. Pero no es muy elegante, ya que en la propia Inzennio tienes los objetos de la pantalla de clima y del termostato (4 en total para consigna, para el modo, para el on/off del termostato) y toca organizarte y acabar siendo un poco lioso. (Ojo, en mi opinión)

¿Alguien lo ha probado? ¿Cómo habeis estructurado las direcciones de grupo? Estaría genial tener un poco de feedback. Por mi parte si alguien quiere puedo subir un proyecto ejemplo de como lo he hecho yo, por si le pudiera valer a alguien , pero no es muy intuitivo XD

Un saludo a todos!

Kike