IOT123 - ASIMILAR EL HUB DEL SENSOR: COMPONENTES WEB ICOS10 CORS: 8 Pasos

2024 Autor: John Day | [email protected]. Última modificación: 2024-01-31 10:18

Los esclavos ASSIMILATE SENSOR / ACTOR incrustan metadatos que se utilizan para definir visualizaciones en Crouton. Esta construcción es ligeramente diferente a las anteriores; no hay cambios de hardware. El firmware ahora admite el alojamiento de editores personalizados (más ricos) que se pueden integrar en la última versión de AssimilateCrouton. Se prestará más atención a la explicación del firmware y el tablero MQTT en este artículo.

Una de las ventajas de servir WebComponents desde el dispositivo que controlan, es que el control más avanzado del dispositivo se limita a la red a la que está conectado el dispositivo: su punto de acceso WiFi. Aunque una vez que usa un servidor MQTT con autenticación hay una semejanza de protección, en las redes públicas si deja su navegador momentáneamente (sitio web AssimilateCrouton) alguien podría entrar y controlar sus dispositivos de automatización. Esta característica de CORS WebComponent hace posible que solo se muestren las lecturas (temperatura, niveles de luz, humedad) públicamente y las funciones de comando (encendido / apagado, programación) solo estén disponibles desde la red del dispositivo.

En el dispositivo, todas las funciones del servidor web con autenticación y alojamiento en SPIFFS siguen siendo compatibles, pero se ha hecho especial hincapié en la compatibilidad con CORS (intercambio de recursos de origen cruzado) para Polymer WebComponents (Crouton usa Polymer 1.4.0).

En AssimilateCrouton (la bifurcación de Crouton utilizada para Assimilate IOT Network) los cambios incluyen

• soporte para una tarjeta de dispositivo (assim-device) que, entre otras cosas, muestra y oculta, para un usuario, tarjetas individuales para un dispositivo
• Propiedad de información en todas las tarjetas que muestra un brindis de información contextual útil para una tarjeta
• soporte para componentes web CORS, en este caso alojados en el servidor web del dispositivo (ESP8266).

Paso 1: CROUTON

Crouton es un tablero que le permite visualizar y controlar sus dispositivos IOT con una configuración mínima. Esencialmente, es el panel de control más fácil de configurar para cualquier entusiasta del hardware IOT que utilice solo MQTT y JSON.

Los ASSIMILATE SLAVES (sensores y actores) tienen metadatos y propiedades incrustados que el maestro usa para construir el paquete deviceInfo json que Crouton usa para construir el tablero. El intermediario entre ASSIMILATE NODES y Crouton es un bróker MQTT compatible con websockets: Mosquito se utiliza para la demostración.

A medida que ASSIMILATE MASTER solicita propiedades, formatea los valores de respuesta en el formato requerido para las actualizaciones de Crouton. La bifurcación AssimilateCrouton agrega algunas características que le permiten descentralizar las reglas comerciales que ejecutan su dispositivo, es decir, el dispositivo IOT no necesita reglas comerciales integradas, es solo una tubería para la comunicación MQTT / I2C a los actores y sensores esclavos más inteligentes (controlados por ATTINY).

Paso 2: ASIMILAR CROUTON

CAMBIOS EN CROUTON

Los cambios de la versión bifurcada incluyen:

• si un punto final tiene una propiedad de ruta definida, el WebComponent para la tarjeta hará un HTMLImport para un recurso CORS (el servidor web en el ESP8266 en esta compilación).
• cualquier recurso aguas arriba de (dependencias de) un WebComponent CORS se hace referencia como si fueran servidos desde el sitio web de Crouton; cuando no pueden cargar un controlador de excepciones, reajusta las rutas y se carga desde el sitio web.
• se muestra una hora local actual en la parte superior derecha, útil para programar la verificación.

DEPENDENCIAS DE POLÍMEROS Y CORS

