Sensores LoRa sin wifi en Home Assistant: Meshtastic por HACS o por MQTT

Un invernadero en el fondo del campo, una bodega al otro lado del predio, una casa de veraneo donde el wifi no llega ni con repetidor. Son los lugares donde más te interesa saber si va a helar o si la humedad se disparó, y justo ahí no hay red. Un nodo Meshtastic resuelve la mitad del problema: mide temperatura y humedad y manda el dato por radio LoRa, sin wifi ni plan de datos, a varios cientos de metros (o kilómetros, con buena línea de vista). La otra mitad es que ese dato termine en Home Assistant, con historial, gráficos y alertas al celular.

En esta guía vas a armar ese puente. Un Raspberry Pi con radio LoRa queda en tu casa conectado a la red, escucha todo lo que circula por el mesh y se lo entrega a Home Assistant. Hay dos caminos para hacerlo y los vas a ver los dos: la integración de Meshtastic vía HACS, que crea los sensores sola, y el camino por MQTT, que usa solo lo que Home Assistant trae de fábrica. Al final vas a tener la temperatura y la humedad de un sensor remoto en tu panel, y mensajes de texto que viajan en ambas direcciones: del mesh a una notificación en tu celular y de una automatización de Home Assistant de vuelta al mesh.

Cómo viaja el dato: del sensor al panel

Antes de tocar configuraciones conviene tener claro el recorrido, porque casi todos los errores de este montaje salen de confundir quién hace qué.

1. El nodo sensor (el que dejas en el invernadero) mide y transmite por LoRa en el canal por defecto del mesh. No sabe nada de redes, de MQTT ni de Home Assistant.
2. El nodo puente (el Raspberry Pi con su HAT LoRa y meshtasticd) recibe ese paquete como recibe cualquier otro del mesh.
3. El puente lo entrega a Home Assistant: o bien Home Assistant se conecta directo a él por TCP (camino de la integración), o bien el puente publica cada paquete en el broker MQTT (camino MQTT).
4. Home Assistant saca de cada paquete el valor que le interesa y lo guarda como entidad.

De ahí salen dos ideas que te van a ahorrar tiempo. La primera: el nodo sensor no necesita ninguna configuración de red, solo estar al alcance de radio del puente (directo o saltando por otros nodos). La segunda: el puente trabaja para todo el mesh, no solo para tu sensor. Si hay otros nodos en la zona, sus paquetes también van a llegar a Home Assistant, cada uno con su número de origen, y vas a tener que filtrar.

El hardware

El montaje del tutorial original, hecho por raspberry.tips con equipos de RAKwireless, tiene dos piezas:

• El puente: un Raspberry Pi 5 con su fuente oficial de 27 W, un HAT LoRa (WisMesh Pi HAT RAK6421 con el módulo de radio RAK13300, basado en el chip SX1262) y meshtasticd, la versión de Meshtastic que corre como servicio en Linux. Si todavía no lo tienes andando, primero instala meshtasticd y deja el nodo emparejado con la app.
• El nodo sensor: un WisMesh RAK4631 Starter Kit (microcontrolador nRF52840 con radio SX1262) con el sensor RAK1901 de temperatura y humedad, emparejado con la app de Meshtastic en el celular.

Además necesitas Home Assistant funcionando y, según el camino que elijas, HACS o la aplicación "Mosquitto broker" (antes se llamaba add on) con la integración MQTT. Para el camino MQTT conviene tener también MQTT Explorer en el computador, para ver qué está llegando al broker.

Frecuencia: en Chile no es 868 MHz

El original usa hardware de 868 MHz, que es la banda europea. En Chile se usan los equipos de 915 MHz, y al configurar el nodo en la app tienes que elegir la región que cubre esa banda (en Meshtastic, US cubre 902 a 928 MHz y ANZ cubre 915 a 928 MHz). Todos los nodos de un mismo mesh deben tener la misma región, así que si vas a sumarte a una red que ya existe, pregunta cuál usa la comunidad de tu zona. Este detalle cambia algo más adelante: el tema raíz de MQTT que trae el nodo por defecto lleva el nombre de la región. Donde los ejemplos dicen msh/EU_868, en tu caso va a decir algo como msh/US o msh/ANZ.

