MQTT en módulos SIMCom
132 views
Skip to first unread message
Miguel Grassi
Nov 11, 2025, 10:21:01 PMNov 11
to Embebidos32
Hola gente,
Si en la lista hay alguien con experiencia usando módulos SIMCom (SIM76xx o similares) para conexiones MQTT que quiera charlar u opinar en el siguiente tema, estaré muy agradecido.
Si en la lista hay alguien con experiencia usando módulos SIMCom (SIM76xx o similares) para conexiones MQTT que quiera charlar u opinar en el siguiente tema, estaré muy agradecido.
Comento la situación:
El módulo se conecta con el broker fácilmente y en algunos casos la conexión se mantiene mucho tiempo sin problemas. Parecería que mientras el cliente no recibe mensajes, es muy estable. Sin embargo en otras ocasiones, (pareciera que especialmente unos pocos segundos luego de recibir algún mensaje MQTT normal, pero es difícil asegurarlo) la conexión se interrumpe.
Luego de luchar bastante configurando timeouts y keepalives sin resultados repetibles y seguros, opté por implementar un heartbeat propio y con eso conseguí paliar el problema que el broker logeaba como: "Client xxxxx has exceeded timeout, disconnecting."
Sin embargo me sigue pasando muy seguido que la conexión se interrumpe como si lo hiciera el propio módulo (en el broker el log acusa: "Client xxxxx closed its connection.") y eso me tiene intrigado. Tengo una estrategia de reconexión y bla bla, pero me gustaría lograr una comunicación más estable porque un proceso de reconexión muy frecuente es demasiado demandante en términos de tiempo, batería, tráfico, mensajes perdidos en el ínterin, etc.
El segundo tema que quería consultar es sobre el retraso en recibir mensajes de los canales a los que el módulo se suscribe. En algunos casos llegan en forma prácticamente instantánea y en otros pueden demorar 20 o 30 segundos y más también. A veces con pérdida total del mensaje, aún con QoS 1. Y aunque los mensajes se puedan recuperar y demás resguardos adicionales que uno puede tomar, en ciertas aplicaciones todo el delay que eso produce es inaceptable.
Para las pruebas estoy usando un sim de Movistar para LTE-IoT.
Cualquier comentario o sugerencia es bienvenida.
Saludos y muchas gracias,
Miguel
El módulo se conecta con el broker fácilmente y en algunos casos la conexión se mantiene mucho tiempo sin problemas. Parecería que mientras el cliente no recibe mensajes, es muy estable. Sin embargo en otras ocasiones, (pareciera que especialmente unos pocos segundos luego de recibir algún mensaje MQTT normal, pero es difícil asegurarlo) la conexión se interrumpe.
Luego de luchar bastante configurando timeouts y keepalives sin resultados repetibles y seguros, opté por implementar un heartbeat propio y con eso conseguí paliar el problema que el broker logeaba como: "Client xxxxx has exceeded timeout, disconnecting."
Sin embargo me sigue pasando muy seguido que la conexión se interrumpe como si lo hiciera el propio módulo (en el broker el log acusa: "Client xxxxx closed its connection.") y eso me tiene intrigado. Tengo una estrategia de reconexión y bla bla, pero me gustaría lograr una comunicación más estable porque un proceso de reconexión muy frecuente es demasiado demandante en términos de tiempo, batería, tráfico, mensajes perdidos en el ínterin, etc.
El segundo tema que quería consultar es sobre el retraso en recibir mensajes de los canales a los que el módulo se suscribe. En algunos casos llegan en forma prácticamente instantánea y en otros pueden demorar 20 o 30 segundos y más también. A veces con pérdida total del mensaje, aún con QoS 1. Y aunque los mensajes se puedan recuperar y demás resguardos adicionales que uno puede tomar, en ciertas aplicaciones todo el delay que eso produce es inaceptable.
Para las pruebas estoy usando un sim de Movistar para LTE-IoT.
Cualquier comentario o sugerencia es bienvenida.
Saludos y muchas gracias,
Miguel
Lisandro Damián Nicanor Pérez Meyer
Nov 17, 2025, 4:43:55 PMNov 17
to embeb...@googlegroups.com
¡Hola!
¿El broker lo controlás vos? Si la respuesta es no, sugiero te montes
algo como un mosquitto y lo uses para probar.
Fuera de eso, mi experiencia con los módulso de SimCom siempre fue mala.
algo como un mosquitto y lo uses para probar.
Fuera de eso, mi experiencia con los módulso de SimCom siempre fue mala.
Miguel Grassi
Nov 17, 2025, 5:23:41 PMNov 17
to embeb...@googlegroups.com
Gracias por el comentario, Lisandro. Si, efectivamente, el broker lo manejo yo. El módulo funciona bien, porque a la noche o los fines de semana no se corta nunca. Los días de semana en horario laboral, que viene mucha gente a la zona (Distrito Tecnológico de Parque Patricios) la conexión es mucho más inestable. Me da que es más un problema de la red que de los módulos.
Saludos,
--
-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32...@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es
---
Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a embebidos32...@googlegroups.com.
Para ver este debate, visita https://groups.google.com/d/msgid/embebidos32/CA%2BQPbz0bhgSu2%2BD1D2JNZu4yn-B-W1xAecKCZNRsvGCANeiT8g%40mail.gmail.com.
Diego Dujovne
Nov 17, 2025, 5:43:13 PMNov 17
to embeb...@googlegroups.com
Y probaste con otro proveedor? Capaz que tenga una mejor red, o podés usar un segundo módulo como redundancia.
Saludos,
Diego
Para ver este debate, visita https://groups.google.com/d/msgid/embebidos32/CAErGbdgoGUAkDtV3L%3DSjWui9O3g648j%3DAU5KMvBQUDKVM3_K5g%40mail.gmail.com.
Lisandro Damián Nicanor Pérez Meyer
Nov 18, 2025, 7:51:45 AMNov 18
to embeb...@googlegroups.com
On Mon, 17 Nov 2025 at 19:23, Miguel Grassi <migr...@gmail.com> wrote:
>
> Gracias por el comentario, Lisandro. Si, efectivamente, el broker lo manejo yo. El módulo funciona bien, porque a la noche o los fines de semana no se corta nunca. Los días de semana en horario laboral, que viene mucha gente a la zona (Distrito Tecnológico de Parque Patricios) la conexión es mucho más inestable. Me da que es más un problema de la red que de los módulos.
¡Ah! Efectivamente, lo que estás sufriendo ahí es cuando una antena
>
> Gracias por el comentario, Lisandro. Si, efectivamente, el broker lo manejo yo. El módulo funciona bien, porque a la noche o los fines de semana no se corta nunca. Los días de semana en horario laboral, que viene mucha gente a la zona (Distrito Tecnológico de Parque Patricios) la conexión es mucho más inestable. Me da que es más un problema de la red que de los módulos.
base tiene mas clientes que los que puede manejar sin desconectar a
nadie. Idealmente el firmware del SimCom debería poder avisarte o
cerrar la conexión. Fijate si hay algún comando AT que permita
habilitar algún mensaje de aviso mas explícito.
Miguel Grassi
Nov 19, 2025, 11:35:19 AMNov 19
to embeb...@googlegroups.com
Se monitorea constantemente la conexión y nuestra estrategia de reconexión funciona muy bien, pero cuando entra un mensaje mientras no hay conexión, el delay en procesarlo puede ser hasta dos órdenes de magnitud mayor que la demora normal y eso complica muchas cosas, por la inconsistencia, dificultad para garantizar QoS 1, etc. Pero con la red congetionada parece que no hay más remedio.
--
-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32...@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es
---
Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a embebidos32...@googlegroups.com.
Para ver este debate, visita https://groups.google.com/d/msgid/embebidos32/CA%2BQPbz2mAZyDA5ZqnUV8gc5iH4fWV0m8q1rWmcOfMNDYqAdEiw%40mail.gmail.com.
Reply all
Reply to author
Forward
0 new messages