Las hojas de un árbol de dependencia de polímeros se pueden alojar en CORS. Debido a que las dependencias raíz se pueden usar varias veces en una aplicación, no se puede hacer referencia a ellas desde 2 ubicaciones (el sitio web y el dispositivo) porque Polymer Module Loader las trata como 2 recursos separados y múltiples errores de registro hacen que una aplicación se tambalee rápidamente.

Por esta razón, el WebComponent para una tarjeta (archivo HTML en 1.4.0) y el archivo CSS asociado son los únicos archivos alojados en el dispositivo. Se hace referencia a las otras dependencias como si el WebComponent estuviera alojado en la carpeta "html" del sitio web de origen, lo que facilita el desarrollo de los WebComponents desde esa carpeta hasta que esté listo para cargarse en SPIFFS en el ESP8266. AssimilateCrouton averiguará cómo obtener los archivos correctos.

DESPLIEGUE

edfungus creador del Crouton original escribió la fuente en Pug / Less y tenía una cadena de herramientas NPM / Grunt. Representé el Pug / Less como HTML / css y simplemente edité / distribuí los archivos renderizados. Esto rompió la cadena de herramientas NPM / Grunt. Arreglar esto se cubre en la sección FUTURO.

Puede probar el tablero localmente en su caja DEV:

• Desde la línea de comando en la carpeta raíz
• inicio npm
• el servidor lite se activa para https:// localhost: 10001

Implementar en un servidor web estático:

• copiar todas las carpetas excepto node_modules
• copiar index.html (y posiblemente web.config)

FUTURO

Uno de los principales objetivos es actualizar a Polymer3 y trabajar desde la CLI de Polymer. Agregar editores avanzados y un marco para que los desarrolladores de IOT desarrollen los suyos propios es una alta prioridad. Eventualmente, el sistema automatizado avanzado se ejecutará totalmente desde clientes MQTT independientes como AssimilateCrouton.

Un ejemplo del paquete deviceInfo utilizado para AssimilateCrouton:

{

"información del dispositivo": {

"endPoints": {

"CC_device": {

"nombre_dispositivo": "ash_mezz_A3",

"card-type": "assim-device",

"ssid": "Corelines_2",

"ip_addr": "192.168.8.104",

"endpoints": [

{

"title": "Grow Lights",

"card-type": "crouton-simple-toggle",

"endpoint": "cambiar"

},

{

"title": "Luces de macetero",

"card-type": "crouton-assim-weekview",

"endpoint": "CC_switch"

}

]

},

"CC_switch": {

"card-type": "assim-weekview",

"info": "Enciende o apaga las luces en intervalos de tiempo de 15 minutos",

"ruta": "https://192.168.8.104/cors",

"title": "Luces de macetero",

"intervalo_mins": 15,

"valores": {

"valor": ""

}

},

"cambiar": {

"title": "Grow Lights",

"card-type": "crouton-simple-toggle",

"info": "Enciende o apaga las luces según sea necesario",

"etiquetas": {

"falso": "DESACTIVADO",

"verdadero": "ACTIVADO"

},

"iconos": {

"falso": "sol",

"verdadero": "sol"

},

"valores": {

"valor": 0

}

}

},

"status": "bueno",

"nombre": "ash_mezz_A3",

"description": "Oficina en Ashmore, Mezzanine, Area A2",

"color": "# 4D90FE"

}

}

ver rawdeviceInfo.json alojado con ❤ por GitHub

Paso 3: MONTAJE DEL DISPOSITIVO

Como no hay cambios de hardware, aquí están los enlaces a la información relevante:

• Ensamblaje de Shell
• Materiales y herramientas
• Preparación MCU
• Preparación de la carcasa de MCU
• Construcción de la placa secundaria de RESET / Interruptor de lado bajo esclavos
• Ensamblaje de los componentes principales

Paso 4: FIRMWARE

PRINCIPALES CAMBIOS ESTE EDIFICIO

Para que la aplicación AssimilateCrouton pueda usar los recursos CORS del dispositivo, los encabezados de respuesta deben configurarse de una manera particular. Esto se implementó en esta versión del firmware (static_server.ino => server_file_read ()).

