Espeasy: MQTT deja de funcionar desde 20181008

En 20181004 ha cambiado lo siguiente:

• [sendHttp] # 1830 Establecer tiempo de espera y salida anticipada cuando se alcanza el tiempo de espera
• [WiFiClient] Establezca el tiempo de espera y hágalo configurable para los controladores
• [Núcleo 2.4.1] Volver al núcleo 2.4.1 desde 2.4.2

Y en 20181006:

• [WiFi] Agregar retraso a los intentos de conexión en ControllerSettings

¿Quizás podría probar la compilación 20181003 y tal vez estos otros 2 también para reducir el problema?

Lo intentaré, pero me temo que no podré hacerlo hasta el sábado. ;-)

¿Tiene alguna idea de cuánto tiempo pasa antes de que se pierda la conexión MQTT?
¿Y de alguna manera coincide con una reconexión wifi?

Por lo que pude ver, no hubo pérdida de Wifi.
que la conexión MQTT se perdió fue bastante rápido esta mañana (10 min) pero también tuve horas según la última entrada del IOBroker ...
Intentaré comenzar al menos una de las 3 compilaciones esta noche.

Solo como un cheque; ¿Lo construye usted mismo o usa compilaciones nocturnas?

otra cosa para comprobar:

¿Estás seguro de que MQTT deja de funcionar?
El mío aquí muestra después de un tiempo "Conexión PERDIDA" pero todo sigue funcionando con MQTT.

El único error que veo es el mensaje "Conexión perdida" mientras todo sigue funcionando.
Por ejemplo, obtengo minutos de tiempo de actividad mediante el controlador MQTT.
Después de un tiempo (entre 10 minutos y 10 horas) veo "Conexión perdida", pero los minutos siguen contando.

Greetz
Sascha

MQTT debería volver a conectarse tan pronto como detecte que ya no está conectado.
Consulte también @ Sasch600xt otro problema relacionado:
https://github.com/letscontrolit/ESPEasy/issues/1873#issuecomment -431170001

Algunas compilaciones antes de 20180927, la que informa que funciona bien, agregué una solución para los controladores MQTT en la que el cliente MQTT en el ESP se dará a sí mismo una nueva ID de cliente, solo para evitar que el corredor rechace una nueva conexión cuando el corredor aún asume una conexión existente de ese cliente y el cliente cree que está desconectado.

¿Puede aumentar la configuración de tiempo de espera del controlador? El valor predeterminado era 1000 mseg, antes de introducir esa configuración y la primera compilación tenía 100 mseg como valor predeterminado. Más tarde cambié el valor predeterminado (para nuevas configuraciones) a 300 mseg.
Entonces, tal vez pueda intentar configurarlo en 300 o más (no más de 1000 mseg) solo como una prueba. (no importa qué versión, al menos una que solía fallar)

Experimenté el mismo problema con 1 (de 5) unidades. He jugado un poco con la configuración del controlador MQTT (intervalo de envío mínimo, profundidad de cola máxima, reintentos máximos y acción de cola completa); configuraciones que funcionan ahora para mí con esta unidad: 1000ms, 5/5 y "Eliminar más antiguo".

Ok noticias ...
Parece que es el mismo problema del que habla blb4github hace 12 horas. Tomó una unidad NUEVA y funciona hasta ahora sin problemas !!!! Parece que el "viejo" tiene problemas de memoria o problemas de sincronización. Intentaré aumentar el tiempo de espera en este ... mantenerte informado ;-)
Por cierto ... (Lo siento ... Autoconstrucción con Atom ... porque no quiero todos los complementos ... Pero hasta ahora siempre ha ido bien ...) Todos ustedes están haciendo un gran trabajo en esto ... y por lo que descubrí es solo esto (y por lo tanto el que tiene el software más nuevo) el que tiene este problema. Aumentaré la configuración y te lo haré saber.

Saludos Peter

@fraeggle ¿ es posible que pegue aquí una captura de pantalla de las páginas de systemminfo de los módulos buenos y malos? (secciones esp y almacenamiento)

Y alguna descripción del hardware.
Por ejemplo, tengo la sensación de que recientemente se han producido algunos cambios en los módulos sonoff.
Sonoff basic y el S20

@fraeggle ¿Quizás también podría realizar una limpieza completa del nodo problemático y comenzar a limpiar?
Los archivos bin vacíos se incluyen en los archivos ZIP de lanzamiento.

