Continuamos donde lo dejamos

En el último post me quedé con las dudas que más suelen aparecer cuando empiezas con Meshtastic: RSSI, SNR, Bluetooth, WiFi y esa idea tan tentadora de pensar que la malla puede comportarse como un internet pequeño y mágico.

Hoy toca una continuación natural, y para mí bastante importante: los modos de nodo.

Porque aquí es donde mucha gente se confunde al principio. Ves un desplegable lleno de nombres, lees “router”, “tracker”, “sensor”, “client”, y es fácil pensar que todo es más o menos lo mismo. Pero no. En Meshtastic, el modo que eliges cambia bastante más de lo que parece:

  • cuánto habla tu nodo.
  • cuánto rebota mensajes de otros.
  • si prioriza batería o cobertura.
  • si aparece en la red como infraestructura visible.
  • si está pensado para movilidad, telemetría o para dar servicio a otros nodos.

En otras palabras: el modo no es una etiqueta bonita. Es una declaración de intenciones.

Antes de seguir: modo, rol y rebroadcast no son exactamente lo mismo

Aquí conviene hacer una pausa porque Meshtastic mezcla varios conceptos que, en la práctica, acaban relacionados, pero no son idénticos.

Yo lo simplifico así:

  • El rol o modo dice qué tipo de nodo eres.
  • El rebroadcast dice qué haces con lo que escuchas.
  • La configuración de energía dice cuánto tiempo vas a estar despierto y cuánto quieres gastar.

Puedes pensar en ello como si el modo fuera tu profesión, el rebroadcast tu forma de repartir el trabajo y la energía tu horario laboral.

Por ejemplo:

  • un nodo de mochila con GPS no debería comportarse como una torre fija en una azotea.
  • un nodo de interior no debería actuar como si fuese el centro logístico de la comarca.
  • un nodo que solo quieres usar para hablar tú no debería reenviar todo por defecto si no aporta nada a la malla.

Por eso elegir bien el modo importa tanto.

La idea general: no todos los nodos tienen que ayudar igual

Este es probablemente el concepto que más me ha ayudado a entender Meshtastic.

En una red tradicional, casi todo el mundo asume que el equipo de red debe estar siempre encendido, siempre reenviando y siempre disponible. Pero Meshtastic no va exactamente por ahí. Aquí hay nodos que están para hablar, otros para observar, otros para dar cobertura, otros para reportar posición y otros para integrarse con sistemas externos.

Si lo piensas bien, tiene sentido:

  • Un nodo personal en la mochila no necesita ser una torre de telecomunicaciones.
  • Un nodo fijo en alto sí puede ser una pieza importante de cobertura.
  • Un sensor de temperatura no necesita gastar batería hablando de más.
  • Un nodo de rastreo necesita priorizar posición, no conversaciones triviales.

La clave está en no pedirle a cada nodo que haga el trabajo equivocado.

Los modos que existen

Voy a pasar por los principales modos que aparecen hoy en la configuración de Meshtastic, explicando para qué sirven, qué implican y en qué casos los veo útiles.

CLIENT

Este es el modo que yo considero más “normal” para empezar.

Sirve para un nodo de uso general: hablar por la malla, recibir mensajes, participar de forma activa y, además, retransmitir paquetes cuando toca y cuando nadie más lo ha hecho ya.

Ideal para:

  • uso general de una persona.
  • nodos de prueba que todavía no sabes si serán infraestructura.
  • equipos que quieren participar de forma completa sin complicarse demasiado.

Qué implica:

  • el nodo escucha y transmite de forma habitual.
  • aporta a la red, no solo consume.
  • es un equilibrio razonable entre utilidad y ruido.

Mi recomendación práctica:

Si no tienes muy claro por dónde empezar, CLIENT es una base sensata. No es el modo más discreto, pero tampoco es una mala elección por defecto si quieres un nodo que realmente participe.

CLIENT_MUTE

Este es el modo que más sentido me parece que tiene para muchísima gente.

Es un nodo que sigue siendo parte de la red, pero no reenvía paquetes de otros dispositivos. Es decir: habla, recibe y funciona, pero no intenta actuar como repetidor para el resto.

Ideal para:

  • nodos personales de uso diario.
  • nodos en interior.
  • nodos móviles.
  • gente que quiere minimizar tráfico en la malla.

Qué implica:

  • menos carga para la red.
  • menos ruido de retransmisión.
  • menos riesgo de convertir un nodo poco optimizado en un cuello de botella tonto.

Mi recomendación práctica:

