QUERY · ISSUE
MQTT subscribe Remaining Length encoding is incorrect
See this discussion for background, also MQTT spec V3.1.1 section 2.2.3.
This may be academic as its main impact is if the topic field is long. This is to record the existence of the issue.
The current encoding stores Remaining Length in a byte. It should be stored as a Variable Byte Integer as per .publish. This will cause a failure if Remaining Length is greater than 127, therefore imposing a limit on the length of the topic field.
I can submit a PR if the maintainers think this is worth fixing.
CANDIDATE · PULL REQUEST
Fixed SyntaxError in subscribe()
>>> 1.to_bytes(1)
Traceback (most recent call last):
File "<stdin>", line 1
SyntaxError: invalid syntax for number
So, what's exactly being fixed here?
I had an exception on this string, because
int()has noto_bytes()method. I callsubscribe()without QoS and it makes QoS become0.Of course it has:
You convert a
tupleto bytes, butqosisinthttps://github.com/Himura2la/micropython-lib/blob/master/umqtt.simple/umqtt/simple.py#L144
Maybe my next commit will be a better option if tuples are OK with
to_bytes()So do you see the issue now?
I don't, sorry. As far as I can tell, the issue you had was because you used a wrong branch of the project. That branch was rebased since, but why did you use it in the first place?
I tested this and it somehow works
Very strange behavior, but OK, it works...
@Himura2la the problem was simply that
1.to_bytes(...)looks like a decimal number to Python and so that's why it gives a syntax error. It can be fixed by putting a space before the period:1 .to_bytes(...), or as shown above putting the number in parenthesis:(1).to_bytes(...). Note that it's not a tuple with one element, that would be(1,).to_bytes(...)which doesn't work (tuple doesn't have a to_bytes method). And sinceqosis not an integer literal that works fine without a space. This is all standard Python behaviour.Thanks for explanation, there are some quite confusing dark corners of Python...