Información sobre la placa de salida de relés Ademco 4204

He conseguido algunas placas Ademco de salida de 4 relés y me gustaría poder controlarlas a través de Arduino, pero no he encontrado información sobre los protocolos de control. El bus es de tipo serie con una entrada y una salida de datos, pero asíncrono, sin señal de reloj, así que podría ser semejante al UART, aunque a buen seguro a velocidad mucho más baja, tal vez como un RS-485, puesto que el sistema permite muchos metros de cableado bifiliar con total seguridad en la comunicación, lo cual no ocurre con el RS-232.

Si alguien conoce una solución Arduino para poder aprovechar estos módulos se lo agradecería...

Saludos

Llorens

Las conexiones del 4204 son simples...

Saludos a todos...

Llorens

Esta es la placa del sistema del geriátrico?

Comparto que es muy posible que sea 485 según lo que veo por primera vez del conexionado.

Que opinas de este paper?
chrome-extension://oemmndcbldboiebfnladdacbdfmadadm/http://www.voip-sip-sdk.com/attachments/583/contact_id.pdf
Aca (link) hay unas imágenes que ayudan a entender mejor.

Este hilo menciona un sistema rs232. No los estoy leyendo con profundidad.

Fueron búsquedas rápidas asi que me disculpo si hay información que no sirva.

Pues sí, son del sistema de llamada de habitaciones, ya que en uno de los pisos han decidido cambiar el sistema para disponer de supervisión a través de un ordenador, lo cual me ha permitido desmontar algunos de los módulos de relés, así como una consola de los receptores de radio y alguno de los emisores, que seguramente podré desmontar el lunes...

He mirado los enlaces (gracias, Surbyte), pero parecen referirse a sistemas más modernos y de acceso telefónico. Por mi parte también he estado buscando por la red, y he encontrado algunas cosas interesantes, como una referencia directa a protocolos Ademco Slow y Ademco Fast (que sigue siendo lento). Tengo que estudiar bien la documentación y cuando disponga de la consola podré conectarle directamente el módulo 4204, programarla según un pdf que he encontrado, y conectarle el analizador lógico Saleae a las líneas de datos ...a ver qué saco en claro...

En realidad no creo que el protocolo sea demasiado complicado, sobre todo si es el "slow", que no lleva "checksum", pero se trata de acertar ...hasta entonces me parece tan oscuro como la escritura cuneiforme...

Sobre la semejanza con el RS-485, lo decía por la velocidad lenta, pero no creo que pueda ser el mismo, ya que éste, siendo también asíncrono, es del tipo "two wires full duplex", en cambio el 485 por lo que sé es un "one wire half duplex"...

Saludos

Llorens

Puedes precisar una central de control que usaba estos modelos, para buscar por ahí. Tiene que haber información.

En principio, éste será el material Ademco-Honeywell con el que voy a experimentar...

Los transmisores 5802H, de 868,95 Mhz, que eran de "colgante", y que yo hace años adapté para que se activaran con el primitivo sistema de aviso de habitaciones electromecánico, con relés de enclavamiento, lamparitas avisadoras y temporizadores a motor. Para ello adapté a cada circuito un reductor de tensión de 24 Vca a 3,4 Vcc...

Ahora lo que he hecho ha sido revertir el cambio, recuperando la caja de plástico original y hasta las pilas de litio de botón, de 3 Volts, que guardé en un sitio seco hace once o doce años, y que de forma milagrosa aún mantienen carga para seguir activando los emisores...

De momento utilizaré los correspondientes a las habitaciones 106, 107 y 117, que entran dentro del rango de la consola que he desmontado...

El receptor doble es del tipo 5882, y parece superheterodino de buena calidad, muy distinto a los típicos receptores de telemando superregenerativos...

La consola es del tipo SA6164-G, totalmente programable y que creo haber visto que podría controlar las placas de relés 4204 incluso sin la placa de la central de alarmas

De todas formas, también dispongo de una placa de central de alarmas, aunque no sé nada sobre ella...

Bien, como ya dije mi intención es conseguir averiguar el protocolo de control de las placas de relés. Este fin de semana comenzaré con las pruebas.