Además, el gráfico de dependencia principal para Polymer debía ser de un solo origen. Se utilizó una estrategia para agregar un controlador de error (corsLinkOnError) a los archivos SPIFFS CORS para recargar los recursos del sitio web AssimilateCrouton cuando no se encuentran en el dispositivo.

Se agregaron 2 convenciones nuevas al sistema de archivos SPIFFS para personalizar los puntos finales que se crean en deviceInfo, que AssimilateCrouton usa para crear las tarjetas del tablero:

• /config/user_card_base.json Definición de punto final con las variables de tiempo de ejecución que se intercambian primero:,,. Aquí es donde normalmente se agregará la tarjeta de dispositivo de asimilación. Esto no se comunica con el dispositivo.
• /config/user_card_#.json Definición de punto final con las variables de tiempo de ejecución intercambiadas primero:,,. Esto es típicamente donde los editores enriquecidos como la tarjeta assim-weekview se agregarán conectados al esclavo I2C (actor / sensor) que se relaciona con #.

EL BOSQUEJO / BIBLIOTECAS

En esta etapa, el proyecto se ha empaquetado como ejemplo para la biblioteca AssimilateBus Arduino. Esto es principalmente para facilitar el acceso a todos los archivos necesarios desde el IDE de Arduino. Los principales artefactos de código son:

• mqtt_crouton_esp8266_cors_webcomponents.ino: el punto de entrada principal.
• assimilate_bus.h / assimilate_bus.cpp - la biblioteca que maneja la comunicación I2C con el sensor esclavo / actores
• VizJson.h / VizJson.cpp: la biblioteca que formatea / construye cualquier JSON publicado a través de MQTT
• config.h / config.cpp: la biblioteca que lee / cajas / escribe archivos de configuración en SPIFFS
• static_i2c_callbacks.ino: las devoluciones de llamada I2C para una propiedad que se está recibiendo y el ciclo de solicitudes de esclavos se completa static_mqtt.ino: las funciones MQTT
• static_server.ino - las funciones del servidor web
• static_utility.ino - funciones auxiliares

Las funciones estáticas INO se utilizaron (en lugar de bibliotecas) por una variedad de razones, pero principalmente para que las funciones Webserver y MQTT pudieran funcionar bien juntas.

LOS RECURSOS SPIFFS

Aquí se pueden encontrar explicaciones detalladas de los archivos SPIFFS.

• favicon.ico - recurso utilizado por Ace Editor

• config

  • device.json: la configuración del dispositivo (Wifi, MQTT…)
  • slave_metas _ #. json - generado en tiempo de ejecución para cada número de dirección de esclavo (#)
  • user_card _ #. json: punto final personalizado que se integrará en deviceInfo para cada número de dirección de esclavo (#)
  • user_card_base.json: punto final personalizado que se integrará en deviceInfo para el dispositivo
  • user_meta _ #. json: los metadatos personalizados anulan los de los esclavos para cada número de dirección de esclavo (#)
  • user_props.json: nombres de propiedades personalizados para anular los que están en los metadatos de los esclavos

• cors

  • card-webcomponent.css: hoja de estilo para varias tarjetas personalizadas
  • card-webcomponent.html: componente web para varias tarjetas personalizadas

• editor

  • assimilate-logo-p.webp" />
  • edit.htm.gz - gzip de Ace Editor HTML
  • edit.htm.src - HTML original del Ace Editor
  • favicon-32x32-p.webp" />

CARGA DEL FIRMWARE

• El repositorio de código se puede encontrar aquí (instantánea).
• Puede encontrar un ZIP de la biblioteca aquí (instantánea).
• Instrucciones para "Importar una biblioteca ZIP" aquí.
• Una vez instalada la biblioteca, puede abrir el ejemplo "mqtt_crouton_esp8266_cors_webcomponents".
• Instrucciones para configurar Arduino para Wemos D1 Mini aquí.
• Dependencias: ArduinoJson, TimeLib, PubSubClient, NeoTimer (consulte los archivos adjuntos si se rompen los cambios en los repositorios).

