Nuevo firmware Qubino Flush Shutter

[Javier]

Hola a todos.

Quiero haceros notar que los dispositivos Flush Shutter de Qubino vienen con un nuevo firmware. Tengo algunos con el original y, ahora, algunos del nuevo. Diferencias: Cuando se actúa sobre pulsador cableado, con el original reaccionaba al instante, ahora tardan algo (medio segundo). He escrito a Qubino y me confirman que prefieren hacer más chequeos antes del movimiento para garantizar buen funcionamiento.
Tenía problemas con un toldo controlado por uno de ellos por lo que tras una intensa conversación (varios email) con Qubino he optado por intercambiar el que tenía conectado al toldo (firmware original) por uno de los nuevos. Aparentemente parece que va bien (aún debo observarlo unos días) pero ayer vi que, a pesar de estar asociado a su estación meteorológica para que lo cerrara en un golpe de viento, el toldo no se cierra, mientras que otro toldo con el flush shutter en versión original sí.
Tras nuevo email a Qubino me dicen que es debido a que el nuevo lo he metido en formato no seguro y la estación sí está incluida en ese modo. Vale, "se lo compro". Pero resulta que, al incluirlo en modo seguro, Jeedom ya no lo reconoce como el módulo que es, sino como un elemento general (adjunto imagen). Los dispositivos con el firmware original eran reconocidos en modo seguro sin problema. Eso provoca que, en 'valores' y en 'parámetros' pueda manejarlo pero en la pestaña 'Comandos' no muestra lo que es. Con ello es imposible hacer una escena ya que 'tira' de los comandos.
Lo peor de todo es que, tras todo esto, la asociación directa con la estación meteorológica suya, sigue sin funcionar, cuando con el firmware original lo hacía (el otro toldo lo sigue haciendo) perfectamente.

¿Alguien sabe (a ver si san Phroc me lee) por qué en modo seguro no es reconocido ahora y en no seguro sí?
Lo de que la asociación directa ya no funcione me temo que me lo tendrán que explicar (si son capaces) ellos.

Saludos,

P.D. Entre todo esto, comprobando si el error era de la estación, me he cargado una cazoleta del anemómetro (y ya no lo fabrican en Qubino más). ¡Vaya mañanita!

[phroc]

Ay... Qubino y los cambios de firmware... Es como un "déjà vu".

Un cambio de firmware en un módulo, no siempre pero en muchos casos implica una nueva integración en el controlador, en este caso Jeedom.

Sí, puede ser normal que con el nuevo firmware te funcione como con el anterior en modo no seguro, pero no lo haga en modo seguro.

Es probable que para integrar el módulo que tenía el firmware antiguo, el equipo de Jeedom tuviera que hacer una especie de parche en OpenZWave, para que funcionara correctamente en modo seguro.

Ahora al cambiar el firmware, tendrán que volver a integrarlo y si acaso a hacer ese "parche" de nuevo.

Como sabes, el motor Z-Wave que usa Jeedom a día de hoy en OpenZWave, que tiene sus ventajas, pero también sus inconvenientes (que no son pocos cuando hablamos de Z-Wave seguro o encriptado). De ahí que en la hoja de ruta de Jeedom para ese año esté el tema de abordar un eventual cambio de motor Z-Wave... precisamente para dejar de sufrir las limitaciones de OpenZwave en Z-Wave seguro.

Resumiendo: el equipo de Jeedom tendrá que volver a incluir este módulo con este nuevo firmware.

En cuanto a lo que te dicen desde Qubino: es cierto. Si tienes la estación en modo seguro, para hacer una asociación directa el otro módulo tiene que estar en modo seguro también, sino no funcionará la asociación directa (lógico por otra parte, sino ese nivel de seguridad no serviría de nada).

Se me ocurre que vuelvas a poner el módulo antiguo o, mientras el equipo de Jeedom vuelve a integrar ese firmware nuevo, uses una escena en vez de una asociación directa (no es lo mismo, pero...).