Saludos a todos

Llorens

Tras algunas pruebas he conseguido poner en marcha la alarma Ademco en modo "mínimo", es decir, sólo con los módulos imprescindibles para conseguir activar los relés de una placa 4204...

El montaje consta del receptor de UHF, una consola de control, una placa base de alarmas y un módulo de relés. Además naturalmente de tres emisores correspondientes a las habitaciones 106 y 107. Naturalmente, el módulo de relés es también el de las habitaciones 105, 106, 107, 108, con lo cual los mandos remotos debían poder activar los dos centrales.

La alimentación es a 12 Vcc a partir de una fuente, y todos los módulos van conectados al mismo bus de cuatro terminales: positivo (rojo), negativo (negro), salida de datos (verde), entrada de datos (amarillo), aunque no en todos los módulos se sigue la misma secuencia, con lo cual previamente tuve que buscar información en la red para no fastidiar nada durante el montaje.

La duda no era con la alimentación, claro, si no con las entradas y salidas de datos, ya que en los sistemas asíncronos de comunicación serie, como las RS232, las entradas y salidas de un módulo están cruzadas con respecto al otro. En este caso en cambio todas las salidas van en paralelo, así como todas las entradas, y se supone que la placa de alarmas actúa como "máster" asignando al resto de módulos esclavos su turno de actuación...

En fin, tras algunas pruebas en que no conseguía respuesta, apareció el display correcto, y después de activar el sistema con un código que encontré en la documentación, lo dejé "armado" y listo para funcionar. Seguidamente activé el mando remoto 107 y al instante la placa principal respondió con el cierre de un relé general y en la consola apareció el número de "habitación que estaba llamando" e hizo sonar un zumbador de los que te perforan el oído...

A la vez, a los dos segundos se escuchó un click en la placa de relés 4204 y el correspondiente a la habitación 107 se activó, hasta que procedí al rearme del sistema con el código anterior... Lo mismo también pasó con el mando de la habitación 106, identificándose correctamente.

En el display de la consola aparece de vez en cuando el mensaje "Fallo de red", pero todo sigue funcionando. Supongo que tiene que ver con el hecho de que faltan muchos módulos para conectar al bus, y la placa principal, en un escaneo de seguridad del sistema que tiene configurado internamente debe darse cuenta y emitir este mensaje...

Ahora el problema será conectarle el analizador lógico Saleae y conseguir descifrar el tipo de señales con que la placa base controla la de relés, aunque no será fácil distinguir entre las señales que van y vienen de los otros módulos, ya que todas ellas viajan por la misa línea...

Continuará...

Saludos a todos

Llorens

He seguido investigando sobre el tema. Primero he averiguado que la versión de esta placa base de alarma es la Ademco Vista 120, y a partir de aquí rebuscando por la red he encontrado algunos manuales, tanto de "usuario" como los de instalación y programación. Estos últimos ofrecen algunas informaciones de cómo funciona el sistema, pero no a nivel de protocolos de comunicación, que es lo que a mí me interesa.

He averiguado por ejemplo que el mensaje "Fallo de red" que me sale cada poco tiempo en la consola no se refiere a la red de módulos de la alarma, si no a la red eléctrica ...y eso ocurre porque estoy alimentando el sistema con una fuente de 12 Vcc. en la conexión de batería de back-up y no con 12 Vca. a través de su entrada correspondiente.

...También he averiguado algunos códigos de manejo, activar el sistema en distintas modalidades, desactivarlo y hasta entrar en el modo de programación. Temas sin duda interesantes pero que no me aportan información sobre cómo poder controlar con Arduino el módulo de relés 4240.

Al parecer mi idea no es nueva, porque en la red he visto algunos trabajos de interacción de los sistemas Ademco Vista con Arduino, pero la mayoría son preguntas sin respuesta, y en todo caso suelen tener que ver cómo interpretar con Arduino los códigos de la consola, no como en mi caso del módulo de relés.

Por si a alguien le interesa, los manuales citados pueden bajarse desde los siguientes enlaces:

Manual de usuario Ademco-Vista120

Manual de Instalación y programación Ademco-Vista120

