IoTPBX

This is IoTPBX for all!

El "Core" Telemetry/Telecontrol es la funcionalidad embebida construida aprovechando las propiedades de VoIP Asterisk que nos permite ahora presentar el concepto IoTPBX a continuación

Con IoTPBX se logra obtener una red distribuida de puntos de comando/supervisión (la tecla de un teléfono/softphone) y que actúa finalmente sobre los diferentes dispositivos conectados a las plataformas IoT comerciales existentes dentro de muchos ambientes, tales como espacios Médicos/Salud, Laborales, Fábricas, Universidades, Oficinas, Comercio, Hoteles, Residencias, etc.

A continuación se expone el proceso de Diseño/Construcción de una aplicación posible.

Cómo controlar las luminarias Philips con Webhooks, desde el ecosistema PABXControl Asterisk Guardian V5.0?

Introducción

Aquí vamos a desarrollar un modelo básico o arquitectura inicial para la implementación de una aplicación IoTPBX basados en el entorno Telemetry/Telecontrol de PABXControl Asterisk Guardian

Descripción

Mediante las mismas funciones Telemetry/Telecontrol construidas dentro del ecosistema Asterisk Guardián que se encuentran ya en uso y que se han visto en la última presentación de vídeo (lanzamiento de la versión bilingue 5.0) para uno de los Modos de Marcación del Dialer, también se tenía ya previsto, un entorno de IoT que le da soporte a señalización de control/supervisión de dispositivos y el envió de Mensajes o Alarmas desde el usuario a sistemas externos varios/múltiples (Node-RED, IFTTT, Zapier, etc)

Estando así internamente ya desarrollado el entorno de Telemetría/Telecontrol, se presenta el siguiente escenario posible de DEMO, como un primer CASO DE APLICACIÓN, de forma tal que usando las extensiones como comando de control/supervisión (Teclas con número almacenado), el IP-PBX Asterisk como medio de recolección/transmisión del comando/supervisión y la aplicación PABXControl Asterisk Guardián como Gateway/Administrador, es posible realizar diferentes implementaciones según sea el caso, y este primer demo para controlar luminarias/dispositivos inteligentes Philips, accediendo con llamados Webhooks a su servidor API RESTful (Hue bridge interface Philips) nos dará una idea de lo conveniente de la implementación y los posibles beneficios que contribuirán muy fácilmente al mejor uso energético, el ahorro de recursos tan valiosos hoy día y una nueva cultura de la preservación.

La finalidad del modelo implementado ahora, es conseguir control de las luminarias inteligentes (u otros de IoT) dentro de las oficinas de una empresa, o en un SOHO (Small Office/Home Office), y todo desde una tecla del dispositivo telefónico o softphone.

Teoría Básica

Todo sistema IoT de marca comercial actualmente tiene su componente de Bridge/Gateway o dispositivo para proveer un servicio web con interfaz RESTfull que permite controlar todos los devices IoT presentes asociados y controlados por él (para cada marca o varias marcas), y puede recibir comandos de control/supervisión a los devices mediante el registro al sistema web y el envió de llamados Webhooks parametrizados.

PABXControl Asterisk Guardián con su entorno Telemetry/Telecontrol puede recibir/recolectar señalización telefónica almacenada como paquetes de números desde cualquier extensión telefónica como un "COMANDO TELEMETRY", aportando además un entorno administrado y seguro que deja rastros de toda transacción dentro de sus archivos detallados de llamada, pudiendo ser factible para generar seguimientos y reportes del uso.

Al mismo tiempo, dispone de la capacidad de envío asincronico de llamados Webhooks y su correspondiente tratamiento de buffer para garantizar siempre la entrega confiable de la información a su destino en tiempo real, todo con un protocolo definido en los archivos de configuración de la aplicación.

Cada aplicación o caso de uso, #DEMO1 por ahora, debe definir un rango de "numeración Telemetry" a usarse, dentro de todo el disponible, por ejemplo:

RANGO TOTAL TELEMETRY EXISTENTE

Rango Inicial :0#######

Rango Final :9#######

RANGO DEFINIDO (ya ocupado)

SupraDialer

Rango Inicial :50000001

Rango Final :50000003

ASIGNACIÓN DE RANGO PARA #DEMO1

HuePhilips (Mil comandos)

Rango Inicial :60000000

Rango Final :60000999

El acceso a estas funcionalidades estará controlado por un archivo de configuración (parcialmente puede ser el INI), que definirá:

- Qué extensiones/"Usuarios" pueden acceder a la generación del marcado del "comando" dentro de la Aplicación #DEMO1, por ejemplo: "101,102,103"

