Según parece, Qubino entrega ahora, desde hace algunas semanas, sus módulos ocultos de 2 relés con un nuevo firmware etiquetado como S5.
Hemos podido constatar que ese nuevo firmware no reportaba ni consumo ni estado, al menos en eedomus (las órdenes ON/OFF sí funcionan).
Después de hablar con el equipo de desarrollo de eedomus, han integrado ese nuevo firmware para integrarlo plenamente en eedomus.
Esa nueva integración ya es operativa. Si sois de los que tenían ese módulo con ese firmware y habéis notado que no os reportaba ni consumo ni estado en eedomus, tenéis que excluir y volver a incluir el módulo.
Después de eso, el módulo reportará consumos pero no el estado ya que el equipo de eedomus ha descubierto que este nuevo firm tiene un bug y no reporta estado nativamente. Para conseguir un reporte de estado, hay que hacerlo por polling (en la ventana de configuración del módulo en la interfaz de eedomus, apartado “Parámetros experto”, polling).
Si tenéis ese módulo con otro firmware y os funciona bien, no debéis cambiar nada.
Espero que esta información sea de utilidad a la hora de elegir el módulo adecuado. Son una verdadera pena estos sobresaltos de Qubino a nivel de software. Son módulos muy buenos y que ofrecen funcionalidades únicas pero estos fallos reiterados de software perjudican mucho a la marca.
Está bien el aviso. Yo iba a comprar alguno más, pero con esto me parece que voy a replantearme los Qubino. Los S4 funcionan bien: reportaban el estado de cada relé así como el consumo (wats) y energía (kwh, eso si, con un sólo dígito decimal).
¿Porqué el nuevo firmware?
Reedito: si alguien usa los S5 de Qubino con Domoticz que cuente como van. Los S4 iban bien, pero había que modificar el archivo de configuración (la última actualización de OZWave ya incluía este cambio creo recordar)
¿Nadie sabe que modificaciones aporta la versión S5? ¿o solo la han lanzado para empeorar la S4? (por lo del estado de los reles) Supongo que la habrán sacado para mejorar algo… ¿no?
Gracias
¿Nadie cuenta nada de esta revisión, la S5? Los de Qubino no responden, cosa extraña porque suelen dar respuesta inmediata a las preguntas que se les plantea. Será por el mes de Agosto.
Con lo bien que iba el S4 no entiendo que saquen esta revisión y que no la arreglen. Yo al menos no le veo ningún fallo a mis interruptores con la S4. El único pero era que los kwh los da con pocos decimales, pero en Domoticz se solucionó este problema desde el código.
Para terminar de arreglarlo los Philio, que son mi otra opción, al parecer también tienen problemas con las lecturas de consumo, pero dicen que el estado de los interruptores si funciona. Lástima no poder probar antes de comprar.
Es difícil esto de comprar dispositivos ZWave.
Acabo de recibir al fin respuesta desde Qubino sobre este asunto del firmware S5. No hay bug sino una nueva manera de funcionamiento. A diferencia del módulo S4, el S5 maneja la asociación multicanal en una forma diferente. Paso la respuesta (en inglés)
[i]As you’ve noticed there is a difference between the way the S4 and S5 versions send unsolicited (Reports sent without preceding Get commands) reports to controllers. On S4 the module reports the status of the switches to the controller on every change, regardless of the way the single channel or multi channel lifeline associations were set. We implemented this in a way similar to other manufacturers, but later on had a discussion with Sigma Designs, where they explained to us the recommended way of sending unsolicited reports (they require strict separation between single channel and multi channel contexts on z-wave plus products), which we implemented in the S5 version in such a way:
If a single channel lifeline association (group 1 associated to the controller) is set then the module shouldn’t report unsolicited Multi channel Encapsulated Reports, which means only the root device will report it’s states without a Get request, not the endpoints (these need to be polled in order to receive reports). From the module’s standpoint this means the controller either doesn’t support multi channel context or the module was integrated in a non-multi channel context.
On the other hand, if a multi channel lifeline association (group 1 on each endpoint is associated to the controller’s endpoint 0 or 1, depending on integration) was set the module will report unsolicited reports from all the device’s endpoints, but not the root device. This will result in the endpoint’s statuses being reported via unsolicited reports also, not just Get commands via polling.
Additionally there are other association groups that can be set on the module (via single channel or multi channel associations) in order to filter the amount of report traffic desired.
Unfortunately, the controller used must also support setting multi channel associations, and additionally actually set them via an automated inclusion process after the controller’s manufacturer integrates the module (or alternatively allow users manual control of which multi channel association groups can be set).
Since you are using Domoticz (along with the OpenZwave engine) i’m afraid that the Domoticz team needs to either set these multi channel associations during inclusion, or allow users to set them manually. OpenZwave already supports multi channel associations but the Domoticz software that uses it does not.
[/i]
Esa respuesta, o muy parecida, nos llegó en julio creo. Después de argumentar lo del multicanal, terminaban diciendo que había que activar el polling a 30 segundos en eedomus para obtener reporte de estado…
Dicho de otra manera, no reporta estado nativamente el módulo, por mucho que digan…
Lo peor de estas cosas son las noticias contradictorias.
Supongo que eedomus soporta multicanal.
Yo con un modulo Philio ZWave (no plus) lo que hago es usar la variable TriggerRefreshValue en la configuración y reporta el estado cuando el raíz cambia, de esta forma me evito el polling.
Y con Domoticz y la version S4 de Qubino obtengo el estado de todo: raíz y relays individuales. Cada grupo lo asocio a una instancia del controlador diferente de la lifeline, esta va al nodo 1 (grupo1-nodo1) y los grupos 2 al 7 van al nodo 1.1 (instancia 1 del controlador). Y el módulo informa del estado sin problemas (root y endpoints I1, I2). Es decir Domoticz al parecer si soporta multicanal de alguna manera. Si esto funcionara con la versión S5, perfecto, el estado del dispositivo root no lo veo imprescindible.
Lo ideal sería que alguien que use Domoticz con esta versión del módulo comprobara esto, porque es raro.
Tema antiguo este del firmware S5 de Qubino, pero acabo de recibir un modulo un Qubino doble relay con firmware S5 y funciona exactamente igual que el S4 con Domoticz: reporta consumos y estados de los relays de la misma forma. O sea que eso de fallos en la version S5 no es tan cierto, o al menos con Domoticz no aparece ningún error.. por ahora ;).
La única pega (de todos los Qubino que he probado) es la precisión en las medidas de energía (los kWh): solo da un decimal, en Domoticz se soluciona con una configuración que permite que este valor sea calculado en lugar de leído, pero los de Qubino debieran pensarse lo de cambiar la precisión a 3 decimales (los consumos hoy en día son muy bajos con las lámparas led, por ejemplo).
Saludos