Continuará...

Saludos a todos

Llorens

Esos manuales si que echan luz al tema!!

Estos manuales permiten hacerse una idea del funcionamiento general de esta alarma Ademco e incluso reprogramarla para una casa particular o un negocio, pero ya digo que no aclaran demasiado a nivel de protocolos. De todas formas, rebuscando por la red he descubierto algunas cosas más, como por ejemplo que el sistema no es asíncrono full-duplex, tal como lo describen indirectamente estos manuales, si no síncrono half-duplex, (más parecido a un I2C) ya que la línea etiquetada como "entrada de datos" es en realidad una línea de CLK, de reloj, además con lógica negativa, detalle que he podido comprobar con el osciloscopio.

...Esta información la he encontrado en varios sitios, como en esta entrada de GitHub, en que el autor experimenta con "Una interfaz y un emulador de teclado para el panel de alarma PC1550 de Digital Security Control"

Saludos

Llorens

Aunque la ayuda es menor, acá esta en versión PDF que puedas consultar tranquilamente.

Vista-120 Installation Manual ADEMCO

Y por esas cosas todo una serie de elementos que puedan ser útiles en tu búsqueda

Directorio dispositivos ADEMCO - Manuales

Link 1 para evaluar:
Bueno, he encontrado esto que tiene pinta de algo bueno.

PROTOCOL

Tal vez no sirva pero dice:

It is possible to send a message from a specific keypad on Ademco/Vista or to a specific partition on DSC.

Tu podrás evaluar si es o no de ayuda.

Link 2 para evaluar
También este comentario de un foro Ademco/Vista 20P Interface

donde se dice:

Its an Ademco Vista 20P.
It does not have a serial interface, it just has the keybus interface.

Creo que ya lo has encontrado porque algo mencionaste al respecto.

Y si fuera el caso dice:

Keybus is a proprietary protocol thats a modified RS485 protocol (its basically RS485 with clock signals). My solution was to drop an optocoupler into the circuit before adding my serial interface. Its slow data, 4800 bps (N81). The data is reversed, so be aware of that.

Y aquí un trabajo con keybus y Xbee

A ver si ayuda a tu propósito.

Gracias por los enlaces, Surbyte. He tardado en responder porque llevo un par de días con serios problemas con el foro Arduino. Me cuesta mucho entrar, debo insistir con usuario y contraseña cinco o seis veces, hasta que me reconozca, e incluso así, al pulsar un botón de enlace me salta a otro apartado distinto o me aparece el código HTML de la página en vez de ella misma... Y esto me ocurre con varios ordenadores distintos... En fin, raro...

Algunos enlaces pueden ser útiles, como el de protocolo, pero trata a nivel de códigos, no de señales que es lo que necesito. Ayer estuve haciendo pruebas con el analizador lógico Saleae, y la cosa está bastante confusa...

...Para empezar, el canal que se define como "reloj" presenta un comportamiento extraño, hay mucha actividad pero irregular, que encima no se corresponde en nada al canal de datos, en el que apenas aparece un frame de vez en cuando cuando le das una orden de disparo de alarma. Esto se complica porque al estar obligado a tener cinco módulos conectados en el bus de comunicaciones (el receptor de radio, la consola, la placa de relés y la centralita Ademco) es muy complicado averiguar de cuál de ellos salen las distintas señales...

Esta tarde probaré de sincronizar otros canales con eventos, como la pulsación del emisor de activación o el encendido del led de alarma, para poder identificar y separar señales útiles del "parloteo" entre módulos. Estaba pensando también en un posible sistema para averiguar el origen de las señales: colocando pequeñas resistencias en la entrada y salida de datos de un módulo, pero de un valor que no cambie el valor lógico de la señal, mediante un operacional que detecte el sentido de la caída de tensión se podría saber en "qué sentido" viaja la señal, si desde el propio módulo hacia los demás o al revés...

Sigo probando...

Saludos a todos

Llorens

Si, tienes razón. Mas tarde le di una leído un poco mas profunda y claro, no es la información que se busca. Esa información no debe estar disponible salvo en canales muy pequeños de técnicos y desarrolladores y que no han compartido dicha información. Habrá que hacer ingeniería inversa como estás haciendo.