Si tu nodo está en una ventana, dentro de casa o en una posición normalita, CLIENT_MUTE suele ser una elección muy razonable. Aporta presencia en la red sin pretender hacerse importante de más.

CLIENT_HIDDEN

Este modo existe para casos más discretos o para ahorrar energía y airtime.

La idea es que el nodo participe, pero con un comportamiento más contenido. No es un modo para presumir de cobertura ni para estar mandando mensajes todo el tiempo.

Ideal para:

  • despliegues donde interesa discreción.
  • escenarios donde quieres reducir consumo al máximo.
  • nodos que no necesitan ser especialmente visibles.

Qué implica:

  • menos actividad visible en la red.
  • menos consumo potencial.
  • menos presencia de la que tendría un cliente normal.

Mi recomendación práctica:

Yo no lo usaría como modo principal sin tener claro por qué. Tiene sentido si sabes exactamente qué quieres ahorrar o esconder, pero para aprender suele ser más fácil empezar por CLIENT o CLIENT_MUTE.

CLIENT_BASE

Este modo me parece muy interesante porque ya empieza a oler a “infraestructura con criterio”.

Un CLIENT_BASE es un nodo personal, pero pensado para dar más cobertura a un conjunto de nodos favoritos. Según la documentación, prioriza paquetes hacia o desde esos nodos favoritos y, en la práctica, se usa mucho como base mejor situada: tejado, azotea, ventana alta, punto despejado, etc.

Ideal para:

  • una base fija en una casa o edificio.
  • un nodo bien colocado que ayuda a otros nodos más débiles.
  • escenarios donde quieres dar apoyo a tus propios nodos, no necesariamente a toda la malla indiscriminadamente.

Qué implica:

  • empieza a comportarse como una pieza de cobertura seria.
  • requiere pensar bien qué nodos se marcan como favoritos.
  • ya no es solo un nodo personal, sino una pieza con cierto peso operativo.

Mi recomendación práctica:

Si tienes un nodo fijo en un sitio mucho mejor que el resto, CLIENT_BASE puede ser muy útil. No es el mismo papel que un router puro, y eso me gusta: te deja ayudar sin convertirte automáticamente en infraestructura pública.

TRACKER

TRACKER está pensado para nodos cuya prioridad es la posición GPS.

La idea es simple: si quieres saber dónde está algo o alguien, este modo pone el foco en emitir datos de localización de forma prioritaria.

Ideal para:

  • personas en movimiento.
  • vehículos.
  • mochilas.
  • activos que quieras localizar.

Qué implica:

  • la posición pasa a ser el dato central.
  • suele tener un comportamiento de energía distinto y más orientado a ciclos de reposo.
  • no está pensado para ser un nodo parlanchín que rebote de todo.

Mi recomendación práctica:

Si el nodo se mueve y tiene GPS, TRACKER tiene todo el sentido del mundo. Es más honesto que forzar a un nodo de rastreo a comportarse como si fuera una base fija.

SENSOR

SENSOR es el equivalente a TRACKER, pero enfocado a telemetría.

En vez de priorizar la ubicación, prioriza los datos de entorno: temperatura, humedad, presión, batería o cualquier otra información de sensor que quieras mandar.

Ideal para:

  • estaciones meteorológicas.
  • sensores remotos.
  • nodos que informan de un estado concreto.

Qué implica:

  • el nodo se organiza alrededor de mandar telemetría.
  • el ahorro de batería importa mucho.
  • no tiene sentido cargarlo con tráfico que no aporte a su función.

Mi recomendación práctica:

Si el nodo es una sonda, un sensor o una estación, SENSOR es casi el modo natural. No estás montando un mensajero; estás montando un observador.

LOST_AND_FOUND

Este modo está pensado para la recuperación de dispositivos perdidos.

Su comportamiento gira en torno a emitir la ubicación del dispositivo de forma regular para facilitar que alguien lo encuentre.

Ideal para:

  • nodos que puedes perder físicamente.
  • dispositivos de campo que puedan extraviarse.
  • etiquetas o equipos que quieras localizar rápido.

Qué implica:

  • bastante foco en localización.
  • menos interés por la conversación general.
  • uso muy concreto, casi de emergencia.

Mi recomendación práctica:

No es un modo de uso diario para cualquiera. Tiene sentido cuando la prioridad es recuperar el aparato, no operar la malla de forma general.

TAK

Este modo está orientado a la integración con ATAK mediante el plugin de Meshtastic. No me extiendo mucho en hablar de ATAK pese a que me apasione ya que hemos hablado en posts anteriores de él.

