“Sigfox es una tecnología realmente agradable cuando quieres hacer una experimentación realmente rápida en IoT. El Time To Hello World te llevará menos de 5 minutos y lo hace realmente fácil.
Eso dijo después de que la producción llegara a la POC, y la forma en que administre su back-end Sigfox para la producción no es la forma en que usted construye su plataforma front-end rápida y sucia para el POC.
Esta publicación presentará cómo crear su plataforma de producción y cuál es la dificultad que debe tener en cuenta. Te propondré alguna solución arquitectónica que he puesto en práctica, pero son una de las formas de implementarla. No detallaré los paquetes de la solución PaaS ya que no soy un gran admirador de ellos: desde mi punto de vista, en primer lugar están respondiendo a la situación POC, pero es solo mi propia opinión.
capturar [todos] los mensajes sigfox
Esto es usualmente donde comenzamos a construir nuestra propia plataforma porque es la primera necesidad que tenemos. En cuanto al ciclo de vida del dispositivo, esto no es totalmente lógico, pero comenzaré por este paso porque es en el que queremos centrarnos.
La principal dificultad es no perder ningún mensaje de Sigfox. Hay dos formas de capturar mensajes Sigfox: empujar y tirar.
Puede solicitar mensajes desde el backend basados en la API de Sigfox. Esta solución tiene algunas ventajas, como que no necesita exponer y asegurar un servicio, pero tiene numerosos límites:
° La API es por dispositivo, por lo que debe tener una gran cantidad de llamadas tan pronto como administre una gran flota de objetos
°La API no permite administrar desde / hasta el rango de tiempo, por lo que necesita administrar páginas en su código
° No hay ningún disparador cuando llega un mensaje, por lo que no podrá anticiparlo, necesita llamar regularmente a la API y procesar siempre y siempre los mismos datos. Usted spam la API sigfox y su propio servidor
° No hay forma de administrar la comunicación de enlace descendente en tiempo real ya que no está sincronizado con la transmisión del dispositivo.
Como consecuencia, no es una buena idea basar la captura en esta solución. Es mejor usarlo, por ejemplo, para administrar la falla de devolución de llamada, como para volver a cargar los mensajes perdidos. Personalmente, preferí hacerlo de manera diferente.
Este es el enfoque de devolución de llamada generalmente preferido: cuando llega un mensaje desde un dispositivo al backend de Sigfox, Sigfox llama a una (o más) URL de devolución de llamada en su propio servidor para enviar los datos.
Esta técnica es en tiempo real, permite el enlace descendente y ofrece algo más que simplemente enviar el mensaje. Puedes elegir cargar mensajes uno por uno con el riesgo de tener un gran tráfico en tu back-end (estamos hablando de dispositivos que se comunican el 1% de las veces … así que básicamente es enorme) o puedes elegir obtener una devolución de llamada con un frecuencia máxima de 1 por segundo que contiene todos los mensajes recibidos ese segundo. Personalmente, encontré esta opción más complicada de administrar hasta que tendré millones de dispositivos y esa vez tomaré algún desarrollador para administrar esta complejidad adicional. Entonces, usar la devolución de llamada para cada mensaje (y uno para cada duplicado) es fácil y bueno.
En este modo, podemos usar HTTP get & post. POST se ve como una mejor opción, incluso si es un poco más complejo de configurar, más adelante se convertirá en una gran ayuda. (la complejidad vendrá con la administración del tipo de dispositivo). Hace un año, era más complejo depurar ya que el servidor no mostraba el cuerpo del mensaje, pero ahora se ha resuelto, por lo que no hay motivo para usar GET.
El problema del método Push es gestionar los fallos:
° Sin duda, en algún momento, su servidor se bloqueará. Si no es por usted, lo hará por su Hoster, pero créame, se bloqueará
° Seguro que gestionará la liberación y detendrá su servicio, e incluso si usted es EL JEFE de la implementación azul verde, terminará colocándose en algún momento.
Entonces, significa que debe tener una solución para manejar estas situaciones:
° Lo primero que se debe implementar es la alta disponibilidad: puede hacerlo en base a un equilibrador de carga y múltiples servidores back-end de captura. Esta es la forma más fácil y más simple de implementarlo. La segunda opción es declarar una devolución de llamada diferente en sus diferentes servidores y administrar en el servidor de back-end la no duplicación de las entradas en su base de datos. Esta solución es más compleja al final, pero elimina la necesidad del equilibrador de carga.
° Lo segundo es tener una infraestructura de captura totalmente diferente como respaldo. Vamos a detallar este punto:
Esta es la mejor solución que encontré para responder a los 2 puntos de falla identificados anteriormente. Además de mi servicio de captura de HA, tengo una solución de software totalmente diferente que se utiliza para hacer una copia de seguridad de los mensajes. Cuando la solución de captura analiza / decodifica los datos, la solución de copia de seguridad solo la almacena como información sin formato. Esta solución de respaldo es realmente simple, inicialmente, era un simple script PHP que almacenaba el cuerpo JSON en un archivo de texto. Entonces decidí cambiarlo por algo mejor.
Básicamente, este componente de copia de seguridad es simple en términos de código y en términos de infraestructura, por lo que no tiene ningún motivo para fallar, no es necesario actualizarlo. En cualquier caso, si falla, la captura principal no y los datos pueden ser recibidos. Para garantizar que esta copia de seguridad no se bloquee con la secuencia de captura principal, decidí implementarla en otro centro de datos en otro servidor … La mejor opción podría ser desplegarla en un proveedor de servicios de nube diferente.
Este servicio de respaldo ofrece el servicio de almacenamiento sin procesar y una API. El backend principal de captura puede invocar esta API para resincronizar sus datos. Entonces, la pregunta correcta ahora es: ¿por qué no usar Sigfox Message API para esto? la respuesta es simple: fue muy fácil para mí formatear los datos provenientes de mi respaldo exactamente como vino de la devolución de llamada de Sigfox y no hice ningún desarrollo adicional para administrarlo. Con Sigfox API, tendría que crear una interfaz diferente con un nivel de información diferente al que tengo en mi devolución de llamada.
Como ejemplo de devolución de llamada, agrego algunas variables globales como la versión del protocolo del dispositivo en relación con el firmware de mi dispositivo. Esta información no es parte de la API y es importante para mí. Más tarde podría tener más información para agregar y la API no lo admitirá.
Con esta solución, puedo programar la sincronización de captura o simplemente ejecutar este proceso de resincronización después de una detención de captura.
El enfoque push push no solo se relaciona con los mensajes que provienen del dispositivo sino que también incluye los mensajes de red en torno a facturación, errores, enlace descendente. Deben ser capturados y administrados.
El backend de Sigfox ahora propone reintentar los mensajes en caso de falla, esta característica es interesante pero solo cubre los bajones, como menos de 5 minutos. Puede ser una buena manera de proteger contra el tiempo de parada / inicio o cambio de equilibrador de carga. Pero no está protegiendo contra bloqueos o lanzamientos de aplicaciones
Esta parte es algo importante, ya que una vez que capturó la información que necesita para reaccionar y comenzar a crear procesos de administración de dispositivos. Veremos eso más tarde.
gestionar fuera de servicio
Ser capaz de reproducir algunos mensajes perdidos después de un tiempo también significa insertar mensajes no ordenados. Esto requiere un procesamiento específico para asegurarse de que realicen las acciones correctas. Como ejemplo, enviar una alarma 2 días después de haber sido levantado no es una buena idea. Enviar una respuesta de devolución de llamada en una repetición no tiene sentido. Por lo tanto, incluso si la capacidad de reproducción se puede implementar siguiendo la misma ruta que la captura habitual, se necesita un procesamiento específico que no se debe olvidar y se debe integrar en los primeros pasos de desarrollo.
administrar el tipo de dispositivo
Tan pronto como haya comenzado a crear su devolución de llamada e incluya los mensajes de servicio, la configuración de su tipo de dispositivo comenzará a verse desordenada y duplicar un tipo de dispositivo será su pesadilla (créame, lo hice tantas veces). Incluso si traté de convencer a Sigfox sobre agregar esta opción en el back-end, en realidad fallé
Por cierto, puedes automatizar esta parte desde la API. Seré honesto, hay una gran cantidad de líneas de código para hacerlo porque primero necesita definir su formato de mensaje diferente (personalmente, mi elección fue para un mensaje común global sea cual sea el tipo de devolución de llamada con ciertas constantes para identificarlo) entonces usted necesidad de automatizar la creación de diferentes API para el tipo de dispositivo y para la devolución de llamada. (Compartiré alguna parte de mi código pronto)
Al final, esto funcionó bien hasta que Sigfox rompió parte de la API relacionada con la administración de contratos, pero está en camino a ser resuelto (pero es demasiado tiempo desde mi punto de vista).
Entonces, esta es una parte importante: poder implementar una configuración compleja de devolución de llamada con un solo clic. Debes tener en cuenta que necesitarás varios tipos de dispositivos incluso con un dispositivo porque este dispositivo tendrá versiones que administrarás más fácilmente de esa manera porque tendrás dispositivos de desarrollo y producción porque tendrás que gestionar varios contratos y por qué no clientes diferentes. ser dueño de los contratos de Sigfox directamente
Si no tiene este sistema automatizado, seguramente olvidará algo durante la configuración y perderá datos o degradará la calidad de sus datos.
También debe pensar en implementar múltiples tipos de dispositivos en relación con el ciclo de vida de su dispositivo. En mi experiencia personal, quiero poder detener la comunicación de algunos dispositivos y la forma más fácil es moverlos en un tipo de dispositivo dedicado sin devolución de llamada. También puede querer tener el tipo de dispositivo para el dispositivo o dispositivo en la basura bajo prueba. El tipo de dispositivo es una buena forma de organizar sus dispositivos desde el punto de vista de Sigfox y depende del estado del dispositivo en el que puede esperar un objetivo de devolución de llamada diferente. Debe comenzar a definir sus reglas con respecto al ciclo de vida del dispositivo y a implementar la automatización en torno a la transferencia del dispositivo.
administrar la comunicación de enlace descendente
¡La comunicación de enlace descendente es una especie de arte! puedes consultar mi publicación dedicada al enlace descendente aquí. Básicamente, debe comprender que nunca está seguro de lo que está sucediendo durante el proceso de enlace descendente. Puede estar seguro de que el dispositivo recibió su enlace descendente si agregó comentarios funcionales. El problema es: si no tienes nada, no significa que tu dispositivo no lo haya obtenido.
En consecuencia, administrar los enlaces descendentes significa gestionar diferentes estados, administrar el servicio de devolución de llamada y posiblemente verificar el OOB desde la API (necesito verificar esto, pero parece que podemos obtener el OOB de la API, pero el servicio de devolución de llamada no lo proporciona, incluso si este servicio existe). Puede estimar que se ha enviado un OOB al detectar el salto de id. De secuencia. Por lo tanto, entiendes el tipo de Magia que necesitas implementar.
Las reglas clave son las siguientes:
° Su dispositivo debe poder recolectar downlinks consecutivos con el mismo valor sin hacerlo incoherente. Debido al estado de recepción desconocido y el reintento asociado, el dispositivo recibirá el mismo enlace descendente varias veces.
° Debe administrar la prioridad del enlace descendente en su back-end, ya que el enlace descendente pendiente a veces puede tomar mucho tiempo antes de ser procesado. Se debe dar prioridad a los enlaces descendentes urgentes.
°Debe administrar la cancelación del enlace descendente, el reintentos del enlace descendente y el enlace descendente sin reintento.
Una vez que haya dominado su administración de enlace descendente, tomando todos estos puntos en consideración, estará listo para la implementación del enlace descendente.
Desde mi propia experiencia, la implementación de administración de enlace descendente afectará el diseño del firmware. Por esa razón, esto debe diseñarse con el equipo de firmware en paralelo a la creación del dispositivo, no como un paso hacia abajo. De lo contrario, no tendrás un sistema de enlace descendente confiable
También debe considerar profundamente su ciclo de trabajo durante el proceso de enlace descendente. Con múltiples comunicaciones secuenciales para solicitud, tecnología y reconocimiento funcional, puede mantenerse en silencio por un tiempo.
Administre sus dispositivos
La gestión del ciclo de vida del dispositivo es una larga historia, hay diferentes elementos a considerar:
° Proceso de manufactura
° Proceso de activación
° Versión de firmware
° Configuración actual
° Configuración pendiente
° Suscripción a la red
°Suscripción a su servicio
…
Podemos considerar algunos pasos importantes para el dispositivo:
Fabricado (soldado pero aún no vendido)
En ese momento, registrará el dispositivo en su back-end con información técnica, como el tipo de objeto, la versión de firmware o la configuración predeterminada. Como el dispositivo no emitirá toda esta información (o lo hará, pero no está seguro de obtenerlo, debido a una posible pérdida de red), siempre es mejor almacenarlo porque están cambiando mes tras mes y al final, usted nunca recordará qué versión tiene qué configuración y qué dispositivo es qué versión.
Probado (como se emitió pero aún no se usó un token)
Una forma de verificar que el dispositivo esté funcionando correctamente es enviar un cuadro durante la fase de prueba y verificar que la red lo haya recibido. Eso es posible si su contrato le permite algunos marcos de prueba antes de comenzar a consumir su token. En este caso, significa que su dispositivo debe estar conectado a un tipo de dispositivo y un contrato. El tipo de dispositivo utilizado para la prueba puede no ser el mismo que el de producción. Para gestionar esto, necesita automatizar la creación del dispositivo y los archivos adjuntos a un tipo de dispositivo. Luego, cambie al tipo de dispositivo prod una vez que la prueba haya sido validada. Todas estas operaciones se pueden automatizar gracias a la API.
Activado (se activa y consume un token)
Su cliente activó el dispositivo y ahora está comunicando datos. En este punto, la primera comunicación comienza a consumir la suscripción de Sigfox. Debe preocuparse por la cantidad de tokens gratuitos que todavía tiene en sus contratos y puede cambiar al contrato correcto. Para tener éxito en este paso, debe administrar el mensaje de error de red y automatizar las acciones correctivas. Levante las alarmas al administrador de la plataforma al menos.
Durante esta fase, el dispositivo puede declararse en el servidor, cambiar su configuración y actualizar su firmware. Hay muchas situaciones diferentes para anticiparlo y codificar.
El modo activado debe detectar dispositivos locos o no hablar de dispositivos, administrar el nivel de la batería para monitorear la red de sensores y aconsejar operaciones manuales.
Loca
A veces, puedes tener dispositivos locos hablando cada 10 segundos. Una de las razones habituales es una falla de la batería no administrada correctamente o un error en el firmware. Los dispositivos locos no se pueden dejar de hablar en general, pero puedes sacarlos de los datos de procesamiento normales para reducir el spam de la base de datos.
Fuera de contrato (se cancela su suscripción a la red)
Un token tiene un final de suscripción Sigfox. Esto debe ser administrado, anticipado y automatizado para la renovación.
Sin suscripción (su suscripción de servicio terminó)
Su servicio también puede tener una suscripción y usted necesita administrarla. Una vez que finaliza su suscripción, el dispositivo puede continuar hablando. Puede tener en su firmware una función para detenerlo, pero básicamente puede seguir hablando. La renovación automática del token de Sigfox es una buena característica para no perder la conexión, pero si no desea pagar por los dispositivos parlantes, debe configurar su dispositivo para esto. Aquí tiene una estrecha integración entre la administración de su dispositivo y la administración de dispositivos Sigfox.
Retirado (nunca más será usado)
El dispositivo nunca se emitirá. Por lo tanto, probablemente no desee listarlo en su lista de dispositivos. Esconderlo en alguna parte. Este estado es más fácil de administrar y está relacionado con la administración del tipo de dispositivo.
Puedes imaginar muchos otros estados, estoy seguro. Eso depende de su necesidad funcional y agrega complejidad cada vez.
Configuración del dispositivo
Como parte de Device Management, tenemos una configuración de dispositivo. Esta no es una parte simple si miras el futuro cuando comienzas a diseñar tu objeto. Un dispositivo tiene una versión y existirá una versión por muchos años. La versión afectará a diferentes firmware con diferentes capacidades y errores, diferentes protocolos de comunicación (su versión de firmware agregará funciones y un tipo de marco), diferentes revisiones de hardware o diferentes dispositivos.
La configuración del dispositivo algunas veces cambiará fuera de su control: el firmware no se puede actualizar en la red, por lo que será manual. La configuración se puede hacer directamente en el dispositivo …
En mi opinión, un dispositivo necesita primero identificarse enviando su configuración y versión a la red en el arranque. Esto sería perfecto si no estuviéramos utilizando una red con pérdida como parte del diseño y con un ancho de banda infinito. La realidad es que tenemos básicamente 12 bytes para anunciar un dispositivo con versión HW, versión FW y parámetros de configuración principales. Este marco será recibido … o no.
Por lo tanto, el backend debe saber antes de la configuración cuál es la información esperada incluida en este marco. El dispositivo luego actualizará esta información enviando el marco. Una parte de la configuración general no se conocerá ni se estimará en función de la configuración inicial determinada por la versión FW y las diferentes configuraciones modificadas solicitadas por el back-end.
Se puede solicitar a un dispositivo que cambie su configuración gracias al mecanismo de enlace descendente. En las mejores condiciones posibles, puede reconfigurar todo el dispositivo con solo una solicitud de enlace descendente, eso es perfecto. Por lo general, el número de parámetro es más alto y debe enviar múltiples enlaces descendentes para cambiar la configuración. En consecuencia, la configuración requerirá un largo tiempo con respecto al ciclo de trabajo y su política de enlace descendente. Durante este tiempo, su dispositivo tendrá que administrar una configuración de sombra (almacenada pero no aplicada) y su backend también tendrá que administrar la comunicación actual y la pendiente. Una vez aplicada, la configuración debe actualizarse en ambos lados. En este punto, el protocolo de confirmación de enlace descendente es muy importante y seguramente debe gestionar en su operación manual posterior / frontal para corregir comportamientos inesperados, configuración sin terminar … Por experiencia, un punto clave de esto, es poder cambiar los parámetros uno por uno para garantizar que puede volver a ejecutar una configuración, sin tener que considerar el estado de configuración inicial. Esto se debe a que debe tener en cuenta en cualquier momento que su imagen de configuración de fondo es falsa en comparación con lo que realmente funciona en su dispositivo.
Administrar acceso a dispositivos a la derecha, grupo de usuarios …
Incluso si al final de esta publicación, se debe considerar la gestión correcta al principio. El usuario / grupo y la administración correcta también es algo importante. No detallaré esta parte porque es bastante estándar. Pero hay algunos elementos que puedes considerar:
° Administrar dispositivos significa transferir la propiedad en algún momento
° Transferir dispositivos significa limpiar datos históricos
° Los dispositivos de acceso pueden ser generalmente realizados por múltiples usuarios
°Los usuarios generalmente tienen múltiples dispositivos
Los dispositivos están generando alertas, los usuarios reciben alertas. Lo obtienen de diferentes maneras dependiendo de estas preferencias.
acceso a los datos
Una vez que los datos se almacenan en un backend, pueden ser consumidos por front-end u otros sistemas. Los front-ends consumen API (si intentas ser un poco moderno en tu desarrollo) y las API pueden estar expuestas de sistema en sistema.
La integración de la API de sistema a sistema puede generar un gran tráfico si no se ofrecen los puntos finales de acceso correctos. Como ejemplo, si quiero una actualización rápida de la información del dispositivo, incluso si el dispositivo está emitiendo una vez al día, necesito llamar a la API cada X segundo / minuto para saber cuándo se ha realizado esta actualización. Esto consume mucho. Para evitar una situación similar, es bueno tener una API que ofrezca información de lo que se ha actualizado desde la última llamada o cuando la información se actualizará en función de la última comunicación y configuración. Este es el enfoque de atracción.
El enfoque de Push es mejor. Puedes hacerlo de diferentes maneras con webhook (como la devolución de llamada de sigfox): tu consumidor está configurando la devolución de llamada de id y presionas la información. Eso significa que debe implementar el reintento, el acceso a la API para garantizar que las fallas se administrarán.
Hay otras formas de hacer una actualización push. Desde mi punto de vista, MQTT es la solución más fácil: transfiere sus datos a un bus de mensajes sobre un tema donde los clientes se suscriben. El autobús guardará la información hasta que el cliente la consuma. El consumidor recibe inmediatamente la información. (Todavía estoy esperando que Sigfox implemente una de esas características más adelante, haría la integración más simple y mejor).
Incluso si hace un servicio de pila completa, mi consejo es: siempre piense en exportar sus datos como parte del diseño inicial. Incluso para usted mismo le ayudará en el futuro y cuesta un poco cuando se diseñó inicialmente.
para concluir
Espero que haya entendido que crear una plataforma IoT (esto es aplicable para Sigfox como cualquier otro) no es algo que pueda hacer en 5 minutos y las preguntas planteadas son importantes para administrar al inicio del diseño, no como un segundo paso. Puede hacerlo iterativamente, pero debe hacerlo como base.
Para darle una idea, mi backend actual es de aproximadamente 20,000 código de línea java / springboot y pasé 3 semanas completas de trabajo en él. Esto implementa alrededor del 80% de lo que se ha descrito anteriormente.
Sólo para hacerle saber.”
Fuente: DISK91.COM