SUBIR A SPIFFS

Una vez que el código se haya cargado en el IDE de Arduino, abra device.json en la carpeta data / config:

• Modifique el valor de wifi_ssid con su SSID WiFi.
• Modifique el valor de wifi_key con su clave WiFi.
• Modifique el valor de mqtt_device_name con su identificación de dispositivo preferida (no es necesario unirse).
• Modifique el valor de mqtt_device_description con su descripción de dispositivo preferida (en Crouton).
• Guarde device.json.
• Sube los archivos de datos a SPIFFS.

El punto de entrada principal para el ejemplo de AssimilateBus:

/*

*

* SE ESPERA QUE LAS REGLAS COMERCIALES DE SU DISPOSITIVO SE CONTROLEN A TRAVÉS DE MQTT, NO SE COCINAN DIFÍCILMENTE EN ESTE FIRMWARE

*

* Aparte de la configuración y el bucle en este archivo

* las partes móviles importantes son

* on_bus_received y on_bus_complete en static_i2c_callbacks.ino

* y

* mqtt_publish y mqtt_callback en static_mqtt.ino

*

*/

#include "types.h"

#include "VizJson.h"

#include "assimilate_bus.h"

#include "debug.h"

#include "config.h"

#incluir

#incluir // establece MQTT_MAX_PACKET_SIZE en ~ 3000 (o tus necesidades para deviceInfo json)

#incluir

#incluir

#incluir

#incluir

#incluir

// --------------------------------- DECLARACIONES DE MEMORIA

// ------------------------------------------------ - define

# defineDBG_OUTPUT_FLAG2 // 0, 1, 2 MÍNIMO, LIBERACIÓN, COMPLETO

#define_mqtt_pub_topic "outbox" // CONVENCIONES DE CROUTON

#define_mqtt_sub_topic "bandeja de entrada"

// ------------------------------------------------ - objetos de clase

Depurar _debug (DBG_OUTPUT_FLAG);

AssimilateBus _assimilate_bus;

VizJson _viz_json;

Config _config_data;

WiFiClient _esp_client;

PubSubClient _client (_esp_client);

WiFiUDP Udp;

ESP8266WebServer _server (80);

Neotimer _timer_property_request = Neotimer (5000);

// ------------------------------------------------ - estructuras de datos / variable

RuntimeDeviceData _runtime_device_data;

PropertyDto _dto_props [50]; // max 10 esclavos x max 5 propiedades

// ------------------------------------------------ -- flujo de control

volatilebool _sent_device_info = false;

byte _dto_props_index = 0;

bool _fatal_error = false;

// --------------------------------- DECLARACIONES DEL ALCANCE DE LA FUNCIÓN

// ------------------------------------------------ - static_i2c_callbacks.ino

voidon_bus_received (byte slave_address, byte prop_index, rol de rol, nombre de carácter [16], valor de carácter [16]);

voidon_bus_complete ();

// ------------------------------------------------ - static_mqtt.ino

voidmqtt_callback (char * tema, byte * carga útil, longitud unsignedint);

voidmqtt_loop ();

int8_tmqtt_get_topic_index (char * tema);

voidmqtt_init (constchar * wifi_ssid, constchar * wifi_password, constchar * mqtt_broker, int mqtt_port);

voidmqtt_create_subscriptions ();

voidmqtt_publish (char * root_topic, char * deviceName, char * endpoint, constchar * payload);

boolmqtt_ensure_connect ();

voidmqtt_subscribe (char * root_topic, char * deviceName, char * endpoint);

voidi2c_set_and_get (dirección de byte, código de byte, constchar * param);

// ------------------------------------------------ - static_server.ino

String server_content_type_get (String nombre de archivo);

boolserver_path_in_auth_exclusion (ruta de la cadena);

boolserver_auth_read (Ruta de la cadena);

boolserver_file_read (ruta de la cadena);

voidserver_file_upload ();