- "Auth.Code" para #DEMO1, será un código de acceso de 5 dígitos que va como prefijo al comando y da acceso a la Aplicación #DEMO1.

Lo anterior en equivalencia a los mismos principios aplicados para la funcionalidad del Dialer y que ya vimos en vídeo!.

Definición de una Tabla de Conversión Telemetry/Telecontrol "ManagerIoT" ( en esencia { Comando : JSONWebhook} )

Cada aplicación, como #DEMO1 en este caso, qué se define exclusivamente para devices IoT Philips, será una SECCIÓN dentro de una "tabla/archivo" de arquitectura similar a la empleada en la funcionalidad "Cazador/Hunter", donde los parámetros en columnas son:

Líneas dentro del Archivo de configuración "ManagerIoT" para la aplicación #DEMO1

<#DEMO1>

;Comandos de establecimiento de sesión y otros...

TlmtryCnfg1 : CmdCnfg1 : LnkAddress : Body : Method : TypeWebRtrn : OptionFnctn : ValueWebRtrn

TlmtryCnfg2 : CmdCnfg2 : LnkAddress : Body : Method : TypeWebRtrn : OptionFnctn : ValueWebRtrn

TlmtryCnfg3 : CmdCnfg3 : LnkAddress : Body : Method : TypeWebRtrn : OptionFnctn : ValueWebRtrn

TlmtryCnfg4 : CmdCnfg4 : LnkAddress : Body : Method : TypeWebRtrn : OptionFnctn : ValueWebRtrn

TlmtryCnfg5 : CmdCnfg5 : LnkAddress : Body : Method : TypeWebRtrn : OptionFnctn : ValueWebRtrn

;

;Comandos de control

TlmtryCmmnd1 : CmdName1 : LnkAddress : Body : Method : TypeWebRtrn : OptionFnctn : ValueWebRtrn

TlmtryCmmnd2 : CmdName2 : LnkAddress : Body : Method : TypeWebRtrn : OptionFnctn : ValueWebRtrn

TlmtryCmmnd3 : CmdName3 : LnkAddress : Body : Method : TypeWebRtrn : OptionFnctn : ValueWebRtrn

TlmtryCmmnd4 : CmdName4 : LnkAddress : Body : Method : TypeWebRtrn : OptionFnctn : ValueWebRtrn

TlmtryCmmnd5 : CmdName5 : LnkAddress : Body : Method : TypeWebRtrn : OptionFnctn : ValueWebRtrn

;etc...

<END_#DEMO1>

Así, se planifican dos clases de procedimientos:

- Webhooks de Configuración

TlmtryCnfg# : CmdCnfg# : LnkAddress : Body : Method : TypeWebRtrn : OptionFnctn : ValueWebRtrn

- Webhooks de Comando

TlmtryCmmnd# : CmdName# : LnkAddress : Body : Method : TypeWebRtrn : OptionFnctn : ValueWebRtrn

Donde son de interés general por ahora los campos

* TlmtryCnfg#, comandos regulares recibidos como paquete de números ("########") para configurar o inicializar el acceso al servidor IoT, en este caso Hue Philips

* CmdCnfg#, Nombre asignado al comando de configuración para identificar en reportes de los accesos al sistema IoT (Ej: "Registro IoT", "Sesión IoT", etc.)

* TlmtryCmmnd#, comandos regulares recibidos como paquete de números ("########") para el cambió de estado de un dispositivo IoT, en este caso Hue Philips

* CmdName#, Nombre asignado al comando de cambio de estado para identificar en reportes de los accesos al sistema IoT (Ej: "Luminaria Ofic. ABC Encendida", etc.)

* LnkAddress, Link básico del procedimiento o llamado Webhook, puede incluir un Token de acceso/autorización del usuario al sistema, y la ruta relacionando el recurso (dispositivo IoT) y el atributo sobre el que se actuará

* Body, carga de datos a aplicar en el procedimiento

* TypeWebRtrn, OptionFnctn, ValueWebRtrn, son para asegurar la comprobación de que el comando ha sido aceptado en el sistema servidor Hue Philips y opcionalmente si existe alguna tarea/función adicional a realizarse por ManagerIoT

Ejemplo básico de un comando para encender una luminaria

Address https://<IP address>/api/<username>/lights/1/state

Body {"on":True}

Method PUT

Conclusiones

De esta forma con el archivo "ManagerIoT" de configuración para la aplicación "#DEMO1" se integra el entorno IoTPBX de PABXControl A.G con cualquier sistema IoT existente, es éste caso demo con Bridge Hue Philips.

Con lo anterior en mente, esta es la arquitectura usada para controlar directamente Hue Philips y todos los diferentes dispositivos asociados y controlados por el.