Hola TD-er
había borrado el nodo defectuoso antes ... Desde que cambié la configuración de tiempo de espera a 800ms
es estable. El voltaje se actualiza cada 120 segundos.

Hardware nada especial ... porque todavía estamos esperando que llegue INA219 .. ;-)

Saludos Peter

ups, desafortunadamente lo cerré ..

Pero creo que con este "workaroud" se puede cerrar ... Realmente creo que ahora es un problema de Unidad ...
¿Qué te parece TD-er?

Aún así, es extraño que las unidades difieran en este aspecto.
Sugeriría que la estabilidad wifi es peor en una unidad

Estoy de acuerdo, pero creo que esta unidad simplemente tiene un rango de tolerancia demasiado grande. Como te dije, desde que cambié a 800 ms funciona bien ...
Entonces, si está de acuerdo, cerraré este, debido al hecho de que existe la posibilidad de cambiar el tiempo de espera.

Gracias por tu ayuda..

saludos Peter

Encontré "desde 20181007 MQTT Open Hab muestra" Conexión perdida "# 1873.
¿Quizás el mismo problema?
TD-er dime si puedo ayudar creando registros o algo así ...
Usando Openhab (con IOBroker). pero hasta ahora no hay error después de configurar el tiempo de espera en 800ms

¿El broker MQTT para OpenHAB que está ejecutando, está instalado en una computadora en su propia red o es externo?
Y si es local, ¿quizás esté instalado en una computadora que carece de recursos?

También tengo una prueba en ejecución desde 394 minutos en 20181020.
Tiempo de espera a 800 ms.
A veces aparece como Desconectado después de 24 horas o incluso más. Pero nunca llegué a los 2 días.
Y de nuevo, para mí todo sigue funcionando después de que muestra "Conexión perdida". Así que es solo el mensaje lo que me confunde. Te mantendré informado

Conexión perdida es solo un mensaje de información que indica ... que se perdió la conexión.
Pero debería reiniciar una nueva conexión.
En la página sysinfo puede ver con qué frecuencia se perdió y se reconstruyó la conexión WiFi y también cuánto tiempo estuvo conectada a WiFi desde la última (re) conexión al punto de acceso.

Tan pronto como se interrumpa la conexión WiFi, también asumirá que la conexión MQTT debe reconstruirse, por lo que considerará que se ha perdido la conexión con el corredor MQTT.
Hasta hace 4 semanas, era posible que el corredor de MQTT no aceptara el nuevo intento de conexión, ya que el corredor aún consideraba que el cliente estaba conectado.
Esto podría resultar en intentos de reconexión indefinidos, cuando el cliente seguía intentando conectarse y el corredor no acepta la conexión.
Cambié la ID de cliente de MQTT en cada reconexión (agregando el número de reconexiones a la ID de cliente) para que el corredor lo considere un nuevo cliente.
Esto da como resultado una reconexión rápida, con como único inconveniente, el corredor enviaría el LWT (última voluntad y testamento) ya que asume que el cliente está desconectado.

Si eso da como resultado un comportamiento no deseado, puedo cambiarlo a una nueva estrategia.
Por ejemplo, en un intento de reconexión que falla, puedo intentar enviar primero un mensaje de desconexión adecuado.

En resumen, existen numerosas opciones en las que se puede perder la conexión con el corredor y no estoy seguro de por qué en su caso se pierde.
Podría ser un tiempo de espera, desconexión de WiFi, alguna respuesta desconocida del corredor o cualquier otra razón.

Ok lo tengo.
Muy buena declaración, gracias.
Estoy en el minuto 507 en este momento / Abrir controlador HAB / tiempo de espera de 800ms.
Hasta ahora todo está bien :)

¿Debo volver a establecer el tiempo de espera predeterminado para las nuevas instancias de un controlador en 1000 mseg?

bueno ... dame 36 horas más ... entonces sé mejor que el error también viene con 800ms o no.

Minuto 629 ahora sin problemas ...

raro ... descubierto después de cambiar a 800ms.
Razón de la última desconexión | (200) Tiempo de espera de la baliza
El número se vuelve a conectar | 3
¿Qué significa das Beacon Timeout?
MQTT todavía se está ejecutando, pero ahora es el mismo que Sasch600txt. Pero diferente que antes ... MQTT sigue funcionando
solo el corredor le dice que este no está conectado.