voidserver_file_delete ();

voidserver_file_create ();

voidserver_file_list ();

voidserver_init ();

voidtime_services_init (char * ntp_server_name, byte time_zone);

time_tget_ntp_time ();

voidsend_ntp_packet (dirección IP y dirección);

char * time_stamp_get ();

// ------------------------------------------------ - static_utility.ino

String spiffs_file_list_build (Ruta de la cadena);

voidreport_deserialize_error ();

voidreport_spiffs_error ();

boolcheck_fatal_error ();

boolget_json_card_type (byte dirección_esclavo, byte índice_prop, char * tipo_tarjeta);

boolget_struct_card_type (byte dirección_esclava, byte índice_prop, char * tipo_tarjeta);

boolget_json_is_series (byte dirección_esclava, byte índice_prop);

voidstr_replace (char * src, constchar * oldchars, char * newchars);

byte get_prop_dto_idx (byte dirección_esclavo, byte índice_prop);

//---------------------------------PRINCIPAL

voidsetup () {

DBG_OUTPUT_PORT.begin (115200);

SetupDeviceData device_data;

Serial.println (); Serial.println (); // margen para la basura de la consola

retraso (5000);

si (DBG_OUTPUT_FLAG == 2) DBG_OUTPUT_PORT.setDebugOutput (verdadero);

_debug.out_fla (F ("configuración"), verdadero, 2);

// obtener la configuración requerida

si (SPIFFS.begin ()) {

_debug.out_str (spiffs_file_list_build ("/"), verdadero, 2);

if (! _config_data.get_device_data (device_data, _runtime_device_data)) {

report_deserialize_error ();

regreso;

}

}demás{

report_spiffs_error ();

regreso;

}

// usa el valor del temporizador establecido en device.json

_timer_property_request.set (device_data.sensor_interval);

mqtt_init (device_data.wifi_ssid, device_data.wifi_key, device_data.mqtt_broker, device_data.mqtt_port);

time_services_init (device_data.ntp_server_name, device_data.time_zone);

server_init ();

// inicia la recopilación de metadatos

_assimilate_bus.get_metadata ();

_assimilate_bus.print_metadata_details ();

mqtt_ensure_connect ();

// necesita la propiedad del sensor (nombres) para completar la recopilación de metadatos

_assimilate_bus.get_properties (en_bus_received, en_bus_complete);

_timer_property_request.reset (); // puede transcurrir un tiempo notable hasta este punto, así que comienza de nuevo

}

voidloop () {

if (! check_fatal_error ()) return;

mqtt_loop ();

_server.handleClient ();

if (_timer_property_request.repeat ()) {

_assimilate_bus.get_properties (en_bus_received, en_bus_complete);

}

}

ver rawmqtt_crouton_esp8266_cors_webcomponents.ino alojado con ❤ por GitHub

Paso 5: TARJETA DE DISPOSITIVO

La tarjeta del dispositivo (card-type: assim-device) está alojada en el sitio web y no es necesario servirla desde el dispositivo (CORS).

Sus listas de páginas predeterminadas:

• Los temas de MQTT para leer y escribir en el dispositivo
• El punto de acceso al que está conectado el dispositivo
• Un enlace al editor de archivos SPIFFS alojado en el dispositivo usando ACE EDITOR
• Un icono de ojo que revela la página de la tarjeta Mostrar / Ocultar.

La página Mostrar / Ocultar tarjeta enumera:

• Cada tarjeta como un artículo separado
• Fuente azul en negrita al mostrar
• Fuente normal negra cuando está oculta
• Un icono que representa el tipo de tarjeta.

La tarjeta se puede ocultar haciendo clic en el botón ocultar en las tarjetas o haciendo clic en un elemento de fuente azul en negrita de la lista. Las tarjetas se pueden mostrar haciendo clic en un elemento de fuente normal negro en la lista.