No olvidar que adicionalmente en el ámbito Telemetry existe la capacidad de señalización de Alarmas o Mensajes "despachados" por la interacción humana para ser desplegados en donde se considere, o integrados con los sistemas IoT para compartir con otros la Alarma o el Mensaje, y claro, esto debe tener su propia especificación dentro del archivo de configuración "ManagerIoT"

Así, el concepto de IoTPBX para PABXControl Asterisk Guardián llega a su plena realización y puede servir a múltiples fines dentro de escenarios similares u otros, industriales, etc.

La integración a través de Node-RED puede dar una mucho mayor escala de control, por ejemplo, al interactuar directamente con Google Assistant que puede controlar Google Home y otros..., y de esta forma, ofrecer una mayor disponibilidad a cualquier recurso desde la tecla de un teléfono o softphone en Asterisk VoIP

Esto es IoTPBX con Asterisk VoIP y PABXControl Asterisk Guardián!

Y puede representar una forma apreciable de ahorro, una nueva forma de integración para contribuir a la conservación y el mejor uso energético y de recursos y además ayudar en la creación de una nueva conciencia y cultura en la oficina corporativa, en la oficina en casa, en la fábrica, la industria, el comercio, el hotel, la universidad o cualquier dependencia humana donde se disponga comunicaciones con Asterisk VoIP.

Lo invitamos a que participe en la evolución del sistema!

Es Bienvenido!

Presentación IoTPBX Ver1.0!

Presentamos la primera versión del nuevo entorno IoTPBX construido a partir del prototipo de especificación previo.

Componentes de Entorno IoTPBX Ver1.0:

1.- Control de todos las luminarias y dispositivos actuadores Philips con Webhooks, desde el ecosistema PABXControl Asterisk Guardian V6.0

2.- Sistema de Información de Alarmas y Mensajes en Web o EBoard (Pizarra Electrónica)

Introducción

Avanzando sobre lo ya visto en la sección anterior del Diseño/Construcción de una aplicación posible, aquí vamos a exponer los resultados de la implementación realizada que cumple con todos los requerimientos previos pero que se ha simplificado y consolidado en beneficio de la funcionalidad y desempeño en varios aspectos.

Se ha decidido asumir como un todo ambos entornos, el de control de dispositivos IoT y el de generación de Alarmas y Mensajes, que aunque tienen a la fecha destinos previstos diferentes (el primer entorno dedicado a los Devices IoT en el Hue Bridge Philips y el segundo entorno potenciando una Web o panel de Visualización de Alarmas y Mensajes) pueden ser ambos configurados dentro de un mismo entorno ÚNICO, para los efectos de usar una más integral señalización e identificación y reportes de todos los eventos que procuren los usuarios autorizados sobre ambos entornos del sistema IoTPBX.

Bajo este marco de referencia único se pueden controlar también incontables Hue Bridge Philips según su capacidad de sistema en la red LAN, y disponer también varios subsistemas de visualización o Panel Web o EBoard, o mezclar varios sistemas IoT de diferentes marcas, quitando así limitantes innecesarios e indeseados y potenciando el crecimiento y la mejor utilización del sistema.

Y como se ha logrado tal integración y simplificación?

Dejemos que los datos hablen... (Si tiene alguna duda o comentario, no dude en contactarnos!)

Para descarga "ManagerIoT.txt:

Archivo de configuración funcional para el entorno IoTPBX V1.0 (en PDF)

Vista de archivo "ManagerIoT.txt"