¿Y el DHT22?

Si pensabas reciclar un DHT22 que tienes en un cajón, aquí hay una trampa: el firmware de Meshtastic lee la telemetría ambiental solo de sensores I2C que reconoce en el arranque (BME280, BME680, BMP280, SHTC3, SHT31, AHT10, entre otros). El DHT22 usa un protocolo propio de un cable, Meshtastic no lo lee, y el nodo simplemente no va a reportar nada. Para un nodo propio con una placa ESP32 LoRa, el BME280 es la opción más directa: va al bus I2C (SDA, SCL, 3,3 V y GND), el firmware lo detecta solo y además entrega presión atmosférica, útil para anticipar cambios de tiempo.

El sensor va en el nodo remoto, no en el Pi

Parece obvio, pero vale la pena decirlo con números. En la prueba original, el RAK1901 montado en el HAT del Pi 5 marcaba entre 34 y 36 °C; el mismo sensor en la placa del Starter Kit, en la misma pieza, marcaba 23 °C. El calor del procesador contamina cualquier lectura que se haga a centímetros de él. Además, la gracia del proyecto es que el sensor esté donde quieres medir.

Con el nodo apagado, el sensor se inserta en un conector libre por la parte de abajo de la placa base y se atornilla (en el original quedó en el slot D).

Activar la telemetría en la app

El sensor no transmite nada hasta que lo habilitas. Conecta la app de Meshtastic al nodo sensor (no al Pi) y en Configuración → Telemetría activa dos interruptores:

• Métricas ambientales: envía temperatura y humedad.
• Métricas del dispositivo: envía nivel de batería y voltaje al mesh. Solo tiene sentido si el nodo funciona con batería; sin este interruptor, el nivel de batería lo ve únicamente la app conectada, no Home Assistant.

Un dato práctico: en la app de iOS el intervalo de las métricas ambientales no bajó de treinta minutos. Vas a tener dos lecturas por hora, que sobran para vigilar heladas o el clima de una bodega, pero no sirven para un control rápido. Para comprobar que el sensor quedó reconocido, entra al detalle del nodo y abre el registro de mediciones ambientales; en la lista general de nodos esos valores no aparecen.

¿Integración o MQTT? Cómo elegir

Los dos caminos parten del mismo montaje (sensor remoto más puente). Cambia cómo llegan los datos del Pi a Home Assistant y cuánto tienes que configurar.

La recomendación corta: si ya usas HACS, la integración llega más rápido y te entrega más datos, a cambio de depender de que alguien la siga manteniendo. MQTT conviene si no quieres integraciones extra o si los datos también los va a leer otro programa, como Node RED o una base de datos de series de tiempo. No son excluyentes: en la prueba original corrieron los dos a la vez y mostraron los mismos valores.

Camino 1: la integración de Meshtastic desde HACS

La integración conecta Home Assistant directo al nodo puente, sin broker, sin plantillas y sin tocar la configuración del nodo. Es el repositorio meshtastic/home-assistant del propio proyecto Meshtastic. Se probó la versión 0.6.1, el release vigente al momento de la prueba (abril de 2025), sobre Home Assistant 2026.9.4. Funcionó, pero dejó varias advertencias en el registro: usa funciones que Home Assistant elimina en las versiones 2027.7 y 2027.8, así que si el proyecto no se actualiza, es esperable que deje de andar entonces.

Instalarla

En el catálogo por defecto de HACS no aparece (buscar "Meshtastic" devuelve otro proyecto), así que se agrega como repositorio propio:

