dsn="postgres://chirpstack_as:dbpassword@localhost/chirpstack_as?sslmode=disable"
marshaler="json"<
# JWT secret used for api authentication / authorization
# You could generate this by executing 'openssl rand -base64 32' for example
jwt_secret="------------------"
Para revisar el estado o reiniciar el componente, se usa el la instrucción:
sudo systemctl status chirpstack-application-server
sudo systemctl restart chirpstack-application-server
De encontrarse todo en funcionamiento, debe ser posible acceder a la versión web de Chirpstack en la dirección IP y puerto (8080)
El network-server es el componente que se dedica a revisar los mensajes duplicados en la red, ya sea por re-intentos de transmisión desde un mismo dispositivo o por recepción de mensajes en más de un gateway.
Además de encargarse de la autenticación , capa MAC, comunicación con el componente de aplicaciones y gestión de colas de mensajes de envió hacia dispositivos.
Base de datos de mensajes
Para manejar los mensajes es necesario disponer de una base de datos. PostgreSQL es la base de datos predeterminada.
En caso de no disponer de la base de datos, la puede instalar siguiendo las instrucciones en:
Usada para guardar los datos de cada sesión , datos no persistentes, de duplicación y meta-data.
sudo apt install redis-server
Instalación de ChirpStack-network-server
Semejante al componente anterior, se añaden las referencias del repositorio de los archivos de instalación para ejecutar luego el proceso de instalación.
[general]
log_level=4
[postgresql]
dsn="postgres://chirpstack_ns:dbpassword@localhost/chirpstack_ns?sslmode=disable"
[network_server.band]
name="US915"
cambiar a comentario la seccion:
# Extra channel configuration.
Revisar el detalle de la línea dsn, pues el usuario al final de la línea vienen escrito con doble _ns_ns.
Añadir al final del archivo los datos de usuario y contraseña para el servicio MQTT
Para revisar el estado del componente se usa el la instrucción:
sudo systemctl status chirpstack-network-server
sudo systemctl restart chirpstack-network-server
debiendo obtener una respuesta semejante a
Para revisar el historial de actividad (log) y verificar operatividad
Es el componente que convierte el protocolo LoRa-packet-forwarder en el formato de datos de ChirpStack-network-server que es el siguiente componente.
Para la gestión de mensajes se usa un servidor MQTT existente y previamente configurado. Si no se dispone de uno, se puede instalar y configurar siguiendo las instrucciones de MQTT – Mosquitto instalar
Instalación de ChirpStack-gateway-bridge v4.x
Las instrucciones para Raspberry OS se encuentran simplificadas, las primeras son para acceder al repositorio de instalación y la siguiente para instalar el componente.
La conexión al servidor MQTT se configura en el archivo, para el ejemplo se ha mantenido la simplicidad al no requerir usuario y contraseña para interactuar con Mosquitto. Recuerde cambiar esta situación una vez que esten terminadas todas las configuraciones y se ha probado la operatividad del mismo.
# Integration configuration.
[integration]
# Payload marshaler.
#
# This defines how the MQTT payloads are encoded. Valid options are:
# * protobuf: Protobuf encoding
# * json: JSON encoding (easier for debugging, but less compact than 'protobuf')
marshaler="json"
# MQTT integration configuration.
[integration.mqtt]
# Event topic template.
event_topic_template="gateway/{{ .GatewayID }}/event/{{ .EventType }}"
# Command topic template.
command_topic_template="gateway/{{ .GatewayID }}/command/#"
# MQTT authentication.
[integration.mqtt.auth]
# Type defines the MQTT authentication type to use.
#
# Set this to the name of one of the sections below.
type="generic"
# Generic MQTT authentication.
[integration.mqtt.auth.generic]
# MQTT server (e.g. scheme://host:port where scheme is tcp, ssl or ws)
server= "tcp:///127.0.0.1:1883"
#"tcp://127.0.0.1:1883"
# Connect with the given username (optional)
username=""
# Connect with the given password (optional)
password=""
Para revisar el estado del componente se usa la instrucción
sudo systemctl status chirpstack-gateway-bridge
en el caso de que se requiera reiniciar el componente
sudo systemctl restart chirpstack-gateway-bridge
El estado del gateway-bridge será semejante a:
Mensajes en MQTT-Mosquitto
Los eventos y mensajes MQTT son semejantes a lo mostrado, revisando todos los mensajes que llegan a Mosquitto: se puede usar la instrucción.
Para leer los contenidos de la configuración desde MQTT será necesario cambiar al formato a "json" en el archivo de configuración del gateway bridge.
Los estados de los mensajes en formato json se observan en la imagen.
mientras en formato "protobuf" se observa de la siguiente manera:
Observe que en ambas situaciones es posible leer solo los valores correspondientes a los parámetros de transmisión, sin embargo los datos de usuario permanecen ilegibles.
Para integrar esta red a IOT en esquema abierto se ha seleccionado como gestor de gateways a ChirpStack, pues se integra a la gestión de paquetes y al gestor de mensajes MQTT versión Mosquitto.
De esta forma se genera un punto intermedio para integrar las conexiones con otros brokers de forma simplificada.
Dado que el servidor MQTT es parte del IOT Esquema Abierto, las instrucciones de instalación y configuración ya se encuentran descritas en:
Para el módulo HT-M01, el fabricante Heltec publicó una aplicación para gestionar los paquetes denominado packet-forwarder, encargada de reenviar los paquetes a un administrador de gateways.
Los datos recibidos por el módulo gateway son reenviados por SPI o el puerto USB hacia la red local o internet usando el aplicativo instalado en un Raspberry Pi.
En las pruebas con USB se encontró que para reiniciar el módulo HT-M01 es necesario presionar el botón Reset, mientras que en el modo SPI se podía realizar de forma remota, por lo que se prefiere configurar el modo SPI.
Activar interface SPI
En Raspberry OS la interface SPI requiere activarse para su uso con la siguiente instrucción:
sudo raspi-config
Que permite seleccionar de una ventana las opciones de interface
para luego activar SPI
Conexión mediante SPI
Las instrucciones paso a paso se describen más adelante, para la ultima instrucción hay que tener disponible la configuración de región. Para el caso de Ecuador es US915.
Cada instrucción se debe realizar en secuencia, el el penúltimo paso se obtiene el Gateway _id, que será usado para registrar el mini gateway en el servidor de red y aplicaciones.
Nota 2026-03: En Raspbian OS se recomienda usar un nombre de usuario diferente de "pi", por lo que se deben ajustar las direcciones en las instrucciones al usuario en las ultimas instrucciones.
En el directorio "lorasdk" Edite el archivo "install.sh" y "lrgateway.service" para evitar errores de donde se encuentra el archivo. Por ejemplo en install.sh, se editan las líneas con sudo nano install.sh
actualizado los archivos, se puede continuar con las correcciones en los directorios:
# This package will create a "lrgateway" service in Raspberry Pi cd /home/pi/lora/lora_gateway make clean all cd /home/pi/lora/packet_forwarder make clean all cd /home/pi/lora/lorasdk chmod +x install.sh ./install.sh #Run the script. After the script is run, it will create a # service named "lrgateway". The purpose is to make the lora driver # and data forwarding program run automatically at startup. sudo cp -f /home/pi/lora/lorasdk/global_conf_US915.json /home/pi/lora/packet_forwarder/lora_pkt_fwd/global_conf.json #the "global_conf_US915.json" may need change to your need.
Cambios para Raspberry pi OS Trixie 2026-03
En la versión Bookworm y Trixie, las instrucciones para manejar GPIOs han migrado a pinctrl, por lo que se debe actualizar el archivo /lora/packet_forwarder/lora_pkt_fwd.sh
# Force bypassing auto update of Gateway_ID in JSON conf file IOT_SK_GWID_UPDATE=true
# The reset pin of SX1301 is wired with RPi GPIO2 IOT_SK_SX1301_RESET_PIN=17
# set GPIO 17 as output echo "out" #> /sys/class/gpio/gpio$IOT_SK_SX1301_RESET_PIN/direction; WAIT_GPIO
# write output for SX1301 reset pinctrl set 17 op dh WAIT_GPIO pinctrl get 17 echo "1" #> /sys/class/gpio/gpio$IOT_SK_SX1301_RESET_PIN/value; WAIT_GPIO pinctrl set 17 op dl pinctrl get 17 WAIT_GPIO echo "0" #> /sys/class/gpio/gpio$IOT_SK_SX1301_RESET_PIN/value; WAIT_GPIO # set GPIO 17 as input pinctrl set 17 ip pinctrl get 17 WAIT_GPIO echo "in" #> /sys/class/gpio/gpio$IOT_SK_SX1301_RESET_PIN/direction; WAIT_GPIO }
iot_sk_term() { echo "iot_sk_term" # cleanup GPIO 17 pinctrl get 17 echo " term reiniciando" if [ -d /sys/class/gpio/gpio$IOT_SK_SX1301_RESET_PIN ] then pinctrl get 17 echo " iot_sk_term en if "$IOT_SK_SX1301_RESET_PIN" ..." #> /sys/class/gpio/unexport; WAIT_GPIO fi }
Conexión al puerto USB
Las instrucciones son muy semejantes al proceso anterior, para la ultima instrucción hay que tener disponible la configuración de región. Para el caso de Ecuador es US915.
Cada instrucción se debe realizar en secuencia, el el penúltimo paso se obtiene el Gateway _id, que será usado para registrar el mini gateway en el servidor de red y aplicaciones
Si el módulo fue instalado en el proceso anterior, no es necesario ejecutar esta sección
mkdir lora
cd lora
sudo apt-get update
sudo apt-get install git
git clone https://github.com/Lora-net/picoGW_hal.git
git clone https://github.com/Lora-net/picoGW_packet_forwarder.git
git clone https://github.com/HelTecAutomation/picolorasdk.git
cd /home/pi/lora/picoGW_hal
make clean all
cd /home/pi/lora/picoGW_packet_forwarder
make clean all
cd /home/pi/lora/picolorasdk
chmod +x install.sh
./install.sh
#Run this script will create a service named "lrgateway". The purpose is to make the lora driver and data forwarding program run automatically at startup.
sudo cp -f /home/pi/lora/picolorasdk/global_conf_US915.json /home/pi/lora/picoGW_packet_forwarder/lora_pkt_fwd/global_conf.json
#Put the configuration file on the specified path
Estado de Packet-forwarder
Las instrucciones de instalación se encuentran en:
HT-M01 Mini LoRa Gateway Quick Start. Heltec.org. Revisado Septiembre 2023
El archivo local contiene la identificación del gateway obtenida luego de ejecutar la línea ./install.sh del proceso anterior. El archivo global contiene la información de la región y las frecuencias usadas.
El archivo "global_conf.json" se configura el servidor donde se encuentra el gateway-bridge usando el parámetro "server_address". Si se encuentra en el mismo Raspberry Pi que el Packet-forwarder se usa "localhost", sino con la dirección IP respectiva. También hay que actualizar los parámetros para el "gateway_ID" obtenido al final del proceso al instalar el packet-forwarder.
"gateway_conf": {
"gateway_ID": "3532363324003700",
/* change with default server address/ports, or overwrite in local_conf.json */
"server_address": "192.168.10.50",
"serv_port_up": 1700,
"serv_port_down": 1700,
/* adjust the following parameters for your network */
"keepalive_interval": 10,
"stat_interval": 30,
"push_timeout_ms": 100,
/* forward only valid packets */
"forward_crc_valid": true,
"forward_crc_error": false,
"forward_crc_disabled": false
}
Conexión a TTN
El archivo "global_conf.json" se configura para un servidor TTN de la regíon, revisar los datos apropiador para "gateway_ID" y "server_address".
"gateway_conf": {
"gateway_ID": "3532363324003700",
/* change with default server address/ports, or overwrite in local_conf.json */
"server_address": "router.us.thethings.network",
"serv_port_up": 1700,
"serv_port_down": 1700,
/* adjust the following parameters for your network */
"keepalive_interval": 10,
"stat_interval": 30,
"push_timeout_ms": 100,
/* forward only valid packets */
"forward_crc_valid": true,
"forward_crc_error": false,
"forward_crc_disabled": false
}
Durante la implementación realizada, no se disponía del adaptador por lo que se probó construir un adaptador usando una placa perforada, teniendo los mismos resultados que con la placa de HELTEC.
El Kit de conexión del fabricante como referencia se muestra a continuacion:
El esquema abierto para un gateway LoRa de bajo costo, desagrega e interconecta componentes de hardware y software.
El mini-gateway es modular, el componente de software para la gestión de gateways y paquete de datos se implementa sobre un Raspberry Pi, conectado por Ethernet a la red local y con dirección IP fija.
En el manejo de software se prioriza integrar la gestión de dispositivos usando mensajes MQTT y de esta manera simplificar la integración al broker del esquema IoT general.
Componentes
El punto de partida la propuesta es gateway entre LoRa y Ethernet/Wifi. El fabricante Heltec presenta un "mini-Gateway" con el Módulo HT-M01. El módulo de hardware se conecta por medio del software "Packet-forwarder" (en un Raspbery Pi) hacia un administrador de gateways que puede estar en la red local (ChirpStack) o en la nube (The Things Network).
La conexión del módulo HT-M01 se puede realizar con SPI usando una placa de conexión hacia el Raspberry Pi. Si no se tiene la placa, también se la puede construir siguiendo las instrucciones en:
El proceso de instalación del Raspberry Pi se encuentra descrito en la Raspberry Pi OS-Instalar.
Packet-forwarder se instala siguiendo las instrucciones del fabricante.
Inicialmente se usó USB como conexión del módulo Heltec HT-M01, luego se usó SPI solo para comprobar las modalidades de implementación. Se utiliza SPI en la versión de operación regular.
Conexión entre componentes
módulo Heltec HT-M01 y Raspberry, SPI o USB
Ethernet desde la Raspberry Pi , usando dirección fija
La conexión Ethernet facilita la comunicación con el esquema existente y en operación, facilitando la ubicación de los componentes de software en otros "servidores" en los Raspberry Pi.
Hardware con Raspberry pi Zero y adaptador Ethernet
Para el caso de usar mas de un Gateway LoRa con Raspberry Pi Zero que no tiene conector Ethernet, se requiere un adaptador USB a Ethernet.
Algunos adaptadores USB a Ethernet "económicos" tienen la misma dirección Mac que al utilizar varios en una red local (todos en el mismo segmento) genera inconvenientes en la comunicación.
La dirección MAC se puede revisar con la instrucción:
Para registrar los eventos de un determinado dispositivo para analizar su comportamiento y registrarlo en un archivo txt se puede usar la librería Paho en Python. El proceso de registro desde luego se puede realizar en un gestor de datos como Home Assistant, se supondrá en éste caso que no está disponible..
Se crea un archivo, al que se añade una linea por cada registros de mensajes MQTT.
Para el ejemplo los datos de guardan sin procesar.
# grabando mensajes MQTT# configurar los parámetros para la creacion de archivo de textoimport paho.mqtt.client as mqtt
# INGRESO# Parametros para la conexión
servidormqtt = "192.168.xx.xx"
topicolee = "oficina/+/dispositivo/#"# Para el archivo.txt
cuentamensaje = 0
nombrearchivo = 'unreporte.txt'
archivo = open(nombrearchivo,'w')
archivo.close() # Cierra el archivo# FUNCIONES, para conectar y recibir mensaje MQTT# Al recibir CONNACK desde el servidor.defon_connect(client, userdata, flags, rc):
print("Conexión/código de resultado: "+str(rc))
# Inicio o renovación de subscripción
client.subscribe(topicolee)
return()
# el tópico tiene una publicacióndefon_message(client, userdata, msg):
global cuentamensaje
print(msg.topic+" "+str(msg.payload))
unmensaje = msg.topic+" "+str(msg.payload)
# Archivo en modo añadir 'append'
archivo = open(nombrearchivo,'a')
unalinea = unmensaje + '\n'
archivo.write(unalinea)
cuentamensaje = cuentamensaje + 1
print('\n mensajes recibidos: ', cuentamensaje)
return()
client = mqtt.Client()
client.on_connect = on_connect
client.on_message = on_message
client.connect(servidormqtt, 1883, 60)
client.loop_forever()
Archivos py o txt desde PC a Raspberry Pi
Para transferir los archivos de Python o de texto generados se encuentra dispobible la instrucción scp. Luego de ejecutar la instrucción se pedirá la clave de acceso del usuario pi para copiar el archivo en el directorio proyecto/
scp archivo.py pi@192.168.xx.xx:projecto/
Para el caso contrario se usa una instrucción semejante pero con los parametros al contrario, observe que termina en un "."
scp pi@192.168.xx.xx:projecto/archivo.txt .
En el enlace de la referencia se encuentran más instrucciones al respecto
Los mensajes MQTT que se transmiten como texto simple en la red (inalambrica) y podrían ser leidos con algún software de inspección de tráfico de red. Para añadir un nivel de seguridad con los mensajes MQTT se usa TLS.
Esta sección consta de dos partes:
- creación de los certificados para CA, broker y dispositivos
- configuración de Mosquitto
1. Creación de Certificados
Son archivos que contienen las "llaves" de encriptación que se deben crear o generar para poder realizar todo el proceso de validación. Esta sección considera que las llaves serán usadas de forma local, por lo que la certificación de las llaves se realiza en el mismo broker (self-signed certificate).
La generación de llaves se realiza con la aplicación "OpenSSL" que se incluye con Raspberry OS y para esta ocasión se ejecuta desde un terminal local o remoto (ssh).
Se requieren llaves y certificados para el broker y para cada cliente
1.1 CA - Certificate authority
Se require una "entidad" para crear los certificados y las llaves usadas en el proceso, concocida como CA. Los archivos creados de guardan en la carpeta:
cd /etc/mosquitto/ca_certificates/
primero se crea la llave, que require establecer una frase para generar el archivo, ejemplo: "mqttasegurado" o alguna que le permita establecer una contraseña para la generación de los todos los siguientes certificados y llaves. Anote la frase en algun lugar a su alcance para los próximos pasos.
sudo openssl genrsa -des3 -out mqtt-ca.key 2048
la instrucción genera la siguiente
Generating RSA private key, 2048 bit long modulus (2 primes)
...........................................+++++
.+++++
e is 65537 (0x010001)
Enter pass phrase for mqtt-ca.key:
Verifying - Enter pass phrase for mqtt-ca.key:
El certificado CA firmado con la llave creada en el paso anterior, requiere añadir información adicional como: país, provincia, ciudad e institución para asociar al certificado.
En CN (Common Name) use el nombre en la red o IP fijo del broker, ejemplo: 192.168.10.40
La información en la parte "-subj" permite disponer de un contacto en caso que sea necesario actualizar el archivo del certificado.
Recuerde revisar los permisos de lectura en el directorio de los archivos para los certificados con la instruccion ls -l. pues se requiere poder leerlos para generar las llaves de clientes. Por ejemplo:
pi@raspberry:/etc/mosquitto/ca_certificates $ ls -l
-rw-r--r-- 1 root root 1196 mar 26 22:46 mqtt-ca.crt
-rw-r--r-- 1 root root 1751 mar 26 22:40 mqtt-ca.key
-rw-r--r-- 1 root root 41 mar 26 23:05 mqtt-ca.srl
-rw-r--r-- 1 root root 73 nov 16 2019 README
pi@raspberry:/etc/mosquitto/certs $
si requiere cambiarlos usar la instrucción: sudo chown usuario archivo, o en otro caso cambiar los permisos de lectura para todos los demás.
sudo chmod g+r mqtt-ca*
1.2 TLS - broker Mqtt
Los certificados del broker y usuarios se crean en el directorio 'certs', por lo que se cambia de directorio con la instrucción:
cd /etc/mosquitto/certs/
se genera la llave para el broker
sudo openssl genrsa -out mqtt-srv.key 2048
Creación del certificado para el Broker usando la llave del paso anterior.
En CN (Common Name) use el nombre o IP del broker, ejemplo: 192.168.10.50. Este valor es el mismo nombre a usar en la conexión del cliente.
Para usar en la programación del archivo.ino del dispositivo.
openssl x509 -noout -in mqtt-srv.crt -fingerprint
Recuerde revisar los permisos de lectura de los certificados, y modifique los que sean necesarios.
Realizar lo mismo de los permisos que para el directorio /etc/mosquitto/ca_certificates
2. Configuración de Mosquitto
La configuración del broker debe contener cuáles son los certificados para la encriptación de los mensajes.
La configuración del broker mosquitto se encuentra en el archivo /etc/mosquitto/mosquitto.conf que se modifica para activar la encriptación con TLS.
El archivo de configuración se abre desde la consola con la instrucción:
sudo nano /etc/mosquitto/mosquitto.conf
Se añaden las instrucciones:
# Port to use for the default listener.
port 8883
# "c_rehash " each time you add/remove a certificate.
#capath
cafile /etc/mosquitto/ca_certificates/mqtt-ca.crt
# Path to the PEM encoded server certificate.
certfile /etc/mosquitto/certs/mqtt-srv.crt
# Path to the PEM encoded keyfile.
keyfile /etc/mosquitto/certs/mqtt-srv.key
# This option defines the version of the TLS protocol to use for this listener.
# The default value allows v1.2, v1.1 and v1.0, if they are all supported by
# the version of openssl that the broker was compiled against. For openssl >=
# 1.0.1 the valid values are tlsv1.2 tlsv1.1 and tlsv1. For openssl < 1.0.1 the
# valid values are tlsv1.
tls_version tlsv1.2
para activar los cambios, deber reiniciar mosquitto con la instrucción:
sudo systemctl restart mosquitto
Verifique el estado del servidor MQTT desde una consola remota con ssh:
systemctl status mosquitto
con lo que se obtiene mensajes semejantes a:
● mosquitto.service - Mosquitto MQTT v3.1/v3.1.1 Broker
Loaded: loaded (/lib/systemd/system/mosquitto.service; enabled; vendor preset: enabled)
Active: active (running) since Sun 2019-08-11 14:16:50 -05; 9min ago
Docs: man:mosquitto.conf(5)
man:mosquitto(8)
Main PID: 394 (mosquitto)
Tasks: 1 (limit: 2200)
Memory: 2.4M
CGroup: /system.slice/mosquitto.service
└─394 /usr/sbin/mosquitto -c /etc/mosquitto/mosquitto.conf
ago 11 14:16:50 raspberrypi mosquitto[394]: 1565551010: Config loaded from /etc/mosquitto/mosquitto.conf.
ago 11 14:16:50 raspberrypi mosquitto[394]: 1565551010: Opening ipv4 listen socket on port 8883.
revise que todo esté funcionando sin inconvenientes, que el puerto 8333 sea el que esté activo.
Para cada dispositivo que se use para enviar o recibir un mensaje Mqtt se define como un cliente. Cada cliente necesita su propia llave que debe ser firmada por la CA para que sea aceptada en las conexiones TLS.
para generar los certificados podemos regresar al directorio:
cd /etc/mosquitto/certs/
En adelante, llamaremos al dispositivo "sensor00" como identificador en cada proceso. Se genera la llave para "sensor00"
sudo openssl genrsa -out sensor00-client.key 2048
se crea una solicitud de forma para la llave. El valor de CN debe ser el nombre del dispositivo FQDN o una dirección IP fija.
Para las pruebas, se puede usar la consola remota o una laptop conectada a la misma red que el broker. Recuerde actualizar los datos en la sección "subj"
al ejecutar la instrucción, se pide la frase del certificado, la ingresa y obtiene:
Enter PEM pass phrase:
Client mosqsub|1557-raspberry sending CONNECT
Client mosqsub|1557-raspberry received CONNACK (0)
Client mosqsub|1557-raspberry sending SUBSCRIBE (Mid: 1, Topic: oficina/mensaje, QoS: 0)
Client mosqsub|1557-raspberry received SUBACK
Subscribed (mid: 1): 0
ON
Puede cambiar el estado con mosquitto_pub se escribe una instrucción semejante añadiendo el mensaje -m 'ON'. Esta instrucción usa otro cliente: sendor01.
Otra opción para probar la conexión es usando un programa desde una PC y con el certificado de cliente, por ejemplo MQTT.FX que lo puede descargar de forma gratuita.
Realice una copia del certificado de cliente en la pc donde instala el programa MQTT.FC en un directorio de trabajo.
Use los parámetros requeridos para la conexión en la ventana del menú "extras/edit/connection profiles" para usuario y clave, TLS, etc
Se presiona conectar a MQTT, luego se suscribe al tópico de interés y se puede publicar en el mismo tópico.
5 Revisar conexión SSL
Sustituir IP_ADDRESS con la dirección IP antes de usar la instrucción.