; PABXControl-NGX (www.pabxcontrol.com); Archivo de Configuración de IoTPBX "ManagerIoT.txt", Ver 1.0; Este archivo permite convertir comandos del ámbito Telemetry en JSONWebhooks ; de forma que para cada comando se obtiene una acción sobre un Device IoT; o se envía un Mensaje o una Alarma a un sistema de Visualización o Web (Eboard/Pizarra Electrónica).;;"ManagerIoT.txt";Esta es la tabla de definición para la conversión Comando Telemetry/Telecontrol -> Llamado Webhook;en esencia {Comando:JSONWebhook};Para dar la mayor libertad de uso de caracteres en este ámbito IoT, se usan los siguientes caracteres;Como comentario ";";Como separador de campo "~" (Alt126);;Cada aplicación implementada según el sistema IoT a integrar puede tener diferentes comando y webhooks;pero la filosofía de construcción y aplicación es la misma.;;Descripción Conceptual General:;Líneas dentro del Archivo de configuración "ManagerIoT" para la aplicación #DEMO1;Comandos de establecimiento de sesión y otros...;=================================================;TlmtryCnfg1 ~ CmdCnfg1 ~ IoTType ~ LnkAddress ~ Body ~ Method ~ WebRtrnType ~ OptionFnctn ~ WebRtrnValue ~ Opt.BodyTogle#1 ~ Opt.BodyTogle#2 ~ Opt.BodyTogle#3;TlmtryCnfg2 ~ CmdCnfg2 ~ IoTType ~ LnkAddress ~ Body ~ Method ~ WebRtrnType ~ OptionFnctn ~ WebRtrnValue ~ Opt.BodyTogle#1 ~ Opt.BodyTogle#2 ~ Opt.BodyTogle#3;TlmtryCnfg3 ~ CmdCnfg3 ~ IoTType ~ LnkAddress ~ Body ~ Method ~ WebRtrnType ~ OptionFnctn ~ WebRtrnValue ~ Opt.BodyTogle#1 ~ Opt.BodyTogle#2 ~ Opt.BodyTogle#3;TlmtryCnfg4 ~ CmdCnfg4 ~ IoTType ~ LnkAddress ~ Body ~ Method ~ WebRtrnType ~ OptionFnctn ~ WebRtrnValue ~ Opt.BodyTogle#1 ~ Opt.BodyTogle#2 ~ Opt.BodyTogle#3;TlmtryCnfg5 ~ CmdCnfg5 ~ IoTType ~ LnkAddress ~ Body ~ Method ~ WebRtrnType ~ OptionFnctn ~ WebRtrnValue ~ Opt.BodyTogle#1 ~ Opt.BodyTogle#2 ~ Opt.BodyTogle#3;;Comandos de control;====================;TlmtryCmmnd1 ~ CmdName1 ~ IoTType ~ LnkAddress ~ Body ~ Method ~ WebRtrnType ~ OptionFnctn ~ WebRtrnValue ~ Opt.BodyTogle#1 ~ Opt.BodyTogle#2 ~ Opt.BodyTogle#3;TlmtryCmmnd2 ~ CmdName2 ~ IoTType ~ LnkAddress ~ Body ~ Method ~ WebRtrnType ~ OptionFnctn ~ WebRtrnValue ~ Opt.BodyTogle#1 ~ Opt.BodyTogle#2 ~ Opt.BodyTogle#3;TlmtryCmmnd3 ~ CmdName3 ~ IoTType ~ LnkAddress ~ Body ~ Method ~ WebRtrnType ~ OptionFnctn ~ WebRtrnValue ~ Opt.BodyTogle#1 ~ Opt.BodyTogle#2 ~ Opt.BodyTogle#3;TlmtryCmmnd4 ~ CmdName4 ~ IoTType ~ LnkAddress ~ Body ~ Method ~ WebRtrnType ~ OptionFnctn ~ WebRtrnValue ~ Opt.BodyTogle#1 ~ Opt.BodyTogle#2 ~ Opt.BodyTogle#3;TlmtryCmmnd5 ~ CmdName5 ~ IoTType ~ LnkAddress ~ Body ~ Method ~ WebRtrnType ~ OptionFnctn ~ WebRtrnValue ~ Opt.BodyTogle#1 ~ Opt.BodyTogle#2 ~ Opt.BodyTogle#3;etc...;;;Así, se planifican dos clases de procedimientos:;;Webhooks de Configuración;==========================;TlmtryCnfg# ~ CmdCnfg# ~ IoTType ~ LnkAddress ~ Body ~ Method ~ WebRtrnType ~ OptionFnctn ~ WebRtrnValue ~ Opt.BodyTogle#1 ~ Opt.BodyTogle#2 ~ Opt.BodyTogle#3;Para efectos prácticos en esta Ver 1.0, y dada la diferencia que todos los sistemas IoT puedan establecer en su configuración básica, la cual es muy sencilla,;no se desarrolla aquí el componente de Configuración (que es de UNA SOLA VEZ!), pero los datos obtenidos de ella, para el caso de Hue Bridge Philips, ;son plenamente usados en los Comandos a continuación y no existen a primera instancia requerimientos adicionales pendientes.;;Webhooks de Comando;====================;TlmtryCmmnd# ~ CmdName# ~ IoTType ~ LnkAddress ~ Body ~ Method ~ WebRtrnType ~ OptionFnctn ~ WebRtrnValue ~ Opt.BodyTogle#1 ~ Opt.BodyTogle#2 ~ Opt.BodyTogle#3;;Donde son de interés general por ahora los campos;TlmtryCnfg#, comandos regulares recibidos como paquete de números ("########") para configurar o inicializar el acceso al servidor IoT, en este caso Hue Philips;CmdCnfg#, Nombre asignado al comando de configuración para identificar en reportes de los accesos al sistema IoT (Ej: "Registro IoT", "Sesión IoT", etc.);TlmtryCmmnd#, comandos regulares recibidos como paquete de números ("########") para el cambió de estado de un dispositivo IoT, en este caso Hue Philips;CmdName#, Nombre asignado al comando de cambio de estado para identificar en reportes de los accesos al sistema IoT (Ej: "Luminaria Ofic. ABC Encendida", etc.);IoTType, define o declara un Tipo para el procedimiento según su finalidad, por ejemplo se adopta de default:;-"None"/"Dvc"/"Alrm"/"Msg";-"None" no es un valor a explicitar aquí, pero será un valor de búsqueda en filtros IoTPBX para localizar una marcación de usuario NO DOCUMENTADA!!!;-"Dvc" equivale a "Device", para interactuar con Sistemas IoT, y se puede discriminar entre Configuración y Comando, por ejemplo, "DvcCnfg", "DvcCmd";-"Alrm" equivale a "Alarm", si es un mensaje o señalización de máxima prioridad;-"Msg" equivale a "Message" para un mensaje regular;LnkAddress, Link básico del procedimiento o llamado Webhook, puede incluir un Token de acceso/autorización del usuario al sistema, y la ruta relacionando el recurso (dispositivo IoT) y el atributo/propiedad sobre el que se actuará ;Body, carga de datos a aplicar en el procedimiento;Method, Metodo del llamado Web (GET, POST, PUT);WebRtrnType, OptionFnctn, WebRtrnValue, son para asegurar la comprobación de que el comando ha sido aceptado en el sistema servidor Hue Philips y opcionalmente si existe alguna tarea/función adicional a realizarse por ManagerIoT;-el valor adoptado de default para los parámetros de la línea anterior es: ~1~0~{"success":true};"WebRtrnType" equivale al tipo de la respuesta obtenida en el llamado Webhook, existen 3 (tres) tipos:;-"0" o "" indica que la evaluación de la respuesta al Webhook no será dada, y siempre se da por confirmada la recepción del Webhook;-"1" indica que la evaluación de la respuesta al Webhook está determinada por una igualdad con el parámetro "WebRtrnValue" para declarar recepción del Webhook.;-"2" indica que la evaluación de la respuesta al Webhook solo requiere que la cadena contenga el parámetro "WebRtrnValue" para declarar recepción del Webhook.;Opt.BodyTogle#1, Opt.BodyTogle#2, Opt.BodyTogle#3, Parámetros opcionales de Body que se alternan de forma cíclica, por ejemplo, un solo comando puede prender y apagar, alternando.;Observación: el mezclar estados como encendido y apagado en un mismo comando, genera indefinición en el seguimiento, luego se aconseja que la alternancia se use por ejemplo para intensidad y otros como color, etc.;por ejemplo, de forma tal que el comando de Encendido tenga como alternancia luminosidad baja, media, alta, podría ser un caso de uso.;queda bajo responsabilidad de la forma de configuración en los opcionales de Alternancia/togle (1-3) la eficiencia de supervisión en los reportes.;Se cargan en configuración los valores opcionales de Alternancia/Togle (1-3) NO VACIOS, y se interrumpe la carga si alguno de los valores de izquierda a derecha es vacío.;;Ejemplo básico de un comando para encender una luminaria;Command :60000011;Address :https://<IP address>/api/<username>/lights/1/state;Body :{"on":true};Method :PUT;Lo que en configuración veríamos como:;60000011 ~ LightOn ~ DvcCmd011 ~ https://10.10.11.20/api/usernamex/lights/1/state ~ {"on":true} ~ PUT ~ 1 ~ 0 ~ {"success":true} ~ ~ ~ ;60000012 ~ LightOff ~ DevCmd012 ~ https://10.10.11.20/api/usernamex/lights/1/state ~ {"on":false} ~ PUT ~ 1 ~ 0 ~ {"success":true} ~ ~ ~ ;;Samples/Muestras;Se puede establecer cualquier definición para un comando, incluso se pueden duplicar en la acción, pero claro, ello en detrimento de unos reportes más certeros.;60000001 ~ LightOn ~ DvcCmd001 ~ https://10.10.11.20/api/usernamex/lights/1/state ~ {"on":true} ~ PUT ~ 1 ~ 0 ~ {"success":true} ~ ~ ~ ;60000011 ~ LightOn ~ DvcCmd011 ~ https://10.10.11.20/api/usernamex/lights/1/state ~ {"on":true} ~ PUT ~ 1 ~ 0 ~ {"success":true} ~ ~ ~ ;60000012 ~ LightOff ~ DevCmd012 ~ https://10.10.11.20/api/usernamex/lights/1/state ~ {"on":false} ~ PUT ~ 1 ~ 0 ~ {"success":true} ~ ~ ~ ;60000002 ~ LightSoft ~ DvcCmd002 ~ https://10.10.11.20/api/usernamex/lights/1/state ~ {"on":false} ~ PUT ~ 1 ~ 0 ~ {"success":true} ~ ~ ~ ;;DEBUG con Beeceptor! (https://asteriskguardian.free.beeceptor.com/);60000002 ~ LightSoft ~ DvcCmd002 ~ https://asteriskguardian.free.beeceptor.com/ ~ {"on":false} ~ PUT ~ 1 ~ 0 ~ {"success":true} ~ {"Opt#1":false} ~ {"Opt#2":false} ~ {"Opt#3":false};;;Comando a Hue Bridge real!;===========================;Aquí la respuesta al comando Webhook no es un JSON Universal predefinido fijo, sino muy variable según el comando, pero tiene como constante que si el comando tiene éxito,;contiene la palabra "success", ante lo cual para confirmar la recepción del JSONWebhook, definimos el tipo de retorno Web/"WebRtrnType" como cadena (2), y ya con ello tenemos protocolo.60000001 ~ LightOn ~ DvcCmd001 ~ http://10.10.11.3/api/UFgKWCzhzC9pvPpnk2H5ZYApAjRpluRCrWFXCXSl/lights/1/state ~ {"on":true} ~ PUT ~ 2 ~ 0 ~ success ~ ~ ~ 60000002 ~ LightSoft ~ DvcCmd002 ~ http://10.10.11.3/api/UFgKWCzhzC9pvPpnk2H5ZYApAjRpluRCrWFXCXSl/lights/1/state ~ {"on":true, "bri":80} ~ PUT ~ 2 ~ 0 ~ success ~ ~ ~ 60000003 ~ LightMedium ~ DvcCmd003 ~ http://10.10.11.3/api/UFgKWCzhzC9pvPpnk2H5ZYApAjRpluRCrWFXCXSl/lights/1/state ~ {"on":true, "bri":160} ~ PUT ~ 2 ~ 0 ~ success ~ ~ ~ 60000004 ~ LightOff ~ DevCmd004 ~ http://10.10.11.3/api/UFgKWCzhzC9pvPpnk2H5ZYApAjRpluRCrWFXCXSl/lights/1/state ~ {"on":false} ~ PUT ~ 2 ~ 0 ~ success ~ ~ ~ ;;Comando Múltiple, cubriendo 4 comandos simples en uno solo con modo de Alternar/Togle;Funciones varias de Luz sobre un device "lights"60000005 ~ LightFnctn ~ DvcCmd005 ~ http://10.10.11.3/api/UFgKWCzhzC9pvPpnk2H5ZYApAjRpluRCrWFXCXSl/lights/1/state ~ {"on":true, "bri":254} ~ PUT ~ 2 ~ 0 ~ success ~ {"on":true, "bri":80} ~ {"on":true, "bri":160} ~ {"on":false};;;###################################;;Comandos IoTPBX para acceder a "devices" de otros sistemas mediante el mecanismo proveedor IoT de tercera parte como lo es el concepto de un "IP Sensors";Aquí se produce desde el usuario un Webhook apropiado que activa o se comunica con un Device lógico o físico que actuará como "Sensor" o disparador de un estado,;como por ejemplo "Generic Flag Sensor" o "Generic Status Sensor" en Bridge Hue Philips, que son "IP Sensor", u objetos Sensores accesibles vía IP,;para proveer accesibilidad desde tercera parte, sea el caso actual, con IoTPBX u otros;Estos objetos y sus atributos/propiedades se crean en el dispositivo Hue Bridge Philips o similar, generalmente mediante POST ;y una vez creados, son accedidos con Webhooks para actualizar sus atributos con PUT y así activar o comunicarse con el Sensor.;Queda a la necesidad y requerimiento del Cliente la implementación de estos componentes para accederlos desde IoTPBX;;La implementación es exactamente similar, así que la definición del Comando Webhook IoTPBX será según los requerimientos específicos del objeto "IP Sensor" creado.;;###################################;;;Comandos IoTPBX para activar "Alarmas" o "Mensajes" en un Panel Visual, por ejemplo una Web representando el Panel/Eboard/Pizarra Electrónica!!!;Aquí se produce desde cualquier usuario con acceso a un teléfono físico o virtual, con un botón o memoria configurado para IoTPBX,;un JSONWebhook que lleva un mensaje de tipo "Alarma" o "Mensaje" y que será representado en una interfaz gráfica o Panel Web!!!;Se puede dar una estructura tan simple o tan compleja/completa como se desee, por ejemplo:;La estructura más simple es solo declarar que el Webhook es de tipo "Msg" o "Alrm" y su body/cuerpo o contenido, que será la cadena/texto, el evento a "comunicar";otras propiedades pueden ser dadas dentro del mismo JSONWebhook, tales como la posición exacta con latitud y longitud dónde se encuentra el teléfono originador;o cualquier otro atributo que se quiera transmitir, como la dirección física del inmueble, el nombre del empleado, la oficina, el cargo, una prioridad, etc, etc, etc.;todo lo anterior, lo cual se puede contener en un JSON "EBoard" que carga con todas las Alarmas o los Mensajes para su Display en el Panel Web IoTPBX;Un prototipo muy sencillo lo podemos representar mediante el servicio Web en https://asteriskguardian.free.beeceptor.com/ y que puede ser replicado muy fácil;para cualquier otra implementación, mostrando todos los aspectos básicos requerido para su propio despliegue a cargo del Cliente.;;Ejemplo JSON para un "Mensaje":;===============================;DEBUG con Beeceptor! (https://asteriskguardian.free.beeceptor.com/);JSON:;{; "EBoard": [; {; "Clase": "Msg",; "Name": "Msg#0001",; "Type": "MsgCmd0001",; "Location": "Office ###1",; "Body": "Puesto Disponible! (o no?)"; }; ];};JSON Minify con https://jsonformatter.com/;{"EBoard":[{"Clase":"Msg","Name":"Msg#0001","Type":"MsgCmd0001","Location":"Office ###1","Body":"Puesto Disponible! (o no?)"}]};60000006 ~ Msg#0001 ~ MsgCmd0001 ~ https://asteriskguardian.free.beeceptor.com/ ~ {"EBoard":[{"Clase":"Msg","Name":"Msg#0001","Type":"MsgCmd0001","Location":"Office ###1","Body":"Puesto Disponible! (o no?)"}]} ~ PUT ~ 1 ~ 0 ~ {"success":true} ~ ~ ~ 60000006 ~ Msg#0001 ~ MsgCmd0001 ~ https://asteriskguardian.free.beeceptor.com/ ~ {"EBoard":[{"Clase":"Msg","Name":"Msg#0001","Type":"MsgCmd0001","Location":"Office ###1","Body":"Puesto Disponible! (o no?)"}]} ~ PUT ~ 1 ~ 0 ~ {"success":true} ~ ~ ~ ;;;Ejemplo JSON para una "Alarma":;===============================;DEBUG con Beeceptor! (https://asteriskguardian.free.beeceptor.com/);JSON:;{; "EBoard": [; {; "Clase": "Alrm",; "Name": "Alrm#0001",; "Type": "AlrmCmd0001",; "Location": "Office ###1",; "Body": "Fire! (Earthquake/Weapons/Urgency/Doctor/Help/Etc.)"; }; ];};JSON Minify con https://jsonformatter.com/;{"EBoard":[{"Clase":"Alrm","Name":"Alrm#0001","Type":"AlrmCmd0001","Location":"Office ###1","Body":"Fire! (Earthquake/Weapons/Urgency/Doctor/Help/Etc.)"}]};60000007 ~ Alrm#0001 ~ AlrmCmd0001 ~ https://asteriskguardian.free.beeceptor.com/ ~ {"EBoard":[{"Clase":"Alrm","Name":"Alrm#0001","Type":"AlrmCmd0001","Location":"Office ###1","Body":"Fire! (Earthquake/Weapons/Urgency/Doctor/Help/Etc.)"}]} ~ PUT ~ 1 ~ 0 ~ {"success":true} ~ ~ ~ 60000007 ~ Alrm#0001 ~ AlrmCmd0001 ~ https://asteriskguardian.free.beeceptor.com/ ~ {"EBoard":[{"Clase":"Alrm","Name":"Alrm#0001","Type":"AlrmCmd0001","Location":"Office ###1","Body":"Fire! (Earthquake/Weapons/Urgency/Doctor/Help/Etc.)"}]} ~ PUT ~ 1 ~ 0 ~ {"success":true} ~ ~ ~ ;;;Next:;Para una próxima versión, se pueden considerar los siguiente aspectos de mejora:;- Dashboard que presente todos los Devices Luminarias o Actuadores con sus respectivos estados en tiempo real, mediante una ventana dentro de ;PABXControl Asterisk Guardian, permitiendo conocer a simple vista el estado de todo el sistema y opcionalmente interactuar directamente con el.;- Conexión de los JSON Eboard, "Mensajes" o "Alarmas", ahora dirigidos a una Web/Eboard, hacia un mensajero como WhatsApp, Telegram u otros.;- Adicionar propiedades en el JSON EBoard dentro de las clases "Msg" y "Alrm", conceptos tales como TimeStamp, IP de Origen, u otros requeridos que pueda resolver dinámicamente el Core IoTPBX;- Direccionamiento de los mensajes entre Extensiones, PeerToPeer, de forma que el "mensaje" o la "Alarma" se enrute a una Extensión/Teléfono especifico y se muestre en su Display o le entregue un mensaje de audio.;- Inicio de una difusión o Broadcasting para una alarma dada y a un grupo dado;- Permitir cualquier otra integración de interés hacia otros sistemas, dentro del ámbito de IoT o Telco.;;