1. En HACS, menú de tres puntos → Repositorios personalizados. Escribe https://github.com/meshtastic/home-assistant y elige el tipo Integración.
2. Abre el repositorio "Meshtastic" en HACS y pulsa Descargar.
3. Reinicia Home Assistant.

Conectarla al Pi

Después del reinicio, en Configuración → Dispositivos y servicios → Agregar integración, busca "Meshtastic". Los diálogos están en inglés. Lo primero que pregunta es el tipo de conexión: TCP/IP, Bluetooth o Serial. Para un Pi con meshtasticd, es TCP/IP.

Como host va la IP del Pi; el puerto 4403 viene puesto. Es la misma interfaz que usa la línea de comandos de Meshtastic para hablar con el nodo.

Luego eliges qué nodos se convierten en dispositivos de Home Assistant. La lista trae todos los que conoce el Pi, pero se elige uno por vez: marcando Add another Node, la selección aparece de nuevo. Agrega primero el puente y después tu sensor.

En el diálogo siguiente se definen los destinos de notificación: uno por canal y, según lo que elijas, uno por nodo para mensajes directos. En un mesh grande, la opción All known and newly discovered Nodes genera decenas de entidades (el mismo diálogo lo advierte). Quédate con Only the selected Nodes.

Hay dos diálogos más, que ofrecen un cliente web integrado y un proxy TCP, ambos marcados como experimentales. Déjalos desactivados: según la descripción del proyecto, ese cliente web queda accesible sin login para cualquiera que llegue a la dirección de tu Home Assistant. Al final puedes nombrar los dispositivos y asignarlos a un área.

Lo que aparece solo

Recién configurada, la integración creó dos dispositivos con 37 entidades: 21 del puente (contadores de paquetes enviados y recibidos, número de nodos conocidos, etc.), 12 del Starter Kit y cuatro más, entre ellas los destinos de notificación.

Temperatura y humedad no están desde el principio: aparecen cuando llega el primer paquete de mediciones después de conectar, o sea, hasta treinta minutos con el intervalo de la app. Después, el nodo sensor muestra temperatura, humedad, relación señal/ruido, Battery Level, Voltage, Uptime, Channel Utilization, Airtime, Hops away y Last Heard.

Dos datos no calzaron con el hardware real. La integración nombra el modelo como "RAK WisMesh Repeater Mini V2 (RAK4631)", aunque es el Starter Kit (ambos usan el mismo módulo de radio). Y "Battery Level" marca 100 % sin batería conectada; el sensor confiable ahí es "Powered", que indica "Encendido". Si tu nodo va con batería, revisa ese valor contra el voltaje antes de armar alertas.

Enviar mensajes al mesh

Cada nodo y canal seleccionado tiene una entidad de tipo notificación. Un mensaje directo al nodo sensor es una acción común y corriente, que puedes lanzar desde Herramientas para desarrolladores o desde una automatización:

action: notify.send_message
target:
  entity_id: notify.mesh_node_meshtastic_d5d4
data:
  message: Hallo per HACS-Integration

La entidad sigue el patrón notify.mesh_node_ más el nombre del nodo, y el texto de message lo cambias por el que quieras. En la prueba original el mensaje llegó al Starter Kit y dos segundos después el registro del Pi mostró el acuse de recibo.

Recibir mensajes del mesh en el celular

Por cada mensaje de texto recibido, la integración dispara el evento meshtastic_api_text_message. Una automatización lo convierte en notificación de la app de Home Assistant. En Configuración → Automatizaciones y escenas, crea una nueva, pasa a Editar en YAML desde el menú de tres puntos y pega:

alias: Meshtastic-Nachricht aufs Handy
description: Textnachrichten aus dem Mesh als Mitteilung weiterreichen
triggers:
  - trigger: event
    event_type: meshtastic_api_text_message
actions:
  - action: notify.mobile_app_dein_handy
    data:
      title: Meshtastic
      message: "{{ trigger.event.data.data.message }}"
