Protocolo de control muy simple

El Very Simple Control Protocol ( VSCP ) ^{[ 1 ]} es un protocolo de automatización gratuito adecuado para todo tipo de tareas de automatización donde la automatización de edificios o del hogar es el foco principal.

Su principal ventaja es que cada nodo VSCP puede funcionar de forma completamente autónoma, formando parte de una red distribuida de otros nodos.

VSCP es independiente de la capa física (por ejemplo, bus CAN , Ethernet , RS-485 , RS-232 , MiWi ) que conecta los nodos individuales para formar el bus de la red de automatización. En el bus pueden existir nodos que lean interruptores, controlen la iluminación , persianas , ventanas o pantallas de información, transmitan mediciones físicas (por ejemplo, temperatura , luminosidad , consumo de energía, etc.), controlen multimedia , alarmas antirrobo o contra incendios , etc.

Existe un subconjunto del protocolo (Nivel I) específicamente diseñado para el bus CAN y microcontroladores con recursos limitados . El Protocolo de Nivel II está diseñado para las capas físicas Ethernet (UDP, TCP y su propio protocolo Ethernet sin procesar ) e inalámbricas. Todos comparten los mismos campos de mensajes y estructura, y pueden conectarse mediante pasarelas.

VSCP se basa en eventos . Cada vez que ocurre un evento , se transmite a todos los demás nodos. Cada nodo de la red recibe el evento y decide si debe procesarlo o no.

El ejemplo que se muestra en el diagrama describe la pulsación de un botón. Esto provoca que el nodo 1 envíe un mensaje de evento al bus, informando a los demás nodos que se ha pulsado el botón. El nodo 2 recibe el mensaje, pero decide que este botón no debe activar un evento para él. El nodo 3 recibe el mensaje y decide que este botón debe encender la lámpara 2.

Pueden producirse eventos por diversos motivos: pulsar un botón, activarse un sensor de presencia o la puesta de sol. También pueden enviarse eventos periódicamente, como por ejemplo, una lectura de temperatura cada minuto. VSCP predefine muchos eventos posibles, clasificados en clases y tipos. La matriz de decisión (DM, por sus siglas en inglés) determina si un evento recibido debe gestionarse o no. La DM se explica con más detalle a continuación.

Los eventos se organizan en clases . Una clase es una colección de eventos que están relacionados de alguna manera. Hay clases para ALARMA , MEDICIONES , CONTROL , INFORMACIÓN , etc. Actualmente, VSCP especifica unas 25 clases, pero tiene espacio para muchas más. Cada clase se subdivide a su vez en tipos . Un tipo especifica aún más el evento dentro de la clase. Por ejemplo, los eventos de la Clase 20 (0x14) son eventos de INFORMACIÓN . En esta clase hay un subtipo 1 (0x01) BOTÓN que señala que se ha pulsado un botón. En esta misma clase de INFORMACIÓN también hay tipos para señalar ENCENDIDO , APAGADO , POR DEBAJO DEL LÍMITE , etc. Del mismo modo, en la clase de mediciones hay tipos para señalar temperatura, corriente, voltaje, etc. Tener todas estas clases y tipos definidos hace que los nodos hablen el mismo idioma. Para obtener una lista completa de las clases y tipos predefinidos, consulte la wiki de VSCP.

Los eventos que se transmiten contienen varios campos que, en conjunto, forman un datagrama VSCP. La forma exacta en que estos campos se asignan a la capa física está especificada para varios protocolos de capa física, como CAN, Ethernet, TCP, etc. Para otros, aún no está definida, pero en general no es difícil asignar estos campos a un protocolo de capa física. Existen dos niveles del protocolo VSCP: NIVEL I y NIVEL II . Ambos son básicamente el mismo protocolo, pero difieren en el tamaño de los distintos campos.

El nivel I está diseñado para ejecutarse en nodos con recursos más limitados y los campos se definen de forma un poco más conservadora. De hecho, el nivel I es un subconjunto del nivel II y, con una puerta de enlace adecuada, los eventos pueden transitar entre una red de nivel I y una de nivel II.

El nivel II está diseñado para ejecutarse en nodos con pocas limitaciones de recursos y que puedan gestionar fácilmente mensajes de mayor tamaño.

Cuando un nodo recibe eventos, debe determinar si necesita ejecutar una tarea en función de dicho evento. Esto se logra evaluando la matriz de decisión (MD). La matriz MD se compone de varias condiciones del tipo SI... ENTONCES... Cada condición SI/ENTONCES se denomina línea , y varias líneas conforman la matriz de decisión.