Aquí la idea no es solo “hablar por radio”, sino hacerlo de una forma que encaje bien con un entorno táctico o coordinado.

Ideal para:

  • equipos que usan ATAK.
  • escenarios operativos con información compartida.
  • coordinación donde interesa compatibilidad y disciplina de mensajes.

Qué implica:

  • reduce broadcasts rutinarios que no aportan tanto al escenario.
  • prioriza la compatibilidad con el flujo de trabajo ATAK.
  • no es el modo para curiosear sin más si no vas a usar ese ecosistema.

Mi recomendación práctica:

Si no usas ATAK, no le sacarás el jugo. Si sí lo usas, entonces el modo TAK tiene mucho sentido porque evita mezclar usos distintos en una misma configuración.

TAK_TRACKER

Es la variante de tracker orientada a ATAK.

La diferencia frente a TRACKER es que aquí el nodo está pensado para integrarse directamente en ese flujo, automatizando los datos de posición que necesita el sistema.

Ideal para:

  • nodos con ATAK y posición automática.
  • despliegues donde el PLI importa de verdad.
  • dispositivos que deben reportar presencia de forma más estructurada.

Qué implica:

  • foco en la ubicación dentro del ecosistema ATAK.
  • menos flexibilidad “generalista”.
  • comportamiento más especializado.

Mi recomendación práctica:

Si un tracker normal ya te parecía específico, este lo es todavía más. Y precisamente por eso está bien: no todo nodo tiene que servir para todo.

ROUTER

Aquí entramos en territorio serio.

ROUTER es un nodo de infraestructura. Su objetivo es extender cobertura y retransmitir paquetes para ayudar a que la malla crezca o salve huecos de cobertura.

Ideal para:

  • puntos altos bien elegidos.
  • nodos fijos de infraestructura.
  • tejados, azoteas o ubicaciones estratégicas.

Qué implica:

  • más responsabilidad para la red.
  • más presencia como nodo visible.
  • más impacto si está mal colocado.
  • en ESP32, el ahorro de energía se activa por defecto y no se puede desactivar como si nada.

Mi recomendación práctica:

ROUTER no es un modo para poner por poner. Si lo usas mal, puedes generar ruido, rutas peores o incluso una sensación falsa de que “estoy ayudando” cuando en realidad solo estás metiendo tráfico. Si lo usas bien, puede ser una pieza clave.

ROUTER_LATE

Este es interesante porque intenta ayudar, pero lo hace con un poco más de paciencia.

La diferencia fundamental es que retransmite también, pero después de otros modos. Eso lo hace muy útil para dar cobertura extra sin imponerse demasiado en la red.

Ideal para:

  • cubrir huecos locales.
  • reforzar una zona concreta.
  • aportar a la malla sin desplazar al resto de nodos por pura prioridad.

Qué implica:

  • sigue siendo infraestructura.
  • pero con una filosofía más suave.
  • puede ser una opción más equilibrada en ciertos entornos.

Mi recomendación práctica:

Si ROUTER te suena demasiado agresivo para tu caso, ROUTER_LATE es una alternativa muy interesante. No elimina la responsabilidad, pero la reparte mejor.

Comparativa rápida

Si tuviera que resumirlo en una tabla mental, quedaría algo así:

Modo Para qué es ideal Qué aporta Qué implica Cuándo no lo usaría
CLIENT Uso general Participa en la malla de forma equilibrada Retransmite cuando conviene Si quieres el mínimo ruido posible
CLIENT_MUTE Nodo personal discreto Comunica sin ayudar a retransmitir Menos carga para la red Si necesitas que el nodo haga de apoyo
CLIENT_HIDDEN Despliegues discretos o ahorro Reduce presencia y actividad Menos visibilidad y menos chatter Si aún estás aprendiendo
CLIENT_BASE Base fija para nodos propios Mejora cobertura de tus favoritos Ya pesa más como infraestructura Si no tienes una posición clara y estable
TRACKER GPS y movilidad Posición prioritaria Piensa en ciclos de energía Si el nodo no se mueve
SENSOR Telemetría Datos de entorno claros Poco interés en conversar más de la cuenta Si el nodo va a hacer de mensajero general
LOST_AND_FOUND Recuperación Facilita encontrar el equipo Uso muy específico Si buscas un nodo de uso diario
TAK Integración con ATAK Encaja con flujo táctico Menos orientado al uso genérico Si no usas ATAK
TAK_TRACKER ATAK con posición Automatiza localización en ATAK Muy especializado Si solo quieres probar Meshtastic básico
ROUTER Infraestructura fuerte Extiende cobertura Más responsabilidad y más impacto Si tu nodo está en mala posición
ROUTER_LATE Infraestructura más equilibrada Ayuda sin imponerse tanto Sigue siendo rol de red serio Si no quieres que el nodo afecte a la topología