mode: queued

Lo único que tienes que cambiar es el nombre de tu acción de notificación (notify.mobile_app_...). Avisa tanto de mensajes directos al puente como de mensajes en el canal. El evento trae además remitente, destinatario y canal, por si quieres filtrar.

Una sola conexión a la vez. El nodo Meshtastic acepta una única conexión TCP de este tipo. Mientras Home Assistant esté conectado, cualquier otro acceso por el mismo puerto (por ejemplo meshtastic --host localhost en el propio Pi) lo saca de la línea. Si administras el nodo por consola, piensa en eso antes de culpar a la integración.

Camino 2: Meshtastic por MQTT

Aquí hay más pasos, pero no dependes de ningún proyecto externo, y todos los paquetes quedan en el broker para cualquier programa que los quiera leer.

Un detalle de compatibilidad: según la documentación de Meshtastic, los nodos con chip nRF52 (como el Starter Kit) no pueden publicar en formato JSON. Eso solo importa para el nodo conectado al broker; el Pi con meshtasticd entregó JSON sin problema, incluidos los paquetes del Starter Kit. Si tu puente fuera una placa ESP32 LoRa, también entrega JSON.

Broker propio, no el servidor público

Si no le indicas un servidor, el módulo MQTT se conecta al broker público del proyecto Meshtastic. Para Home Assistant no sirve: tus mediciones quedarían sin cifrar en un servidor ajeno y el puente dependería de internet. Por eso se configura el broker de tu red local.

Ojo con lo siguiente: la documentación desaconseja usar el canal por defecto con un broker privado. El servidor público evita que los paquetes que vienen de internet se retransmitan por radio; un broker privado no hace ese filtro, y los nodos que aceptan paquetes del broker podrían inundar el canal público. Eso afecta solo a la dirección broker → mesh, el downlink. Para las mediciones basta el uplink (mesh → broker), así que en el canal por defecto el downlink se queda apagado.

Paso 1: un usuario para el nodo en Home Assistant

El broker Mosquitto de Home Assistant acepta los usuarios creados en Home Assistant. Dale uno propio al nodo: en Configuración → Personas, agrega una persona, activa Permitir inicio de sesión, define usuario y contraseña y activa Solo acceso local. No necesita permisos de administrador. Usa una contraseña que no ocupes en ningún otro lado (más abajo verás por qué).

Paso 2: activar MQTT en el nodo puente

Abre el cliente web del Pi en https://IP-DEL-PI:9443 y ve a Configuración → Configuración de módulos → MQTT:

Cifrado y TLS van apagados para que Home Assistant pueda leer los paquetes. El campo del tema raíz no puede quedar vacío o el cliente web no guarda; deja el valor que viene, porque es el inicio de todos los temas en que publica el nodo. Al guardar, el nodo se reinicia. Si el aviso de "cambios sin guardar" sigue ahí, recarga la página: los valores sí quedaron.

Paso 3: uplink en el canal principal y reinicio

Qué canales se reenvían al broker se define canal por canal. En Configuración → Channel Config → Primario, activa Uplink, deja Downlink apagado y guarda.

Ahora reinicia el nodo a mano. Sin este reinicio el nodo de la prueba no se conectó al broker; lo más probable es que el módulo MQTT revise solo al arrancar si algún canal tiene uplink o downlink. El reinicio está en el menú de comandos de la barra lateral, sección "Contextual", como "Reiniciar dispositivo"; por consola es sudo systemctl restart meshtasticd.

Para confirmar que se conectó, revisa el registro del servicio por SSH en el Pi. Si aparece una línea con "MQTT connected", listo; si no sale nada, ve a la sección de problemas más abajo.

journalctl -u meshtasticd -b --no-pager | grep "MQTT connected"