Bueno, las lecturas con el analizador lógico Saleae están dando algunos resultados, aunque de momento algo confusos. Por ejemplo, el presunto canal de reloj, no es tal, es un canal de datos con todas las de la ley, donde parecen combinarse señales de sincronismo, con otras de dirección y otras de órdenes. Así que al margen de algunas descripciones que he encontrado en la red, el sistema no parece síncrono en absoluto...

En las siguiente imágenes, el canal 0 corresponde a la presunta línea de reloj (que no lo es), el canal 1 a la línea de datos (que tampoco lo es), y el 2 me indica la activación o desactivación del relé de alarma del módulo 4204, lo cual me permite distinguir los "frames" involucrados en su activación y desactivación...

Imagen a tamaño real

Aquí se distingue el frame de datos del canal 0, que parece generar una respuesta (siempre la misma) de 3 únicos impulsos en el canal 1. En el dos vemos el momento en que se activa el relé del módulo 4204, con la típica señal de los rebotes de los contactos...

Ahora mostraré el evento de apagar el relé, apenas unos segundos más tarde que el de activarlo...

Imagen a tamaño real]

Como la respuesta del canl 1 no cambia, fijémonos solamente en el canal 0 y de momento en los eventos de activación, de varios disparos más y siempre desde la misma "habitación", la 106, con lo cual en teoría los impulsos deberían ser iguales ....pero resulta que NO LO SON... Algunas partes sí, pero en otras aparece un corto grupo de 3 impulsos que no está presente en todos los disparos...

Imagen a tamaño real]

Claro, el problema es que no sabemos si todo el "frame" proviene del mismo módulo (se supone que del de la "centralita") o algún otro (el receptor de radio, la consola o el mismo 4204) ha insertado la diferencia.

Así que para poder deducir con más propiedad, voy a mirar de construir el sistema que comenté con operacionales que mediante la caída de tensión en pequeñas resistencias pueda diferenciarme el origen de los impulsos...

Continuará...

Saludos a todos

Llorens

Mientras sigo construyendo el detector diferencial de impulsos para saber de qué módulo concreto vienen en una línea común en que hay varios, muestro otra comparativa de señales. En este caso son "frames" de activación y desactivación correspondientes a las "habitaciones" 106 y la 107 (eso se refiere al tipo de alarma que daban al pulsar los avisadores de radio correspondientes), resaltando los fragmentos del "frame" que son distintos en cada caso sobre los que parecen siempre iguales en estas órdenes...

Observemos algo que ya he citado. En la activación de una alarma concreta hay dos tipos de señales distintas.

01_106_ON es la activación de la alarma 106, se ve un grupo de 3 impulsos muy breves, y luego una "palabra" de 6 impulsos de variado formato.

06_106_ON también es la activación de la alarma 106, en que los 3 impulsos se convierten en 1 y la "palabra" de 6 impulsos que viene a continuación es distinta a la anterior.

01_106_OFF es el "frame" que desconecta la alarma correspondiente a la activación 01_106_ON. Observar que también mantiene los 3 impulsos muy juntos y la "palabra" final, al ser una orden de apagado, es naturalmente distinta.

06_106_OFF es el frame que desconecta la alarma correspondiente a la activación 06_106_ON. En este caso copia el impulso único y la "palabra" también es distinta.

Seguidamente vienen las señales leídas para activaciones y desactivaciones de la alarma 107, en que se mantiene esta dualidad 3 impulsos - 1 impulso, de manera que parece bastante aleatoria, y naturalmente tiene sus propias "palabras", tanto de activación como de desactivación...

En todo caso tengo claro que el meollo del asunto tiene que estar en la "palabra" del final del "frame", que procedente de la centralita debe contener una dirección de placa y una orden específica... Así que una vez pueda certificar de qué módulos vienen estas señales, ya que es posible que el "frame" sea una superposición de varias de distinto origen, se tratará de medir con el analizador lógico Saleae los tiempos marca-espacio de cada señal y escribir un programa para Arduino que pueda imitar el "frame". Con un circuito driver adaptaría el formato TTL 0-5V del Arduino a 0-12 del Ademco y ver si el módulo 4204 responde con tanta alegría como lo hace con su propia centralita...