Con esta tabla no pretendo darte una verdad absoluta, porque tampoco soy un experto, pero sí una orientación bastante útil para no elegir a ciegas compartiendo lo que he aprendido yo.

Lo que implican de verdad estos modos

Cuando empiezas, es fácil quedarse solo con el nombre. Pero los efectos reales van mucho más allá.

1) Afectan al consumo de batería

No es lo mismo un nodo que duerme gran parte del tiempo que uno que está siempre disponible para recibir y retransmitir.

Si eliges un modo de rastreo o de sensores, el sistema suele priorizar ciclos de trabajo muy concretos.

Si eliges un modo de infraestructura, la idea pasa a ser otra: estar disponible cuando haga falta.

2) Afectan a la cantidad de tráfico en la malla

Esto es importante de verdad.

Un nodo que retransmite mucho puede ayudar, pero también puede contribuir a congestionar una red ya cargada si está mal colocado o si no lo necesita nadie.

Por eso muchas veces un nodo personal que no retransmite nada puede ser más sano que otro que intenta ser importante a toda costa.

3) Afectan a la visibilidad del nodo

Hay modos que quieren ser visibles como infraestructura y otros que prefieren pasar más desapercibidos.

Eso no es solo una decisión estética. También cambia cómo interpretas la topología, cómo aparece tu nodo en los listados y qué papel juega dentro de la red.

4) Afectan al tipo de mensaje que mandas

Un tracker no necesita comportarse como un chat.

Un sensor no necesita reportar más de lo que aporta.

Un router no debería estar pensado para lucirse, sino para sostener la malla.

La especialización no es una complicación innecesaria. Es justo lo que evita que cada nodo haga el trabajo mal.

Ejemplos concretos

Esto suele aclararlo todo mucho mejor que cualquier definición larga.

Ejemplo 1: nodo personal en mochila

Llevas un Heltec con batería, sales a caminar, quieres poder escribir mensajes y ver la malla sin pensar demasiado.

Modo recomendado: CLIENT_MUTE o CLIENT.

Por qué:

  • no necesitas que sea infraestructura.
  • probablemente no está en la mejor posición del mundo.
  • quieres gastar batería con cabeza.

Ejemplo 2: nodo fijo en una ventana alta

Tienes un nodo en casa, bien colocado, con antena decente, y quieres que ayude a otros nodos cercanos.

Modo recomendado: CLIENT_BASE o CLIENT.

Por qué:

  • puede dar servicio real.
  • tiene una posición mejor que la media.
  • tiene sentido que ayude a nodos cercanos o favoritos.

Ejemplo 3: nodo en una azotea o colina

Tienes un punto estratégico, alta visibilidad y una ubicación que puede cubrir un hueco en la malla.

Modo recomendado: ROUTER o ROUTER_LATE.

Por qué:

  • ahí sí tiene sentido pensar en cobertura general.
  • el nodo aporta más como infraestructura que como terminal personal.

Ejemplo 4: equipo de campo con GPS

Un dispositivo va a moverse y quieres saber dónde está.

Modo recomendado: TRACKER.

Por qué:

  • la prioridad es la localización.
  • no quieres gastar energía mandando cosas que no son posición.

Ejemplo 5: estación meteorológica improvisada

Pones sensores de temperatura, humedad o presión en un punto remoto.

Modo recomendado: SENSOR.

Por qué:

  • la telemetría es el objetivo.
  • el comportamiento de energía y transmisiones encaja mejor con eso.

Ejemplo 6: red con ATAK

Montas un escenario coordinado donde ATAK es parte del flujo.

Modo recomendado: TAK o TAK_TRACKER.

Por qué:

  • el modo ya está pensado para ese ecosistema.
  • reduces configuración innecesaria.
  • todo encaja mejor desde el principio.

Ejemplo 7: nodo que puedes perder o dejar en un equipo

Quieres que, si desaparece, sea fácil de localizar.

Modo recomendado: LOST_AND_FOUND.

Por qué:

  • la finalidad no es dialogar, sino recuperar.
  • el comportamiento está alineado con esa tarea.

La función de favoritos