Lo que queda expuesto. Sin cifrado y con JSON, todos los paquetes quedan legibles en el broker: quien tenga acceso al broker lee todo. Eso incluye los mensajes directos al puente, que por radio sí van cifrados; en la prueba original su texto apareció en claro bajo un tema propio. Además, meshtasticd escribe el usuario y la contraseña del broker en texto plano en su registro al conectarse. Nunca compartas salidas de journalctl sin revisarlas, y usa para el nodo una contraseña exclusiva.

Paso 4: ver qué llega con MQTT Explorer

Conecta MQTT Explorer al broker (IP de Home Assistant, puerto 1883, usuario del paso 1) y déjalo abierto. El broker no guarda los paquetes de Meshtastic, así que la rama msh aparece recién cuando llega un paquete después de conectar. Con un sensor cada media hora puede tardar; un mensaje de texto desde el nodo sensor al canal por defecto genera un paquete al tiro.

Bajo msh/EU_868/2 hay dos ramas: e con los datos crudos y json con la versión legible. El tema completo en la prueba fue msh/EU_868/2/json/LongFast/!9eabc180: LongFast es el nombre del canal por defecto y !9eabc180 el identificador del puente (no del sensor). Un paquete de mediciones se ve así:

{
  "channel": 0,
  "from": 523294164,
  "payload": {
    "relative_humidity": 56.7,
    "temperature": 23
  },
  "rssi": -27,
  "sender": "!9eabc180",
  "snr": 7.25,
  "to": 4294967295,
  "type": "telemetry"
}

Anota tres cosas: el tema, el número que aparece en from y el número del puente. from identifica al nodo que midió (aquí, el Starter Kit). sender nombra al puente, pero como identificador hexadecimal. Su número es ese mismo identificador sin el signo de exclamación, pasado de hexadecimal a decimal: !9eabc180 es 2662056320. Lo puedes convertir con la calculadora en modo programador o en el Pi con:

printf "%d\n" 0x9eabc180

Si te preguntas por qué to vale 4294967295: es 0xFFFFFFFF, la dirección de difusión de Meshtastic, o sea "para todos los nodos". Como todos los paquetes de todos los nodos pasan por el mismo tema, el campo from es lo que le permite a Home Assistant distinguir de quién es cada dato. Batería y voltaje llegan en un paquete aparte, menos frecuente, con los campos battery_level y voltage.

Paso 5: crear el sensor como dispositivo MQTT

Los dispositivos MQTT se crean desde la interfaz; no hace falta tocar configuration.yaml. El dispositivo es el nodo sensor completo, y cada entidad es una medición: vas a crear un dispositivo con dos entidades, no dos dispositivos.

1. En Configuración → Dispositivos y servicios → MQTT, pulsa Agregar dispositivo MQTT y ponle nombre, por ejemplo "Meshtastic Invernadero". Elígelo con cuidado: en la prueba original no se pudo cambiar después desde este diálogo. El resto de los campos puede quedar vacío.
2. Como tipo de entidad elige Sensor y como nombre la medición, "Temperatura". Home Assistant antepone solo el nombre del dispositivo.
3. Clase de dispositivo, clase de estado Medición y unidad según la tabla de abajo.
4. Como tema de estado, el de tu paso 4, y la plantilla de valor que corresponda.
5. Para la humedad, en la integración MQTT pulsa el engranaje junto al dispositivo, elige Agregar otra entidad a… y repite los puntos 2 a 4. Cierra con Guardar cambios en ese mismo menú.

Plantilla para la temperatura:

{% if value_json.from == 523294164 and value_json.payload.temperature is defined %}{{ value_json.payload.temperature | float | round(1) }}{% endif %}

Para la humedad:

{% if value_json.from == 523294164 and value_json.payload.relative_humidity is defined %}{{ value_json.payload.relative_humidity | float | round(1) }}{% endif %}

Si tu nodo va con batería, agrega una tercera entidad (clase Batería, unidad %):