Para obtener más información sobre el marco Beacon, consulte Wikipedia.
En resumen, el punto de acceso envía periódicamente un paquete que contiene información sobre la red.
Este intervalo suele ser de 100 TU (102,4 ms).
El módulo ESP está intentando escuchar esta baliza cada vez, pero por varias razones puede perder una trama de baliza. El tiempo de espera es superior a 100 TU, por lo que debe perder algunas de estas tramas de baliza para informar un tiempo de espera de baliza.
Las razones para perder un marco de baliza de este tipo son:

• demasiado ocupado procesando otras tareas de bloqueo (muy probablemente)
• el punto de acceso no envía una baliza debido a las altas demandas de tráfico de otros (según la marca / modelo / configuración)
• Perturbaciones de RF (probablemente no dada la frecuencia con la que esto ocurre)
• deriva del reloj (no es muy probable)

Entonces, el "tiempo de espera de la baliza" ocurre de vez en cuando en los nodos ESP.
Estoy trabajando duro para que todos los complementos / controladores utilicen segmentos de tiempo cortos para hacer que las tareas sean lo menos bloqueadas posible.

Puedo confirmar todo fraeggle dicho.
En algún momento esta noche tengo "Conexión perdida"

Ten un buen fin de semana :)
Sascha

@fraeggle :
si aparece como "Conexión perdida" intente ir a la configuración del controlador de ESPEasy, simplemente desactive el controlador -> guardar, habilítelo de nuevo -> guardar. Entonces, al menos para mí, aparece como conectado nuevamente. No es una solución, pero al menos interesante :) ¿Es este IPSymcon que está utilizando?

@ TD-er:
tareas demasiado ocupadas? bueno ...... en la "UNIDAD DE PRUEBA" que tengo corriendo aquí, solo envío minutos de tiempo de actividad cada 60 segundos ...... nada más se está ejecutando en esta unidad ..... así que probablemente el sistema más pequeño posible

@ Sasch600xt, los términos "demasiado ocupado" tal vez no sean los mejores para describir el problema real.
La forma de hacer las cosas de Arduino es:

• llamar setup()
• llame a loop() una y otra vez.

Además de eso, la versión de Arduino para ESP8266 (y ESP32 Arduino) están ejecutando algunas tareas fuera de loop() para la parte de Arduino.
Estas tareas se refieren a procesos en segundo plano, como manejar la conexión de red y el tráfico entrante, etc.
Las tareas en segundo plano se ejecutan solo en:

• fin de un loop()
• al llamar a delay() o yield() desde dentro del espacio de Arduino.

Si la ejecución de un bucle tarda más de 102,4 ms y no se realizan llamadas a yield () o delay (), el nodo ESP habrá perdido un intervalo de baliza.
Además, si está ejecutando varias tareas de bloqueo que siempre están ocupadas en el momento en que el punto de acceso WiFi envía la baliza, se perderán varias balizas.

Cuando mires el registro en serie (con el nivel de depuración habilitado), verás las estadísticas de tiempo.
Algunos de ellos pueden producir varias decenas de milisegundos y, por lo tanto, son candidatos para causar estas razones de "desconexión".

Podría agregar una tarea al programador para intentar escuchar la baliza cada 102,4 ms. Lo único es que no estoy seguro de cómo ver cuándo se ha visto una baliza de este tipo.

Acerca de este problema, podría investigar la desconexión / reconexión de MQTT cuando se perdió una conexión.
¿Qué corredor estás usando? Estoy usando Mosquito aquí y funciona bien con el comportamiento actual.

ok, "demasiado ocupado" fue un poco fácil de decir de mí :)

Estoy usando un script que se ejecuta en mi evento de control de la casa ipsymcon para el corredor MQTT

Greetz
Sascha

Hola Sascha .. Usando IOBroker.
@ TD-er volvió a la compilación 27092018. El agente me dice que todavía estoy conectado ...
Realmente confuso ... SIN errores dentro de las 14 horas (el número se vuelve a conectar | 0)

Estoy instalando IObroker ahora en mi computadora, solo para ver qué está pasando.

