MQTTException(30) #Connection timeout

[JoseFQL]

When I use the umqtt.simple with the same parameters I can publish messages to AWS, but when I want to use want to use umqtt.simple2, I can't connect, even if I put "socket_timeout=None" in init it just keep waiting, it gives me the next error:

Traceback (most recent call last): File "main.py", line 99, in File "umqtt/simple2.py", line 289, in connect File "umqtt/simple2.py", line 92, in _read File "umqtt/simple2.py", line 89, in _read File "umqtt/simple2.py", line 162, in _sock_timeout MQTTException: 30

I guess it just freeze in the line : res = poller.poll(-1 if socket_timeout is None else int(socket_timeout * 1000)) def _sock_timeout(self, poller, socket_timeout): if self.sock: res = poller.poll(-1 if socket_timeout is None else int(socket_timeout * 1000)) if not res: raise MQTTException(30) else: raise MQTTException(28)

[fizista]

Too little information for me to help. The only thing that can be said is that there is a problem with the connection.

Describe the bug A clear and concise description of what the bug is.

To Reproduce Steps to reproduce the behavior: For example a piece of code that can be pasted into a micropython console.

Details (please complete the following information):

• Device board: [e.g. ESP32]
• Micropython version: [e.g. 1.12, name or URL fork]
• Library version [e.g. 0.1]

[tom24]

I had the same problem but came up with a fix and got it working on a raspberry pico-w.

The problem is that using poll() on an ssl socket does not work right if there is pending data associated with the ssl socket. In the more limited ussl library I could not find a way to get to the status of the pending data.

What I found, at least for an ssl socket and in nonblocking mode, that you can attempt a read(). If it returns None, then there must not be any pending data. In that case you can use poll() to wait for the real socket to get some more. If the read returns data instead of None, no need to do the poll.

So the fix is to put the socket in nonblocking mode and when checking for new received data, first do a read() and only poll() if read() returned None.

I put my changes in a fork at https://github.com/tom24/micropython-umqtt.simple2. The changes are in the branch awsfix_plus.

The changes are minor but I'm not ready to do a pull request. There is a chance it may break something when not using ssl. For example, a read() on a 'normal' socket with no data may result in exception instead of returning None. This would be easy to handle, just not done yet.

Also in this branch in examples/awsiot is a sample program to exercise with AWS. The simplest way to get the right keys, permissions, etc is to follow their "set up a single thing" walkthrough which installs everything on, say, a linux computer. Then you can copy from that the keys and any other details you need.

[sgbaird]

@tom24 's fork worked on avoiding the timeout error and receiving/publishing messages, but when I try to use the requests library to log to MongoDB afterwards I get ENOMEM:

  File "urequests.py", line 184, in post
  File "urequests.py", line 93, in request
OSError: [Errno 12] ENOMEM

Related to https://github.com/micropython/micropython/issues/2055#issuecomment-234270744 perhaps? Context: https://github.com/sparks-baird/self-driving-lab-demo/issues/134

I verified that the only difference was changing simple to simple2. I'll see about getting a MWE.

@tom24 a draft PR would be nice so it's easier to see the changes and make comments.

EDIT: I verified that I can send a fixed "dummy" payload if I comment out some bulkier sensor code for the AS7341 and pass an example set of hard-coded values directly. I guess that means if I want to use the fix as-is I'll need to reduce the amount of memory I use.

EDIT: I verified that I don't get the ENOMEM error with mqtt.robust

[fizista]

I moved @tom24's fork fixes to the main branch, and added a couple of new changes.

With esp8266 encrypted connections maybe working. Unfortunately, this device has very little memory.

It is possible that the above problem has already been fixed in the current new version.