Entorno de Configuración IoTPBX dentro de PABXControl Asterisk Guardian

Dado que la configuración del ámbito IoTPBX se relaciona principalmente y mayoritariamente en el archivo "ManagerIoT.txt", se ofrece para este nuevo entorno las mismas herramientas de edición presentes y ya conocidas por todos en el producto.

A continuación una imagen para su familiarización:

Vista al Sistema de Reportes IoTPBX

Dado que cada Extensión/Teléfono es un punto de control potencial para que un usuario autorizado actúe en cualquiera de los entornos previstos en IoTPBX, es posible siempre hacer un seguimiento muy preciso y detallado acerca de todas y cada una de las actuaciones sobre el sistema, lo cual es una característica muy especializada de control y supervisión poco frecuente y disponible, pero que en el entorno IoTPBX gana mucha tracción y valor pues el sistema puede proveer reportes muy completos para cada usuario, en rangos de tiempo, por tipo de dispositivo, por tipo de acción sobre el dispositivo, la frecuencia, o si fue un Mensaje o Alarma, y seguir así el rastro completo y especifico del manejo de todos los recursos y la seguridad alrededor de la operación.

Generación de Reportes IoTPBX

De forma similar a todo reporte de llamada dentro de PABXControl Asterisk Guardian se realizan los reportes del entorno IoTPBX.