Editar:
45 minutos más tarde y todavía no puedo hacer que IObroker se ejecute en mis computadoras.
No estoy seguro de lo que está sucediendo aquí, pero el instalador de Windows simplemente no funciona (el archivo bat de servicio no se encuentra en ninguna parte) y la instalación en Linux simplemente no termina. Sigue intentando hacer la misma instalación de npm una y otra vez.
Probado en Ubuntu 18.04 en un host de CPU Intel y Bash en Windows (Ubuntu 18.04)

No estoy seguro con Windows ... Creo que hay algunas dependencias de software. Ejecutarlo en Frambuesa.
para Windows ioBroker verwendet Node.js como Plattform und setzt diese voraus. (Descarga: http://nodejs.org/download/) Primero se debe instalar node.js.

También tengo un problema con un módulo con 4 sensores DS18B20 conectados.
Pensé que era mi RasPi, pero tomé una imagen limpia de Raspbian Streth e instalé mosquitto y node-red en ella. El mismo problema, la conexión se interrumpe después de 6-12 horas.

Panel de control: https://emoncms.org/Edegem/scrtmp2e
Las 4 curvas del ESP son CV_aanvoer, CV_retour y Sanitair_warm, Sanitair_koud

@fluppie si usa compilaciones oficiales?

No, me construyo con PlatformIO / Atom
EDITAR: Ja, no leí bien, intentaré una compilación oficial.

¡Veamos esto!

Hola

Tengo / tuve el mismo problema, estoy usando HomeAssistant pero después de ESPEasy_mega-20181111 fw, el problema parece arreglado para mí.

Gracias
T

El mío todavía estaba perdiendo la conexión después de 2-3 días. Actualizaré a: ESP_Easy_mega-20181112_normal_ESP8266_4096.bin

¡Veamos!

El mío fue perder la conexión. después de 1-10 horas. Tengo ~ 10h30min de tiempo de actividad y todos (5 piezas) los módulos relacionados conectados. :-)

Parece que valdría la pena intentarlo ... todavía en 2709 porque necesita una conexión estable. Por favor, mantenme informado. :-))

También puede seguir a través de: https://emoncms.org/Edegem/scrtmp2e y comprobar si los gráficos CV_ y Sanitair_ están ahí :).

1 día de tiempo de actividad y todavía está bien. :-)

También puede seguir a través de: https://emoncms.org/Edegem/scrtmp2e y comprobar si los gráficos CV_ y Sanitair_ están ahí :).

:-D Sanitair_warm casi 60 C? pequeña fogata? ;-)
Probaré la firma .. Gracias ...

Me estaba bañando ;-)

1 día ... todavía conectado :-D
usando 12112018

Después de ~ 3 días 3 horas, uno de mi unidad perdió la conexión MQTT. :-( (mega-20181112 4096 VCC fw)

@redskinhu :
solo para asegurarse, ¿sigue funcionando bien después de que la unidad perdió la conexión MQTT?
porque, por mi parte, solo aparece como "conexión perdida", pero sigue funcionando bien con todas las acciones de MQTT.

Greetz
Sascha

De hecho, una conexión perdida no es infrecuente de vez en cuando.
Mientras la conexión se reconstruya sin intervención humana, no hay problema.
Las conexiones WiFi se restablecerán de vez en cuando y no hay nada que pueda hacer para evitarlo.
Tan pronto como se pierde dicha conexión, notifica a los clientes MQTT en el mismo nodo que se vuelvan a conectar.

Parece algún tipo de problema relacionado con LWT. MQTT no está totalmente desconectado, ESPEasy envía / recibe mensajes MQTT pero el LWT no se renueva, por lo que HomeAssistant no recibió el mensaje LWT conectado, por lo que muestra que el sensor / interruptor relevante no está disponible. Esta es mi teoría ...

La mía Aún está conectada y, a diferencia de mi primera publicación, incluso MQTT LWT me dice que está conectada. Se ve bien.

De hecho, una conexión perdida no es infrecuente de vez en cuando.
Mientras la conexión se reconstruya sin intervención humana, no hay problema.
Las conexiones WiFi se restablecerán de vez en cuando y no hay nada que pueda hacer para evitarlo.
Tan pronto como se pierde dicha conexión, notifica a los clientes MQTT en el mismo nodo que se vuelvan a conectar.

OK, ¿existe la posibilidad de renovar el LWT conectado en este caso?

Se supone que envía el LWT en el momento en que renueva la conexión.

Tengo un nodo en este momento que se muestra desconectado en el LWT y envía medidas sin problemas. Una construcción un poco más antigua ... tal vez esto te diga algo

Versión GIT: | mega-20181008
Tiempo de actividad: | 3 días 17 horas 36 minutos

He visto cosas extrañas cuando el nodo ESP piensa que estaba desconectado y necesita volver a conectarse, pero el corredor no está de acuerdo.

Hola

Hice una pequeña investigación. Parece que el problema es el LWT. Uno de mis ESP volvió a producir esta cosa "desconectada" de MQTT.

Todo funciona bien, sensores / interruptores. Pero Home Assistant no pudo verlos porque en la configuración proporcioné los detalles de LWT.

- platform: mqtt
  name: "Socket 02"
  command_topic: "home/Socket02_ESP12F/GPIO/13"
  state_topic: "home/Socket02_ESP12F/Relay/State"
  availability_topic: "home/Socket02_ESP12F/status/LWT"
  payload_available: "Connected"
  payload_not_available: "Connection Lost"
  payload_on: "1"
  payload_off: "0"
  qos: 1

Verifiqué el tráfico MQTT: obtuve los datos del sensor y pude encender / apagar el GPIO. Todo está bien ex. el LWT.

Y después de que publiqué un mensaje LWT "Conectado" y todo volvió a la normalidad.

Espero que ayude.

T

PD:
Estoy pensando en una regla que puede publicar el mensaje LWT Connected si el mensaje LWT está Desconectado, pero lamentablemente no puedo importar cadenas MQTT ;-)

