← index #334Issue #134
Related · high · value 1.392
QUERY · ISSUE

umqtt (with tls): check_msg() / wait_msg() - how to know connection is gone? timeout?

openby mirkoopened 2019-03-15updated 2024-11-01

I'm using the umqtt module - on conjunction with ussl_mbedtls - within the UNIX port with mbedtls.
When I re-route the traffic originally going to my MQTT broker to /dev/null (e.g. 127.0.0.1), check_msg() as well as wait_msg() continue behaving as before. No different return value, no exception thrown.
From the umqtt.robust implementation I figure that should be the case though.
I also thought this might be due to an overly long timeout, so I called settimeout(X) on the underlying socket, but then wait_msg() throws an exception right after X seconds - no matter what - which I also appears weird to me.

What's the way to go to catch network issues and potentially reconnect automatically when using umqtt.{simple,robust} with TLS?

3 comments
jonnor · 2024-08-25

Hi. Is this still an issue with the latest MicroPython and mqtt.simple/mqtt.robust versions?

mirko · 2024-08-25

It's been more than 5 years, I honestly have no idea :)

prabhu-yu · 2024-11-01

hi @mirko , @jonnor
I have submitted a fix here.
https://github.com/micropython/micropython-lib/pull/890/files

CANDIDATE · ISSUE

umqtt.simple check_msg() setblocking(False) Fails

closedby timpuropened 2016-12-15updated 2017-02-22

MicroPython v1.8.6-7-gefd0927 on 2016-11-10; ESP module with ESP8266

in
def check_msg(self):
self.sock.setblocking(False)
return self.wait_msg()
setblocking(False) fails only when using ssl.
But when just using the wait_msg() messages are coming through so its not the actual connection something with the USSL i believe is failing.

Normal socket (non SSL) works fine.

Keyboard

j / / n
next pair
k / / p
previous pair
1 / / h
show query pane
2 / / l
show candidate pane
c
copy suggested comment
r
toggle reasoning
g i
go to index
?
show this help
esc
close overlays

press ? or esc to close

copied