De todas formas, más que conseguir la activación mediante señales "copiadas", lo que me interesa es averiguar el protocolo completo de la "palabra" y poder sintetizar luego con Arduino cualquier otra señal de activación o desactivación para los módulos 4204...

...Del mismo modo estaría bien poder "leer" los códigos que vienen del receptor de radio UHF y los que van y vienen de la consola con el teclado y el display... pero eso ya son otros asuntos...

Continuará...

Saludos a todos

Llorens

Si hicieras una rutina basada en RCSwitch podrias decodificar eso, porque veo que si tomas el pulso mas corto como indicador de bit, pareciera leerse algo ahi. Es mas solo hay que sincronizarlo para descartar lo anterior.

Qué opinas?

Sí, es una buena idea, Surbyte, utilizar las señales más cortas como referencia de pasos de reloj y averiguar cuantos bits contiene la "palabra" significativa, pero antes debo "limpiar" esta secuencia de señales, que presuntamente procede de la placa principal, de las que puedan intercalar los otros módulos, que además es necesario que estén conectados a los dos buses porque si no no tengo manera de disparar el evento de alarma ni luego de detenerlo. Además está la incógnita de las señales distintas pero que hacen lo mismo... eso es lo que menos me cuadra... no es lógico.

...Cuando tenga claros estos temas podré realizar más pruebas, porque tengo 18 emisores (101-118) y de 5 módulos de relé 4204, con lo cual, supongo, dispondré de suficientes ejemplos para poder identificar las direcciones y las órdenes básicas...

Saludos

Llorens

Si, esta claro, yo hablo solo sobre lo que has marcado pero hay que SEPARAR todo lo que ahora parece basura que no lo es.

He seguido trabajando en el tema del análisis de datos Ademco y he construido algunos circuitos para ayudar a controlar el flujo en buses comunes...

El primero es la idea de utilizar una pequeña resistencia entre cada pin del módulo y el bus común entre ellos. El pin va además a la entrada + de un operacional LM324, y el - va al bus común... entonces, port la caída que provoca la resistencia, si la salida procede del pin siempre tendrá una tensión algo mayor que si procede del bus, y la salida del operacional sera a un 1, y si es al revés será un 0...

El circuito básico está cuadruplicado y por tanto puede procesar las señales de una línea de bus y cuatro módulos de manera simultánea...

Enlace directo a la imagen a tamaño normal

...Acabé el circuito, lo puse en marcha conectando el - común a la línea de "salida de datos" y los + a los pines de igual nombre de los cuatro módulos: central, 4204, receptor y consola, y la sorpresa fue que no parecía hacer nada, el canal Saleae 0 correspondiente a la placa Central siempre estaba alto y los restantes siempre bajos. Las salidas del operacional no respondían además a los datos digitales...

Pensando un poco llegué a la conclusión que era normal que no salieran las señales digitales en la salida de los operacionales, puesto que sea cual sea el módulo que genera una señal hacia el bus, la tensión de la entrada + siempre será proporcionalmente mayor a la - ...Entonces, el hecho que el resultado del pin de salida de datos de la Central siempre estuviera a 1 podía indicar que era un bus direccional, en que estas placa habla y el resto de módulos escuchan, algo similar al MOSI del protocolo SPI, aunque en este caso asíncrono...

Para certificar si estas suposiciones eran acertadas o era un mal funcionamiento imprevisto del circuito, construí otro más sencillo, sin operacionales, sólo con diodos y algunas resistencias de descarga...

Enlace directo a la imagen a tamaño normal

Si los buses eran realmente unidireccionales, los diodos deberían poder discernir y separar los datos de cada módulo, y por tanto analizar el destino de las órdenes, su respuesta por el bus "entrada de datos" y la acción externa que el módulo realice...

En la siguiente imagen se observan más detalles sobre este nuevo circuito, que de certificar lo que pienso aún podrá reducirse más... Las resistencias de 1 K son para evitar que si la entrada de un módulo es de alta impedancia o tipo MOS, el diodo cargue el "condensador" impidiendo que este regrese a valores de señal 0, con lo cual el módulo dejará de responder...