De todos modos, he estado esperando ansiosamente el nuevo lanzamiento de fw. 4 largos días ....

Estuve fuera el lunes / martes y los días posteriores estuvieron muy ocupados;)

Echaré un vistazo a la LWT para ver si puedo encontrar por qué no se publica al volver a conectar.

¿Cuál es la configuración de tiempo de espera del bróker MQTT?
Estoy pensando en la posibilidad de que el corredor asuma una conexión perdida, pero el nodo ESP todavía actúa como si hubiera estado activo y todavía está conectado.

Intenté 100-1000 ms. Ahora 300. No importa.

No en el controlador, en el corredor.
Esos tiempos son del orden de 10 a 15 segundos.
Por lo tanto, verifique en la configuración del corredor qué tiempo de espera se está utilizando.

No cambié nada sobre el tiempo de espera de LWT y no pude encontrar ninguna configuración relevante en mi configuración de Mosquitto. Debe ser predeterminado. Tampoco pude encontrar ninguna configuración de tiempo de espera de LWT en los documentos.

No, no es el tiempo de espera de LWT, el tiempo de espera del corredor.
Si un cliente no envía un mensaje en el período de tiempo de espera, el corredor lo considerará desconectado.
Entonces, si el cliente usa otra configuración de tiempo de espera, podría ser que el corredor considere que el cliente está desconectado y el cliente no intenta volver a conectarse.

Lo que entiendo de la especificación mqtt es que el corredor envía LWT cuando no recibe un mensaje del cliente dentro del período Keep Alive que establece el cliente. Nada que configurar en el lado del corredor.

Consulte https://www.hivemq.com/blog/mqtt-essentials-part-10-alive-client-take-over

Y

https://www.hivemq.com/blog/mqtt-essentials-part-9-last-will-and-testament

Eso es cierto, pero lo que quiero saber es qué es este "Período de vida" en el lado del corredor.
Sé que está arreglado en el lado ESPeasy.
Pero si estos no están sincronizados entre sí, verá que suceden cosas extrañas.

hm no tengo ninguna posibilidad de configurar algo como esto

Pero todavía dice "Conectado". 4 días :-D

Acabo de hacer lo mismo con un mega-20181006. LWT no actualizado a Online pero normalmente funciona MQTT

@ jimmys01 ¿Puede ver en su corredor si está basando la decisión en la identificación del cliente? (esto cambia cuando se pierde la conexión)
Este cambio de ID de cliente es algo que agregué a finales de septiembre.

@ TD-er, ¡encontré una manera de reproducir esto! De-auth el wemos del enrutador mikrotik y se conecta de nuevo, pero el LWT permanece fuera de línea mientras el mqtt todavía está funcionando. Envíame construcciones para probar a voluntad