Se empieza seleccionando un archivo de Mes (secundario), se realizan unos filtros adecuados y se genera el reporte impreso o a texto.

Al frente vemos una descripción del proceso... ->

En el reporte impreso mostrado más abajo se detalla que filtros se efectuaron para el caso del ejemplo.

Ejemplo del Reporte texto IoTPBX visto desde la aplicación

Vista al Sistema de Información de Alarmas y Mensajes en Web o EBoard

Aunque el sistema de Alarmas y Mensajes solo provee los Webhooks que en una arquitectura de diseño EDA, ofrece los eventos para que un sistema Web sirva de Panel o sean llevados a una App o mostrados en una Pizarra electrónica, es muy fácil ver su implementación más elemental aprovechando servicios gratuitos de prueba a llamados Web, tales como Beeceptor, y aprovechando el entorno ya creado ahí, lo vemos aquí actuando en la siguiente imagen:

La parte superior de la imagen muestra un Mensaje con todas las propiedades que se quiso dar en la definición de la configuración del archivo "ManagerIoT", y en la parte inferior, se muestra una Alarma, igualmente según la especificación dada, así ambos siempre son enviados dentro de un JSON "EBoard" siguiendo la convención establecida, pero se puede definir cualquier otra.

What's Next?

Para una próxima versión, se pueden considerar los siguiente aspectos de mejora:

Un Dashboard que presente todos los Devices Luminarias o Actuadores con sus respectivos estados en tiempo real, mediante una ventana dentro de PABXControl Asterisk Guardian, permitiendo conocer a simple vista el estado de todo el sistema y opcionalmente interactuar directamente con el.

Conexión de los JSON Eboard, "Mensajes" o "Alarmas", ahora dirigidos a una Web/Eboard, hacia un mensajero como WhatsApp, Telegram u otros.

Adicionar propiedades en el JSON EBoard dentro de las clases "Msg" y "Alrm", conceptos tales como TimeStamp, IP de Origen, u otros requeridos que pueda resolver dinámicamente el Core IoTPBX

Direccionamiento de los mensajes entre Extensiones, PeerToPeer, de forma que el "mensaje" o la "Alarma" se enrute a una Extensión/Teléfono especifico y se muestre en su Display o le entregue un mensaje de audio.

Inicio de una difusión o Broadcasting para una alarma dada y a un grupo dado

Permitir cualquier otra integración de interés hacia otros sistemas, dentro del ámbito de IoT o Telco.

Page updated

Google Sites

Report abuse