mqtt_as Arduino RP2040 Connect

[scruss]

... Perhaps you or someone else might like to try this script

Have to be someone else, I'm afraid. Although I am an Arduino reseller. the only boards that sell consistently from them are Unos

[pythoncoder]

... it would be really great if the mqtt_as could eventually be persuaded to run as I had ideas about running that on my Arduino Nano RP2040 boards....

I have a version which runs for a short while but then the WiFi disconnects. The library re-starts as per a real loss of connectivity, runs for a short while before it disconnects again. The disconnections make no sense: suddenly .isconnected() returns False and the module responds accordingly.

Given the complete failure of umqtt.simple I'm surprised mqtt_as works at all.

If anyone can confirm the behaviours I'm seeing with .ifconfig and umqtt.simple I'll raise tickets.

[beetle]

If anyone can confirm the behaviours I'm seeing with .ifconfig and umqtt.simple I'll raise tickets.

I'd like to have a go but, following along with the info in the doc found in the Arduino web page about how to install micropython has resulted in a complete and utter failure to install.

The CircuitPython install was successful though and this had been already installed by me some months back. During the attempted micropython installation I got the rpi folder showing on my mac desktop (if I correctly remember the folder name) and dropped the micropython .uft file into the folder and it seemed to copy, but sadly no micropython poped up on a reboot, it just come back as a CircuitPython folder.

[pythoncoder]

Did you link gnd and rec, then press the button? You can remove the link after a few seconds, but copying the file should then work. That procedure has been reliable here.

[beetle]

Did you link gnd and rec, then press the button? You can remove the link after a few seconds, but copying the file should then work. That procedure has been reliable here.

Dear Peter,

Yes I was shorting the rec to ground but I gave it another go. First try, again nope, the circuitpython drive disappeared with the usual warning about not ejecting the drive, but no rpi-rp2 drive. Second try I firstly ejected the circuitpython drive and then shorted and pressed reset, and this time up popped the rpi-rp2 drive. I decided to put on the lastest nightly build instead of the 'release' in case that contributed to my previous problems (I had got the rpi-rp2 drive showing before). That copied ok. I think the rpi-rp2 drive disapeared but the drive(port) in /dev was not showing up. A power off/on of the board still did not show up any port in /dev. So I rebooted my mac, connected the board to the usb, and we have a port in /dev and Thonny connected. Got there eventually

So on to some testing with the network and mqtt simple. Probably my ignorance but I found that I had to be sure to disconnect the network before running the connect program again or the second attempt would always fail. The third attempt would connect , but the fourth would fail etc etc, always a success / failure pair. Anyway ensuring the program had a network disconnect meant I could alway connect OK. However the network connect program always gives the following message
- Warning: firmware version mismatch, expected 1.4.8 found: 1.4.5

So on the the mqtt simple.py. I can run the test publish program with the following code.

from simple import MQTTClient
import network
# enable station interface and connect to WiFi access point
station = network.WLAN(network.STA_IF)
station.active(True)
station.connect('MYSID','MYPASSWORD')
print('Network config: ', station.ifconfig())

# Test reception e.g. with:
# mosquitto_sub -t foo_topic

def main(server="10.0.1.141"):
c = MQTTClient("umqtt_client", server)
c.connect()
c.publish(b"foo_topic", b"hello")
c.disconnect()

if __name__ == "__main__":
main()
station.disconnect()

Again the station.disconnect() is necessary or the program will be on a success/fail cycle.

So I don't know if this helps, but do let me know what else I can do to assist.

[pythoncoder]

The message about "expected 1.4.8" must be referring to the NINA-W102 module firmware. This can be upgraded using this procedure but (see my posts above) I didn't find this easy. It's worth doing, but it won't fix your problem.

The difficulties connecting really shouldn't happen. I think there is no escaping that (even with my 1.4.8) the WiFi firmware support is flaky.

[beetle]

The message about "expected 1.4.8" must be referring to the NINA-W102 module firmware. This can be upgraded using this procedure but (see my posts above) I didn't find this easy. It's worth doing, but it won't fix your problem.

The difficulties connecting really shouldn't happen. I think there is no escaping that (even with my 1.4.8) the WiFi firmware support is flaky.

The flakyness does not stop at the wifi I find. After installing micropython upon powering up the board I get a folder called NO NAME popping up on my mac. Running Thonny sees a port called ' Board in FS mode (/dev/cu.usbmodem141201) '. If I eject the folder then Thonny also disconnects. I put a small network connect and mqtt publish program to be called from main.py so it auto runs on boot, but it will only run when connected to my mac and can create this NO NAME folder. If I just power the board from a usb wall wart then the main.py does not run.

Currently the micropython implementation on the Arduino RP2040 is a pigs ear and I suppose it should be regarded as a work in progress.

Just an observation that, if running from this silly NO NAME folder the simple mqtt and network connect seems to start up reliably as long as the program starts with a check to ensure that the board does not think its currently connected to a network
station = network.WLAN(network.STA_IF)
if station.isconnected():
station.disconnect()
Then go on to make a new connection.
(And a test mqtt publish loop has been publishing away for about 4 hours now, shortly to be killed and put into storage to await some hoped for further developments to mp for this board)

[pythoncoder]

... shortly to be killed and put into storage to await some hoped for further developments to mp for this board)

On past performance these problems will be fixed. The failings seem so extensive as not to be worth reporting: whoever is working on firmware for this port is bound to be aware of them.

I don't plan any further work on the board's use with mqtt_as until the board is capable of connecting to a network, displaying correct network config data, and running mqtt_simple without special hacks. I'm fairly confident that, when it passes those tests, it will work with the tweaks I have in the pipeline.

I suggest we try again in a few weeks.

[pythoncoder]

I have raised this ticket.

[pythoncoder]

The issues raised in the ticket are now fixed. The Arduino RP2040 Connect with NINA firmware 1.4.8 and today's firmware build now works with the official MQTT library.

I have pushed an update to mqtt_as which works with this hardware.