Saludos.

[Javier]

Ay... Qubino y los cambios de firmware... Es como un "déjà vu".

Un cambio de firmware en un módulo, no siempre pero en muchos casos implica una nueva integración en el controlador, en este caso Jeedom.

Sí, puede ser normal que con el nuevo firmware te funcione como con el anterior en modo no seguro, pero no lo haga en modo seguro.

Es probable que para integrar el módulo que tenía el firmware antiguo, el equipo de Jeedom tuviera que hacer una especie de parche en OpenZWave, para que funcionara correctamente en modo seguro.

Ahora al cambiar el firmware, tendrán que volver a integrarlo y si acaso a hacer ese "parche" de nuevo.

Como sabes, el motor Z-Wave que usa Jeedom a día de hoy en OpenZWave, que tiene sus ventajas, pero también sus inconvenientes (que no son pocos cuando hablamos de Z-Wave seguro o encriptado). De ahí que en la hoja de ruta de Jeedom para ese año esté el tema de abordar un eventual cambio de motor Z-Wave... precisamente para dejar de sufrir las limitaciones de OpenZwave en Z-Wave seguro.

Resumiendo: el equipo de Jeedom tendrá que volver a incluir este módulo con este nuevo firmware.

En cuanto a lo que te dicen desde Qubino: es cierto. Si tienes la estación en modo seguro, para hacer una asociación directa el otro módulo tiene que estar en modo seguro también, sino no funcionará la asociación directa (lógico por otra parte, sino ese nivel de seguridad no serviría de nada).

Se me ocurre que vuelvas a poner el módulo antiguo o, mientras el equipo de Jeedom vuelve a integrar ese firmware nuevo, uses una escena en vez de una asociación directa (no es lo mismo, pero...).

Saludos.

Gracias por tu rapidez. Últimamente te veo mucho (la semana pasada estuve viendo los dos últimos webinars tuyos).
Aprovechando tu respuesta, voy a detallar algo mi problema porque seguro que a alguien puede serle útil:

• He puesto el módulo en modo seguro también, pero la asociación directa no funciona. Probaré lo contrario; poner los 3 dispositivos (estación Qubino y los 2 flush shutters) en modo no seguro. A ver si 'suena la flauta' y el módulo nuevo sí reaccionara a la asociación directa.
• Propones que ponga el módulo antiguo. Lo retiré porque presenta un problema que entre Qubino y yo no hemos sido capaces de solventar pero sí de, al menos, saber dónde está: el toldo (nunca pasa con persianas, solo con los toldos y especialmente con el más pesado), de vez en cuando, cuando lo recoges un poco (por ejemplo), al pulsar el botón después para recogerlo del todo, no se mueve (también pasa al sacarlo a veces). Da igual si lo haces con el pulsador físico (cableado) o con el jeedom. La única solución es pulsar un momento sobre el movimiento contrario y volver a pulsar lo que querías en un principio. Eso es peligrosísimo ya que si la estación ordena recoger por ráfaga de viento y en ese momento el toldo se ha quedado 'pillado' en ese problema, no lo recogería. Mi toldo mide más de 5 metros de ancho así que te imaginarás que es como la vela de un pequeño barco. Vamos, que se podría preparar muy gorda. Por eso había intercambiado el módulo por uno de los nuevos.
  Para información de todos, lo que hemos averiguado entre Qubino y yo es que el módulo alguna vez informa erróneamente de la posición. Por ejemplo si lo estoy extendiendo hasta la mitad y lo quiero seguir extendiendo hasta el final pero no se mueve, miro el jeedom y veo que eso sucede porque el sistema se 'piensa' que está totalmente extendido. Por eso no se mueve. Sin embargo pulsando brevemente el movimiento contrario, ya recibe información de la posición real y se puede retomar el movimiento original.
  Propones meter una escena. Yo lo intentaba evitar para salvar que, ante una caída de jeedom, al ser una maniobra de protección del toldo, no se quedara sin moverse, pero lo acepto ya que así, puedo hacer un movimiento de 1 segundo en sentido contrario previo, asegurando que salvo el error descrito antes.
  Aprovecho para preguntarte una duda. Si quiero que esa escena esté activa constantemente ¿qué tendría que poner'? Entiendo (corrígeme si me equivoco) que debería ser un escenario 'programado', no provocado, y la programación debería ser ***** . Eso implicaría que el toldo podría estar como máximo 1 minuto en espera del disparo de la acción. ¿es correcto lo que propongo?
  De hecho tenía esa duda cuando recojo los toldos ya que lo hago de manera provocada con el atardecer de un plugin. Al ser aquí 'provocado' puedo retrasarlo unos minutos con 'time_op' pero no podría anticiparlo al atardecer poniendo un valor negativo a 'time_op' ya que, hasta que no llega el evento que lo provoca no empezaría a contar. Es decir, habría que pasarlo a programado también de manera permanente. (Es una pregunta)
  El hecho de tener bastantes cosas en modo ****** ¿no sobrecarga mi raspberry 3b+? Me acabo de dar cuenta de que no he dicho que 'caja' tengo.