Hay un detalle que muchas veces se pasa por alto al empezar con Meshtastic, y que encaja muy bien con todo lo que hemos visto arriba: la posibilidad de marcar nodos como favoritos.

Esto no es un adorno de la interfaz ni una lista bonita para tener los nombres ordenados. Tiene un efecto práctico muy claro, sobre todo cuando trabajas con un nodo tipo CLIENT_BASE.

La idea es sencilla:

  • tú eliges qué nodos consideras importantes para tu red.
  • el nodo base da más prioridad a esos nodos favoritos.
  • si tienes una instalación mejor situada, esa base ayuda especialmente a los equipos que más te interesa proteger o reforzar.

Para qué sirve de verdad

La utilidad real está en que no todo nodo tiene el mismo valor para ti.

Por ejemplo:

  • puedes tener un nodo en casa que use tu equipo principal.
  • puedes tener otro nodo de pruebas que solo te interesa de forma secundaria.
  • puedes tener un nodo móvil que entra y sale de la cobertura con frecuencia.

Si marcas como favoritos los nodos que de verdad quieres priorizar, el comportamiento del base se vuelve mucho más útil y más coherente con tu red real.

Cuándo tiene sentido usarlo

Yo lo veo especialmente útil en estos casos:

  • cuando tienes un nodo fijo bien colocado y varios nodos personales más flojos.
  • cuando quieres que una base apoye primero a tu equipo principal.
  • cuando no quieres convertir un nodo en router total, pero sí darle un papel más inteligente.

Qué implica

La parte importante es esta: favoritos no significa magia.

No convierte un nodo malo en uno bueno, ni arregla una mala antena, ni sustituye una mala ubicación. Lo que hace es priorizar mejor el tráfico hacia o desde los nodos que tú has decidido cuidar.

Por eso, como casi todo en Meshtastic, la función de favoritos funciona bien cuando la acompañas de criterio:

  • nodo bien colocado.
  • antena decente.
  • pocos favoritos, pero bien elegidos.
  • una idea clara de qué quieres optimizar.

Si usas CLIENT_BASE, marca como favoritos solo los nodos que de verdad forman parte de tu uso real. No hace falta poner toda la lista por sistema. Cuantos más favoritos metas sin sentido, más diluyes precisamente la ventaja de tenerlos.

En resumen: los favoritos son la forma de decirle a Meshtastic qué nodos importan más para tu escenario concreto. Y eso, en una red pequeña o media, puede marcar bastante la diferencia.

Mi regla práctica para elegir sin volverme loco

Si me obligaran a resumir todo el post en una receta corta, yo me quedaría con esto:

  • Si es tu nodo de uso diario y no quieres complicarte: CLIENT_MUTE
  • Si quieres participar de forma normal: CLIENT
  • Si el nodo da cobertura y está bien colocado: CLIENT_BASE, ROUTER o ROUTER_LATE
  • Si tiene GPS y se mueve: TRACKER
  • Si mide entorno: SENSOR
  • Si usa ATAK: TAK o TAK_TRACKER
  • Si es para recuperar algo perdido: LOST_AND_FOUND

Y una norma que a mí me parece importante:

no conviertas un nodo normal en ROUTER por inercia.

Ese salto solo tiene sentido si de verdad está bien situado, si entiendes el impacto y si aceptas que ya estás jugando otro partido. Y no olvides que estás en una comunidad, habla con tus vecinos al respecto de la decisión de poner un nuevo ROUTER.

Lo que yo me llevaría como idea principal

Meshtastic funciona mejor cuando cada nodo hace el papel que realmente le toca.

No hace falta que todos sean heroicos. No hace falta que todos retransmitan. No hace falta que todos sean visibles.

De hecho, una red sana suele ser justo lo contrario: una mezcla de nodos con funciones distintas, cada uno aportando lo suyo sin estorbar.

Y eso me parece una de las cosas más interesantes de Meshtastic. No te obliga a pensar en la red como una pieza plana y aburrida. Te obliga a pensar en topología, posición, energía y propósito.

Que, dicho de otra forma, significa que aunque es radio deja de ser PTT(Press-To-Talk) y pasa a ser ingeniería pura.

Cierre

Este post, como todos los demás, me sirve como guía para no perderme entre nombres parecidos y para recordar que el modo correcto depende mucho más del contexto que del capricho.

En el siguiente paso seguramente me meta con configuraciones más finas, o con algún caso práctico de campo donde ya se ve de verdad la diferencia entre teoría y uso real.

Y ahí es donde la cosa se pone divertida de verdad.

¡Nos vemos en el próximo log!