{% if value_json.from == 523294164 and value_json.payload.battery_level is defined %}{{ [value_json.payload.battery_level | int, 100] | min }}{% endif %}

En todas, reemplaza 523294164 por el número from de tu nodo sensor. La plantilla revisa primero si el paquete es de ese nodo y si trae el valor buscado; con cualquier otro paquete no devuelve nada y la entidad conserva su último valor. Ese filtro es lo que evita que la temperatura salte a cero cada vez que llega un mensaje de texto o el paquete de otro nodo. La de batería se limita a 100 porque el Starter Kit, alimentado por USB-C y sin batería, reporta 101 %; en la prueba los datos del dispositivo llegaron cada dos horas, menos seguido que los ambientales.

Las entidades nuevas aparecen como "Desconocido" hasta el próximo paquete del sensor, o sea, hasta media hora. Reiniciar el nodo sensor no lo acelera: solo manda información del nodo, no mediciones. Lo mismo pasa cada vez que editas o borras un dispositivo MQTT: Home Assistant recarga la integración y, como el broker no guarda los paquetes, todas las entidades de Meshtastic vuelven a "Desconocido" hasta el siguiente.

Mensajes del mesh al celular

Los mensajes de texto viajan por el mismo camino que las mediciones y llevan "type": "text". Crea una automatización nueva en YAML con este bloque:

alias: Meshtastic-Nachricht aufs Handy
description: Textnachrichten aus dem Mesh als Mitteilung weiterreichen
triggers:
  - trigger: mqtt
    topic: msh/EU_868/2/json/+/!9eabc180
    value_template: "{{ value_json.type }}"
    payload: text
conditions:
  - condition: template
    value_template: "{{ trigger.payload_json['from'] != 2662056320 }}"
actions:
  - action: notify.mobile_app_dein_handy
    data:
      title: Meshtastic
      message: "{{ trigger.payload_json.payload.text }}"
mode: queued

Cambia tres cosas: el identificador de tu puente en el tema (y la región, si no es EU_868), su número decimal en la condición y el nombre de tu acción de notificación. El + del tema acepta cualquier nombre de canal: los mensajes del canal llegan bajo LongFast y los directos al puente bajo PKI. La condición descarta los textos que envió el propio puente; sin ella, cada mensaje que mandes desde Home Assistant te volvería como notificación.

Mensajes de Home Assistant al mesh

Para el camino de vuelta, Meshtastic reserva un canal que tiene que llamarse exactamente mqtt. Créalo en el cliente web, en Configuración → Channel Config, en la siguiente pestaña libre: nombre mqtt en minúsculas, Downlink activado y Uplink apagado. El canal por defecto no se toca y su downlink sigue apagado. El rol del canal se deja como venga (en la prueba quedó en "DESACTIVADO" y funcionó). Reinicia el nodo otra vez.

Las mayúsculas importan: el nombre del canal pasa tal cual al tema. Si lo llamas MQTT, el nodo escucha en msh/EU_868/2/json/MQTT/ y el ejemplo no hace nada. Para probar, abre Herramientas para desarrolladores → Acciones, pasa a modo YAML y pega:

action: mqtt.publish
data:
  topic: msh/EU_868/2/json/mqtt/!9eabc180
  payload: '{"from": 2662056320, "to": 523294164, "type": "sendtext", "payload": "Hallo aus Home Assistant"}'

El canal mqtt es solo la entrada de estas órdenes de envío: el puente toma la orden del broker y transmite el texto por radio. from es el número del puente y to el del destinatario; con to sale como mensaje directo, y si lo omites el puente lo manda al canal por defecto, donde lo lee cualquier nodo al alcance. La documentación recomienda no pasar de 190 caracteres.

Esa misma acción la puedes meter en cualquier automatización: un aviso al mesh cuando se corta la luz en la casa, cuando salta una alarma o, en el caso del invernadero, cuando el pronóstico anuncia helada y quieres que lo lea quien está en el campo con su nodo en el bolsillo.