Muchas gracias y espero que todo esto sirva a alguien más.

Saludos,
Javier.-

Actualización:
He probado a introducir los 3 dispositivos en modo no seguro (Estación Qubino, Flush shutter firmware antigo y Flush shutter firmware nuevo). El mismo resultado. La asociación directa funciona perfectamente entre estación y flush shutter con firmware antiguo. El del firmware nuevo no reacciona ante golpe de viento. Inaceptable de todo punto, especialmente considerando que todo es del mismo fabricante (aunque esto no debería influir).

[phroc]

Sobre lo que me preguntas de la escena, no acabo de entender como lo tienes, por lo que es probable que mi respuesta no sea la correcta.

Así como principio general, si el disparador es "un golpe de viento" (es decir el anemómetro), tu escena debería ser con criterio provocado, no programado.

Otra cosa es que tengas otra escena programada para hacer aperturas y cierres a horas determinadas y/o con amanecer/atardecer.

Saludos.

[Javier]

Sobre lo que me preguntas de la escena, no acabo de entender como lo tienes, por lo que es probable que mi respuesta no sea la correcta.

Así como principio general, si el disparador es "un golpe de viento" (es decir el anemómetro), tu escena debería ser con criterio provocado, no programado.

Otra cosa es que tengas otra escena programada para hacer aperturas y cierres a horas determinadas y/o con amanecer/atardecer.

Saludos.

Hola de nuevo y gracias.

Pues el 'golpe de viento' (wind gust) no lo tenía programado sobre una escena ya que no viene como comando. Solamente se podía utilizar para una asociación directa que es como estaba. Ahora he creado el comando y lo refleja bien (más allá de mantener la asociación directa por seguridad). No obstante, he aprovechado tu artículo sobre 'acción sobre el valor' combinado con que dispare una escena. Me parece de gran utilidad.
Qubino respondió que no acaban de comprender cómo los dispositivos con el nuevo firmware no responden a la asociación directa con su estación meteorológica. No obstante, como ya no la comercializan (desconozco el porqué), no me extrañaría que no se hubieran molestado en probarlo antes de lanzarlo al mercado. Teóricamente están comprobando qué sucede.
Por otro lado, sobre el asunto de disparar una escena antes del atardecer, al no poder usar como disparador el evento 'atardecer' ya que quiero que se ejecute antes de que ese evento suceda, ¿lo único que se podría usar es una escena que esté 'cuasipermanentemente' disparándose con *****? O ¿a alguien se le viene a la cabeza otra opción?
Voy a aprovechar que estoy de 'limpieza' para hacer una instalación desde 0 ya con Debian 10 y Jeedom v4 sobre raspberry 3b+. Imagino que me llevará un tiempo porque había logrado tener https con letsencrypt sobre noip.com. No es trivial pero si uno es perseverante, se logra.

Saludos,