Enlace directo a la imagen a tamaño normal

Pues bien, ayer noche realicé las primeras pruebas y el resultado coincide con lo que pensaba. El bus "salida de datos" sólo es de envío de señales desde la placa Central al resto de módulos, los cuales contestan todos ellos a través del bus "entrada de datos", son en efecto buses direccionales. De tal manera que enviando al canal Saleae 0 la "salida de datos" y al Saleae 1, 2 y 3, las "entradas de datos" correspondientes al receptor, a la consola y a la placa de relés 4204, puede diferenciarse perfectamente el tráfico de órdenes-respuestas...

He podido ver las órdenes de interrogación del receptor, el intercambio de datos entre la Central y la consola, y entre la central y el módulo de relés... De todas formas, no todos los tipos de pregunta-respuesta están demasiado claros, de vez en cuando hay intercambios que no coinciden con eventos externos, cuyo sentido también deberá resolverse...

Continuará...

Saludos a todos

Llorens

Con los datos obtenidos a partir de los dos circuitos anteriores, he montado un tercero que supongo será definitivo. De hecho es más sencillo, ya que consta de tan sólo tres diodos y unas pocas resistencias adaptadoras de nivel.

Una vez constatado que los buses son unidireccionales, como los MOSI y MISO del protocolo SPI, aunque sin línea de reloj ni de CS, el denominado "Salida de datos", equivalente al MOSI (Master Output Slave Input) estará conectado directamente al resto de los módulos, ya que la señal sólo puede provenir de "master", es decir, de la placa de la centralita...

...En cambio los "retornos" del resto de módulos hacia la línea "Entrada de datos" de la Centralita van a una OR formada por tres diodos, y por tanto en cada ánodo tenemos exclusivamente la señal procedente de cada módulo: el receptor, la consola o la placa de relés.

Así el analizador lógico Saleae puede grabar simultáneamente las señales digitales de cinco canales distintos:

  • MOSI de la Centralita hacia el resto de módulos (Salida de datos)
  • MISO "retorno" general del resto de módulos (Entrada de datos)
  • MISO sólo del Receptor
  • MISO sólo de la Consola
  • MISO sólo del módulo de salida de relés 4204
  • Activación de un relé determinado del 4204

El Saleae conectado al circuito...

...Y todo el conjunto conectado a los módulos...

Los datos obtenidos se identifican muy bien, pero intentar averiguar los códigos binarios a partir de la imagen del Saleae en muy tedioso y es fácil equivocarse. Para intentar simplificarlo me he hecho una imagen en forma de plantilla gráfica con columnas semitransparentes que puede ser superpuesta a la imagen de la señal a analizar través del Photoshop y que a igual resolución marca los tiempos cada 0,21 mS, que corresponde más o menos al impulso de reloj que he detectado visualmente en las señales Ademco, pero al final resulta igualmente engorroso, por este motivo he pensado en un sistema automático a partir de hardware-sofware para decodificarlas y también poder reproducirlas y enviarlas a los módulos...

El Saleae también puede exportar los datos gráficos en formato numérico "cvs" (datos separados por comas), que pueden ser abiertos con el Excel o incluso con el block de notas. En estos datos se basan en los cambios de nivel de la señal y contienen los valores de tiempo en segundos con 6 decimales, contados desde el inicio de la grabación o bien desde un fragmento acotado por marcadores, y la transición que ocurre en cada uno de ellos, si es un 0 o un 1.

...Mi idea es enviar estos datos al Arduino vía serie mediante un programa de Visual Basic (que ya tengo a medio hacer) y que el programa de Arduino genere luego el "frame" digital correspondiente con una resolución de pulsos de al menos 0,01 mS, utilizando para ello la reprogramación de los temporizadores internos. Luego sólo hará falta cambiar los niveles de TTL 0-5 V a 0-12 Volts e insertar tales señales en los módulos a controlar para ver cómo responden...

...Así que es éstas estoy...

Continuará...

Saludos a todos

Llorens