.encode not available on STM32F05 build -- potential workaround

[jerryneedell]

The STM32F405 build does not have .encode available.
see this discussion adafruit/circuitpython#2433 (comment)

I have a fix for this -- so it works without .encode
do you want a PR for it?

here are the diffs

jerryneedell@Ubuntu-Macmini:~/projects/stm32f405/airlift$ diff adafruit_minimqtt.py ~/projects/adafruit_github/Adafruit_CircuitPython_MiniMQTT/
121c121
<         if self.password is not None and len(bytes(password,"utf-8")) > MQTT_TOPIC_LENGTH_LIMIT:
---
>         if self.password is not None and len(password.encode('utf-8')) > MQTT_TOPIC_LENGTH_LIMIT:
129c129
<             self.client_id = 'cpy{0}{1}'.format(microcontroller.cpu.uid[randint(0, len(microcontroller.cpu.uid)-1)],
---
>             self.client_id = 'cpy{0}{1}'.format(microcontroller.cpu.uid[randint(0, 15)],
355c355
<             msg = bytes(str(msg),"ascii")
---
>             msg = str(msg).encode('ascii')
357c357
<             msg = bytes(str(msg),"utf-8")
---
>             msg = str(msg).encode('utf-8')
690c690
<             self._sock.send(bytes(string, "utf-8"))
---
>             self._sock.send(str.encode(string, 'utf-8'))
705c705
<         elif len(bytes(topic,'utf-8')) > MQTT_TOPIC_LENGTH_LIMIT:
---
>         elif len(topic.encode('utf-8')) > MQTT_TOPIC_LENGTH_LIMIT:

note the change at line 129 -- the STM build microcontroller.cpu.uid is only 12 bytes so this was failing -- I set it to len() to avoid the error

[jerryneedell]

regarding the length of microcontroller.cpu.uid I have found that it varies
for atmel MCUs it appears to be 16 bytes long, but for nrf52840's it is only 8!
Has anyone tried this library on an nrf52840?? It will likely fail half the time due to this.
For the stm32f405 it is 12 bytes ( you have a 75 % chance of passing)

so regardless of the .encode issue, it looks like line 129 should be changed.

Do you want me to create a PR for that? would you prefer 2 different PRs?
one for .encode and one for the uid fix?

[jerryneedell]

@brentru The STM32F405 issue has been made moot since .encode is now available in current master.
1)Do you think it useful to make these changes anyway just so it is not necessary to have it?
2)Line 129 definitely needs to be fixed. Should I just do that in a PR by itself?

[brentru]

@jerryneedell 1) Let's leave it as-is, .encode. should work the same across MCUs

2. Yes, I'd be thankful if you could create a new PR for that. I have some thoughts...

regarding the length of microcontroller.cpu.uid I have found that it varies
for atmel MCUs it appears to be 16 bytes long, but for nrf52840's it is only 8!
Has anyone tried this library on an nrf52840?? It will likely fail half the time due to this.
For the stm32f405 it is 12 bytes ( you have a 75 % chance of passing)

L129 creates a ClientID such that each one is unique per-microcontroller (req'd in MQTT spec, also lots of brokers disconnect identical CIDs).

Since this library supports circuitpython libraries for linux devices and the UID is different per chip, I think we should move away from using microcontroller-specific API calls (I would suggest temperature, but that limits devices running adafruit-blinka). We could hash the random integer with a call to time.monotonic instead of the chip's identifier.

[jerryneedell]

@jerryneedell 1) Let's leave it as-is, .encode. should work the same across MCUs

1. Yes, I'd be thankful if you could create a new PR for that. I have some thoughts...

regarding the length of microcontroller.cpu.uid I have found that it varies
for atmel MCUs it appears to be 16 bytes long, but for nrf52840's it is only 8!
Has anyone tried this library on an nrf52840?? It will likely fail half the time due to this.
For the stm32f405 it is 12 bytes ( you have a 75 % chance of passing)

L129 creates a ClientID such that each one is unique per-microcontroller (req'd in MQTT spec, also lots of brokers disconnect identical CIDs).

Since this library supports circuitpython libraries for linux devices and the UID is different per chip, I think we should move away from using microcontroller-specific API calls (I would suggest temperature, but that limits devices running adafruit-blinka). We could hash the random integer with a call to time.monotonic instead of the chip's identifier.

I'm open to anything -- should I just go ahead with the change to I proposed for now (using len()) or do you want to implement something else now.

[brentru]

Let's implement it with time.monotonic instead of cpu id

[jerryneedell]

Let's implement it with time.monotonic instead of cpu id

OK -- something like this?

self.client_id = 'cpy{0}{1}'.format(random.randint(0, int(time.monotonic())%100), random.randint(0, 9))

will it be a concern that on reboot of an MCU, time.monotonic() always starts at 0 and the seed value may be somewhat deterministic if the call to initialize is executed at the same time after boot.

[brentru]

will it be a concern that on reboot of an MCU, time.monotonic() always starts at 0 and the seed value may be somewhat deterministic if the call to initialize is executed at the same time after boot.

Possibly, the case where this would be applicable is if both devices are sitting on the same power breaker (for example) and reboot at the same time. We could wait a random amount of time, we could also increase the range of the randint we're hashing with.

[jerryneedell]

will it be a concern that on reboot of an MCU, time.monotonic() always starts at 0 and the seed value may be somewhat deterministic if the call to initialize is executed at the same time after boot.

Possibly, the case where this would be applicable is if both devices are sitting on the same power breaker (for example) and reboot at the same time. We could wait a random amount of time, we could also increase the range of the randint we're hashing with.

maybe

'cpy{0}{1}'.format(random.randint(0, int(time.monotonic()*100)%1000), random.randint(0, 99))

uses some fractional seconds as well

[brentru]

Let's go with that 👍

[jerryneedell]

PR submitted -- tested on grand_central_m4
unfortunately stm32f405 has still not been updated to include .encode -- WIP

[brentru]

@jerryneedell Ok - when the adafruit/circuitpython#2457 WIP works and releases, please update or close this issue.

[jerryneedell]

fixed via adafruit/circuitpython#2457