Si algo no funciona

Dos preguntas que salen siempre. ¿El nodo sensor necesita wifi o internet? No: solo transmite por LoRa. Red y MQTT los necesita únicamente el puente. ¿Otros pueden leer mis mediciones? Por radio sí, si el sensor transmite en el canal por defecto, porque su clave es pública y cualquier nodo Meshtastic al alcance la conoce. Si no quieres eso, crea un canal secundario con clave propia en ambos nodos y activa el uplink en ese canal en lugar del primario.

Variantes y mejoras

• Un nodo propio con ESP32 LoRa y BME280 para el invernadero. En lugar del Starter Kit, una placa ESP32 con radio SX1262 de 915 MHz (tipo Heltec WiFi LoRa 32 V3) con el firmware Meshtastic flasheado desde el navegador y un BME280 en los pines I2C hace el mismo trabajo. Alimentada con una batería 18650 y un panel solar pequeño, puede quedar sola en el invernadero toda la temporada; en ese caso activa las métricas del dispositivo para vigilar la batería desde Home Assistant.
• Alerta de helada en el celular. Con la temperatura ya como entidad, una automatización que avise cuando baje de 2 °C entre las 3 y las 8 de la mañana te da tiempo para encender un calefactor o cubrir las plantas. Combínala con la acción mqtt.publish del camino 2 y el aviso llega también al mesh, para quien no tiene datos en el campo.
• Historial largo en InfluxDB o Grafana. Como en el camino MQTT todo queda en el broker, Node RED o Telegraf pueden suscribirse a msh/+/2/json/# y guardar cada paquete de todos los nodos, con RSSI y SNR incluidos. Así puedes ver cómo cambia la cobertura del mesh a lo largo del día, no solo la temperatura.
• Puente sin Raspberry Pi. Según la documentación de Meshtastic, cualquier nodo con wifi o Ethernet puede usar el módulo MQTT, y todas las plataformas menos nRF52 publican en JSON. Una placa ESP32 LoRa conectada a tu wifi podría reemplazar al Pi como puente para el camino MQTT (el original solo lo probó con el Pi).

Personalización para Chile

En Chile consigues buena parte de este montaje en MechatronicStore. Busca en el catálogo:

• Raspberry Pi 5: el nodo puente que corre meshtasticd y queda conectado a tu red.
• Fuente USB-C de 27 W para Raspberry Pi 5: la oficial evita los avisos de bajo voltaje cuando el HAT LoRa está transmitiendo.
• Tarjeta microSD de 32 GB o más para el sistema del Pi.
• Placa ESP32 LoRa con SX1262 de 915 MHz: para armar tu propio nodo sensor (o un puente sin Pi), en lugar del RAK4631 Starter Kit del original.
• Sensor BME280 I2C: temperatura, humedad y presión, leído directamente por el firmware de Meshtastic. Reemplaza al RAK1901; evita el DHT22, que Meshtastic no lee.
• Batería 18650 con su portapilas si el nodo sensor va a quedar lejos de un enchufe.

Si en el tutorial original usan el WisMesh Pi HAT con el RAK13300, cualquier HAT LoRa con chip SX1262 compatible con meshtasticd cumple la misma función; revisa que sea de la banda de 915 MHz y que su pinout esté entre los soportados por el archivo de configuración de meshtasticd.

Recursos

• Tutorial original (alemán): Meshtastic in Home Assistant einbinden: per MQTT oder HACS, de Philipp Schweizer en raspberry.tips. Esta versión está basada en él.
• Repositorio GitHub de la integración: meshtastic/home assistant
• Documentación del módulo MQTT de Meshtastic: meshtastic.org/docs/configuration/module/mqtt
• Sensores de telemetría compatibles: meshtastic.org/docs/configuration/module/telemetry
• MQTT Explorer: mqtt explorer.com

Versión chilena con componentes en stock local en MechatronicStore.