Welcome to the Pycom forum Forum
    • \[\[global:header.categories\]\]
    • \[\[global:header.recent\]\]
    • \[\[global:header.tags\]\]
    • \[\[global:header.popular\]\]
    • Login

    Explore Pybytes | Official Documentation | Report a Firmware Bug/Issue | GitHub

    MQTT: OSError: -1 from line 160, in wait_msg

    Scheduled Pinned Locked Moved WiPy 2&3
    mqttwipyoserror
    2 Posts 2 Posters 1.1k Views 3 Watching
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • S Offline
      semireg
      last edited by semireg

      I've searched the forums and this is the closest post to what I'm experiencing:

      • https://forum.pycom.io/topic/1592/oserror-1/4

      This is on a new WiPy 3.0 with default MQTT library. This also happens using the other version from micropython-lib (https://github.com/micropython/micropython-lib/blob/master/umqtt.simple/umqtt/simple.py).

      I've tried setting timeout to different values, no luck. This code was working fine on an ESP8266. Thoughts?

      (sysname='WiPy', nodename='WiPy', release='1.11.0.b1', version='3032601 on 2017-12-30', machine='WiPy with ESP32')
      

      Here's the relevant code:

          # Wait for a single incoming MQTT message and process it.
          # Subscribed messages are delivered to a callback previously
          # set by .set_callback() method. Other (internal) MQTT
          # messages processed internally.
          def wait_msg(self):
              res = self.sock.read(1)
              self.sock.setblocking(True)
              if res is None:
                  return None
              if res == b"":
                  raise OSError(-1) # <-- LINE 160
              if res == b"\xd0":  # PINGRESP
                  sz = self.sock.read(1)[0]
                  assert sz == 0
                  return None
      

      My guess is the socket implementation has a bug - it should return None instead of a zero length bytes object. If that's the case, a quick fix would be to make the check less strict:

       if res is None or res == b"":
                  return None
      

      This seems to work OK... What are the implications for relaxing this check?

      1 Reply Last reply Reply Quote 1
      • D Offline
        daniel
        last edited by

        @semireg We'll have a look to see if there's a bug in the socket implementation.

        1 Reply Last reply Reply Quote 0

        Hello! It looks like you're interested in this conversation, but you don't have an account yet.

        Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.

        With your input, this post could be even better 💗

        Register Login
        • 1 / 1
        • First post
          Last post

        Pycom on Twitter

        Pycom