payload parameter of type None
replaced with zero-length string in will_set()
#47
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
satisfies #39 in accordance with paho_mqtt library compatibility
I tested this fix locally (on my trusty ItsyBitsy M4) without connection to a broker. The only esp32 I have lying around is a TinyPico, so properly testing this on my end might be a bit taxing for a 1-line fix. If there's an easier way to test this with a Raspberry Pi, I'd gladly dust off my old RPi.
I followed the data from the
payload
parameter through the code to see if this fix instigates another issue, and I found no problems. However, I'm not sure aboutself._sock.send(string)
whereself._lw_msg
(instance attribute that holds the zero-length string when payload parameter is of typeNone
) is passed as thestring
parameter in_send_str()
. BTW, I have verified thatself._lw_msg
becomesb''
(empty bytearray) when callingwill_set()
using parameters' defaults with this fix.TL;DR
All this to say that the success of this fix depends on the socket interface's ability to send an empty bytearray.