Vagamente relacionado con esta característica está el brindis de información. Si alguno de los puntos finales en deviceInfo tiene una propiedad de información asignada, se mostrará un botón de información junto al botón de ocultar en la tarjeta. Cuando se hace clic en la información contextual definida en el punto final, se "brindará" a la ventana.

Si la tarjeta del dispositivo no está definida, los botones de ocultar no se mostrarán en las tarjetas. Esto se debe a que una vez ocultos no hay forma de volver a mostrarlos.

Consulte PERSONALIZACIÓN DE ENDPOINT para obtener detalles sobre cómo se puede agregar la tarjeta de dispositivo de asimilación a través de los archivos SPIFFS en el ESP8266.

AssimilateCrouton WebComponent

señales-de-hierro>

div>

MOSTRAR OCULTAR ICONO

i> span>

FORMULARIO DE DISPOSITIVO

TEMAS MQTTdiv>

/ outbox / {{endPointJson.device_name}} / * div>

/ inbox / {{endPointJson.device_name}} / * div>

WIFI SSIDdiv>

{{endPointJson.ssid}} div>

DIRECCIÓN IPdiv>

{{endPointJson.ip_addr}} a> div>

div>

MOSTRAR OCULTAR LISTA

elemento>paper-item>

plantilla>

cuadro de lista de papel>

div>

tarjeta de crutones>

plantilla>

dom-módulo>

ver rawassim-device.html alojado con ❤ por GitHub

Paso 6: TARJETA WEEKVIEW

La tarjeta weekview (card-type: assim-weekview) está alojada en el dispositivo (carpeta cors). Se inyecta en el paquete deviceInfo publicado para AssimilateCrouton, agregando un archivo config / user_card _ #. Json a SPIFFS (en este caso user_card_9.json).

VISIÓN DE CONJUNTO

Los días de la semana se presentan como listas de franjas horarias. La granularidad del intervalo de tiempo se establece con la propiedad "interval_mins" en config / user_card _ #. Json. Debe ser una fracción de hora o múltiplos de una hora, p. Ej. 10, 15, 20, 30, 60, 120, 360. Al hacer clic en un intervalo de tiempo, asegúrese de que se ordena un estado de encendido para el dispositivo asociado en ese momento. Si el intervalo de tiempo es ahora, se envía (publica) un comando inmediatamente para el dispositivo. Normalmente, el estado se revisa / publica cada minuto. Las selecciones se guardan en LocalStorage, por lo que las horas se volverán a cargar con una actualización del navegador.

CASOS DE USO

En su estado actual, la vista semanal es adecuada para dispositivos que pueden usar un interruptor de palanca para visualizar su estado, es decir, están encendidos o apagados y, una vez configurados, permanecen en ese estado. Las luces, los ventiladores y los calentadores de agua son buenos candidatos.

LIMITACIONES / AVISOS

• El intervalo_mins debe ser uno de los valores mencionados anteriormente.
• La vista semanal no admite acciones momentáneas que también están programadas, como abrir un grifo brevemente (5 segundos) dos veces al día.

FUTURO

• Se espera que se apoyen acciones momentáneas.
• Se está considerando el almacenamiento sincronizado entre dispositivos, para las selecciones de programación.

Paso 7: PERSONALIZACIÓN DE PUNTOS FINALES

Como se mencionó brevemente en FIRMWARE, hay 2 nuevas convenciones agregadas al sistema de archivos SPIFFS para personalizar los puntos finales. Los archivos JSON son fragmentos que se agregan a la propiedad de los puntos finales en el paquete deviceInfo publicado en el agente MQTT que se convierte en la definición del panel.

Las claves de los endpoints se generan en firmware:

• CC_device (tarjeta personalizada) para user_card_base.json
• CC_SLAVE_ENDPOINT NAME para la user_card _ #. Json (# es la dirección del esclavo)

Como se mencionó anteriormente, hay variables que se sustituyen por valores en tiempo de ejecución:

• mqtt_device_name
• wifi_ssid
• local_ip

user_card_base.json

Un ejemplo:

tarjeta_usuario _ #. json

Un ejemplo:

Paso 8: VIDEOS