Opiniones sobre el nuevo sensor SRBUS

Pues precisamente te decía lo contrario, apuntaba que el que sólo pueda enviar ON--OFF me parece insuficiente, y así lo notifiqué para que su programa de aplicación mejorase, al igual que varios canales de detección, sensor de luminosidad,...

Aún así, para aquellos que sólo necesiten un detector económico para encender una luz de baño, un pasillo, o un trastero (aplicaciones, creo, bastante comunes), encontrarán un producto que les vendrá muy bien. Como decía el anuncio, para el resto de cosas...

Lo interesante de este mundo es conocer qué puede hacer cada aparato, y usarlo según necesidades. Como te decía, hace lo que hace, y lo hace más que bien. Si cuadra en tú proyecto, pues listo.

Seguro que el programa de aplicación mejora en no mucho tiempo, y los errores en la documentación se solucionan.

Saludos a todos.

Hola,

Belloto, me gusta tu manera de entender las cosas. Si buscas que te envíe los valores de on y off al bus, es un producto más que elegante para tus proyectos.

I+D_BES, me alegra "leerte". aquí estamos para intentar mejorar las cosas si se puede o por lo menos para que podáis conocer opiniones de la calle. Debes comprender que el dispositivo viene como viene. Si su folleto (manual o datasheet) dice literalmente "Conexiones: conector BUS EIB + conector adicional para alimentación.". Cualquier integrador entiende que debes conectar una fuente externa de alimentación, y si tiene dudas, como es el caso, lo mínimo es dejar ver una dirección mail de soporte técnico (que yo conozca no existe ningún fabricante que te cambie un dispositivo que se haya estropeado por conectarle la alimentación de forma distinta a como viene especificado en su datasheet). No sé si en otros post como dices ya se había solucionado el tema, pero no considero que sea una obligación de vuestros clientes el tener que conocer todos los post sobre domótica para solucionar esta duda. Todo lo que hacemos los integradores es ayudaros con buena fe (mediante feedbacks) con vuestro trabajo sin pedir nada a cambio, sólo mejoras en vuestros productos, y solucionar tonterías como esas ya suponen una mejora en vuestro producto, aunque creais que es una tontería.

Por desgracia, no conozco (en la práctica ni en profundidad) el sistema Busing. No lo sé. Seguramente puede que sea mejor y más económico que KNX, pero eso aquí no creo que sea la cuestión. Si como dice Belloto, que parece controlar del tema, dicho objeto 2 de comunicación sólo funciona en el protocolo Busing, lo normal es que lo borres de datasheet del SRBUS de KNX. No me digas antes de comprarlo que tiene un objeto de comunicaión que me informa de la potencia de la señal cuando después te enteras por este compañero que sólo funciona en Busing. A Belloto le dará igual porque no lo necesita, pero yo sí lo utilizaría, y entiendo que si está implementado en Busing es porque es necesario (por lo menos para quien le de utilidad).

Me dices "Al tratarse precisamente de un valor de lectura, no influye en el funcionamiento del detector". Hombre, esa manera de ver las cosas no la comparto. El objeto de "estado" también es de lectura, y creo que no hace falta que te explique de la importancia que tiene para el buen funcionamiento del sistema.

me dices que te indique cuál es el mal funcionamiento del detector: el polémico Objeto 2 no funciona, pero como veo que no tiene funcionalidad para KNX, ya está solucionado.

En esta feria de L&B ya había por fin conseguido vuestro mail de soporte técnico para que me dieseis soporte por estas cosas, pero como os habéis adelantado, ya está solucionado.

Un saludo.

Hola JulioJF,

Desde el equipo de I+D que ha desarrollado el SRKNX, nos gustaría resolver las dudas planteadas después de exhaustivo análisis que habéis hecho del dispositivo y que ha generado tal controversia:

En referencia a la alimentación del detector, tal y como se ha reflejado en otros post, no es necesario alimentarlo de una fuente externa pudiendo puentearse las bornas entre sí y usar únicamente alimentación del BUS. Se ha realizado de esta manera por la normativa del estándar KNX que obliga a disponer de esta posibilidad de alimentación suplementaria.

Sobre la errata detectada en el catalogo del dispositivo, agradecer que haya gente tan dispuesta a colaborar detectando posibles bugs que ayudan a disponer de un producto con mayor calidad si cabe. Dicho lo cual entiendo que no es sensible para el funcionamiento del dispositivo por tratarse de un texto del cual se puede extraer perfectamente su significado real.

Respecto al objeto de comunicación de lectura de intensidad, sí que devuelve valor. Se trata de un valor instantáneo de muy difícil lectura. Al tratarse precisamente de un valor de lectura, no influye en el funcionamiento del detector, tratándose simplemente de información complementaria.

Finalmente te agradecería nos indicases en qué consiste el mal funcionamiento del detector. Se trata de una información de extrema utilidad para poder solucionar posibles incidencias y, dado lo profundo de tú análisis, entiendo que tendrás información exhaustiva sobre dichos fallos.

Toda la información que nos podáis facilitar redundará en una mayor calidad final del producto puesto que sois vosotros los que le dais la utilidad real al mismo, más allá del diseño del mismo en I+D. Muchas gracias por vuestras opiniones sobre el producto.

Gracias y un saludo.

Pues hombre, el detector funciona bien. Hace lo que hace de forma más que correcta. Su rango es amplio, se coloca oculto (no atraviesa metal), y es KNX, justo lo que se supone que tiene que hacer.

¿Qué el programa de aplicación tiene errores ortográficos, o fallos de traducción? Pues sí, pero vamos, creo que se entiende bien (fin, fini,...; en fin ) Entiendo que los solucionarán, es un simple despiste (a mi modo de ver, claro).

El objeto 2, viene del mismo dispositivo pero en su versión BUSING, no dará valores en KNX. Aún así, si uno prueba el detector, descubre algo importante: ¡es capaz de detectar y enviar valores al bus!. Nos obstante, si este objeto es útil, proponer la integración en KNX sería una posible solución.

¿Qué hace falta que el programa de aplicación haga más cosas? Estoy de acuerdo, supongo que en breve tendremos noticias. Los comienzos siempre fueron duros, y todo el mundo comete errores.

Lo dicho, yo lo he probado y el resultado es satisfactorio. Tengo claro que las propuestas serán escuchadas, yo he propuesto: varios canales de detección, objetos de byte, funciones separadas detección / fin de detección, funciones condicionadas a sonda de luminosidad externa (incluso incluirla en el próximo diseño del detector),...; bueno, pues lo que hacen otros detectores.

En fin, saludos a todos.

Hola Antonio,

El dispositivo que hemos comprado funciona mal, o sea, no realiza las funciones que el dispositivo especifica en su ficha de funcionamiento, entre otras cosas por las ya expuestas en este blog. Por lo que nos has comentado:

"Realmente estas comprando a HomeFUTURA y las garantías y responsabilidades a día de hoy son para HomeFUTURA"

me gustaría solucionar algunas preguntas:

¿Cuándo y dónde obtendremos una actualización de la base de datos del dispositivo para que funcione correctamente? Creo que ha pasado bastante tiempo y los compradores de este dispositivo SRBUS (por lo menos yo) no tenemos información ni soporte del producto que hemos comprado, y funciona mal. ¿Es ingenium el fabricante y tenemos que pedirle el soporte a ellos? ¿Ingenium es el responsable y desarrollador de esta base de datos? Principalmente me interesa porque el producto es muy práctico e interesante a nivel integración domótica.

Alguien sabe o puede aportar algo de claridad al asunto??

Muchas gracias, un saludo.