¿También puede ver la identificación del cliente en el corredor de MQTT?
Si tiene un "-1" o algo detrás del ID de cliente, significa que acepta el nuevo ID de cliente.
Si no es así, puede que tenga algo que ver con el cambio de ID de cliente que hice hace un tiempo.

No he averiguado dónde está la identificación del cliente en Mosquitto, pero los registros muestran como si no se desconectara ningún cliente y se conectara uno nuevo, probablemente porque el proceso de autenticación y desactivación de wifi es más rápido que el latido del protocolo MQTT.

Nueva conexión después de reiniciar tanto el esp como el corredor

 New connection from 10.10.1.53 on port 1883.
1542965214: New client connected from 10.10.1.53 as aquariums_1 (c1, k10, u'openhabian').

Dar de baja al cliente y el cliente se vuelve a conectar. El corredor esta vez dejó al cliente LWT en línea por alguna razón ...

1542965214: New client connected from 10.10.1.53 as aquariums_1 (c1, k10, u'openhabian').
1542965308: New connection from 10.10.1.53 on port 1883.

Segundo desautorización

1542965308: New client connected from 10.10.1.53 as aquariums_1_1 (c1, k10, u'openhabian').
1542965308: Socket error on client aquariums_1, disconnecting.
1542965385: New connection from 10.10.1.53 on port 1883.

Desde esta reconexión y en el LWT permanece fuera de línea, los mensajes MQTT funcionan bien. Observe el _1_1 adicional en el nombre del cliente.

1542965385: New client connected from 10.10.1.53 as aquariums_1 (c1, k10, u'openhabian').
1542965385: Socket error on client aquariums_1_1, disconnecting.
1542965448: Socket error on client aquariums_1, disconnecting.

De acuerdo, revertiré el cambio de ID de cliente.
¿Quizás también sea posible verificar remotamente si se considera que el cliente está conectado?
He visto que la conexión se niega cuando el corredor considera que el cliente aún está conectado y el cliente intenta volver a conectarse.
Reintentar en intervalos cortos mantendrá este estado y, por lo tanto, el cliente nunca podrá volver a conectarse.

¿Alguna actualización de estado sobre esto?

No, no todavía.
Pero dado que estamos progresando (finalmente) en otros temas de estabilidad, supongo que será el siguiente en mi lista.
Gracias por el ping;)

Hice que sea opcional cambiar la identificación del cliente al volver a conectarme. (Herramientas => Avanzado, junto a las otras configuraciones de MQTT)

Cierra el problema si está funcionando ahora.
Lo pondré en fijo.

¿Por qué cambiar la identificación del cliente de todos modos?

Hubo informes de que el corredor rechazó los intentos de conexión siempre que el corredor asuma que el cliente todavía estaba conectado.
Entonces el cliente fue rechazado y volvió a intentarlo.
Pero de alguna manera esas reconexiones desencadenaron algo en el lado del corredor para considerar los intentos de conexión como una actividad reciente de ese cliente y, por lo tanto, nunca consideraría que el cliente está desconectado.

Ok, esto lo solucionó, pero la solución no se explica por sí misma para los demás que ven esa casilla de verificación.
Tal vez agregue una ventana emergente que explique cómo marcarla si hay problemas de reconexión después de una pérdida de wifi
Una búsqueda en problemas de tasmota le mostrará que tenían problemas de apariencia similar, relacionados con la retención de MQTT, parecía que esto era un problema de corredor.
También tuve un cliente que no se reconectó a wifi en absoluto después de que lo desactivé ... necesito investigar eso.

Agregaremos esto a la documentación .
Estamos trabajando muy duro para actualizar la documentación y también mover mucha documentación de la wiki a ReadTheDocs. Esto hace posible tener documentación por versión.
Los archivos de documentos también se incluyen en el repositorio de GitHub.

Idealmente, una confirmación para una corrección en el código también contendrá una actualización en la documentación.
Ahora cerraré este tema.
Si tiene más información sobre el otro problema que mencionó, abra un nuevo problema para eso.

Hola

Instalé la versión 20190110 recientemente. Parece prometedor. Sin problemas de LWT después de 5 días de prueba. :-)
Tengo un par de nodos con la opción "MQTT cambiar ClientId al reconectar" habilitada y algunos con deshabilitada.

¡Buenas noticias!

T