La clase y el tipo del mensaje entrante siempre se evalúan mediante una línea DM. La evaluación de la clase y el tipo se realiza pasando primero la clase/tipo a través de una máscara y luego comparándola con un filtro. Este método permite que múltiples clases/tipos activen una condición válida para una línea del DM. Las demás condiciones para la línea DM (SenderGUID, Zona, Subzona) se evalúan opcionalmente. Si la línea DM es válida, se ejecuta la ACCIÓN . Junto con la ACCIÓN hay un parámetro de ACCIÓN . Un ejemplo de ACCIÓN sería: activar el relé 6, donde 6 es el parámetro de acción . Las ACCIONES exactas que puede realizar el nodo receptor vienen determinadas por el diseño del propio nodo. Corresponde al desarrollador del firmware definir qué acciones se pueden ejecutar. Al documentar la acción posible en el archivo MDF (véase más adelante), el software de configuración sabrá cómo seleccionar esta acción. El DM se puede modificar configurando los registros de configuración del nodo correspondientes. Una forma práctica de hacerlo es mediante el software de configuración VSCPWorks.

Un evento enviado también puede contener una carga útil de datos. El contenido y la organización de esta carga útil dependen de la clase y el tipo de evento. Por ejemplo, un evento de clase 10 (medición) y tipo 6 (temperatura) contendrá los datos de temperatura (con codificación determinada por el byte 0, grados o Celsius) en su carga útil. Un evento de botón contendrá información sobre el botón y su zona/subzona en su carga útil de datos. Para cada clase/tipo, el formato de datos se define en la especificación; consulte la wiki para obtener más detalles.

Algunos eventos (bastantes) contienen una zona de campo y una subzona de campo en su carga útil de datos. Esta funcionalidad permite agrupar nodos . Por ejemplo, podríamos determinar que todos los botones que controlan una lámpara específica pertenecen al mismo grupo. Esto simplifica el DM en ciertos escenarios. En lugar de tener una línea DM como nodo de lámpara para cada botón (1 línea por botón: SI botón x entonces encender lámpara), podríamos tener una sola línea DM que diga SI (coincidencia de zona) ENTONCES encender lámpara . La creación de varios interruptores de nodo en un grupo se realiza configurando los nodos; el firmware del nodo admitirá esta funcionalidad.

Un nodo debe configurarse adecuadamente antes de ejecutar su función. Cada nodo VSCP proporciona su propio conjunto de registros de configuración adaptados a su función. Un nodo de botón tendría la posibilidad de configurar la zona o subzonas a las que pertenecen los botones. Un nodo de temperatura tendría la posibilidad de establecer valores de activación. La configuración del DM también forma parte de la configuración del nodo.

La configuración de un nodo se realiza escribiendo en los registros . Cada nodo (Nivel I) proporciona acceso a 256 registros. Los 128 registros superiores están reservados para las funciones principales de VSCP. En estos 128 registros encontramos elementos como el GUID del nodo, el alias, el MDF y un registro de paginación. Los 128 registros inferiores están disponibles para uso específico de la aplicación. Si 128 registros no son suficientes, existe la posibilidad de paginación de 16 bits. Esto permite 65536 x 128 registros de 8 bits para uso de la aplicación. La escritura/lectura de estos registros se realiza mediante eventos de CLASE 0. Los eventos de Clase 0 son mensajes de funcionalidad del protocolo VSCP destinados a la configuración y gestión de nodos.

Controlar qué registro cumple qué función puede ser un desafío, especialmente para los registros específicos de la aplicación. Aquí es donde entra en juego el archivo de descripción del módulo (MDF). El archivo MDF es un archivo XML legible por máquina que describe la función de cada registro de un módulo, proporcionando las opciones de configuración para dicho registro, etc. Este archivo es utilizado por el software de configuración (VSCPWorks) para mostrar las opciones de configuración específicas del módulo. El archivo MDF puede almacenarse en el propio nodo y VSCPWorks lo recupera desde allí, pero lo más común es que el archivo MDF sea un archivo XML alojado en un servidor web. El nodo solo necesita informar a VSCPWorks dónde se encuentra el archivo XML (URL). Esta URL está presente en los registros reservados de VSCP 0xE0-0xFF.

VSCPworks es una herramienta para PC (Linux y Windows) que permite configurar y administrar los nodos. VSCPworks permite leer y modificar registros, presentándolos en un formato legible mediante el análisis automático del archivo MDF. Además, VSCPworks proporciona asistentes para configurar la matriz de decisión.

Si VSCP es el protocolo, VSCP & Friends se utiliza para nombrar una API de software, un esquema y una capa de abstracción construidos en torno a VSCP. VSCP & Friends permite abstracciones por capas de dispositivos heredados mediante el uso de controladores que los hacen parecer dispositivos VSCP. Esto significa que cualquier dispositivo puede ser controlado y monitoreado con el marco de VSCP & Friends. VSCP & Friends resuelve cuatro problemas comunes de IoT y M2M.

• Detección e identificación uniforme de dispositivos.
• Configuración uniforme del dispositivo.
• Funcionalidad de dispositivos autónomos/distribuidos.
• Método uniforme para actualizar/mantener el firmware del dispositivo.

• Página principal del proyecto VSCP
• Especificación VSCP
• Documentación de VSCP
• Módulos VSCP