Fixes related to specific uPython ESP32 versions

General discussions and questions abound development of code with MicroPython that is not hardware specific.
Target audience: MicroPython Users.
Post Reply
DWIM
Posts: 3
Joined: Sun Aug 25, 2019 10:25 am

Fixes related to specific uPython ESP32 versions

Post by DWIM » Tue Oct 08, 2019 10:38 am

Have been using MicroPython v 1.9.4 bin & v 1.11 187 & 312 bins. My environment: Have several Temp & Humidity sensors (DS18b20, HTU21D, AM2315 types), ssd1306 type display, blinkM LED. All good. Adding ESP32 Huzzah into network of other (prior builds) using Rasp 3s & ZeroWs, all being coalesced in an Ubuntu 17 box via MQTT (3.11). Data stored in mySQL DB on other U box (~40m rows so far). All Python on ESP32, GoLang & Python on other boxes. Using anonymous MQTT (so no un/pw) via std default MQTT port. All Pub only on Rasps; Subscr only on U box. Can MQTT fr ESP32 to public test platforms (e.g., mosquitto's test platform + others) when testing a standalone ESP32; that's fine. Tried Simple & Robust. Keep getting Connect failure at socket connection. Have sourced serial connection fr ESP32 to host via Windows 10, Mac OS 10.13.6, & Ubuntu 17 & 18. WiFi connection good (to my closed NW). By 'closed' I mean not Internet accessible. Since integrating ESP32s into existing, I need to continue no un/pw q=0 process in this closed NW. Have not tried anyncio approach (yet).By 'Connect failure' I mean w/in Simple, the socket connect call always fails. But works to outside test platforms. Simple MQTT Subscr test fr ESP32 looking at ZeroW's Pub messages is fine; I can echo rcvd msgs onto console. Msgs all <= 100 chars or so. No firewall rules in place for default MQTT port. WiFi connection fine. Have also tried simple DNS lookups w/in NW fr ESP32; all get IPs fine. Have tried both named machines & only IPs; both connect fail.

So need some help. Can use my W10 box w/COM3 connection via Putty for test. Simple Pub any junk topic & msg fr ESP32 to Sub on W10 box. W10 Python script minimal. ESP32 uP script minimal. Both just for testing. Didn't post my simple python code (Pub & Subscr sides) since first time poster here & it's just like open & available. Since I've tried 1.94 version & multiple 1.11 versions, was wanting to see if MQTT or other fixes might be the problem. Or just my 'dumbness'. Thanks for being patient.

User avatar
pythoncoder
Posts: 3607
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: Fixes related to specific uPython ESP32 versions

Post by pythoncoder » Wed Oct 09, 2019 6:55 am

This is hard to diagnose remotely as your setup sounds complex. The code for umqtt is stable and there are no known issues relating to any recent firmware build. Many people are using umqtt and I don't recall any issues with connect(). I recommend using the latest code throughout.

I'd work on the assumption that the problem is in your network. Set up a test broker using mosquitto on a PC or Raspberry Pi and run the umqtt test scripts to try to figure out where the fault lies. Run mosquitto_sub and mosquitto_pub on the PC to prove communication with the target. It should be straightforward.
Peter Hinch

DWIM
Posts: 3
Joined: Sun Aug 25, 2019 10:25 am

Re: Fixes related to specific uPython ESP32 versions

Post by DWIM » Fri Oct 11, 2019 4:06 pm

I know it's been a few days; given you're replying, I wanted to ensure I'm doing tests in a controlled environment. so..
- Using Micropython version: MicroPython v1.11-417-g79ab82ea7 (esp32-20191010-v1.11-417-g79ab82ea7.bin)
- Using boot.py & config.py below.
- Trying a simple subscribe on the ESP32 (main.py is below) to one of the RPIs (rpiz-6) using mqtt to publish
active data. Works fine; gets 8 msgs, prints them out as they come in, then disconnects MQTT connection.
- Trying a simple publish using a local version of simple.py (has added prints to help diagnose).
Had to add set_last_will before connect (since connect requires it but Internet test prog didn't have it).
- Trying simple publish to test.mosquitto.org using boot, config, & (slightly modified, above) simple.
Works fine; send 8 msgs of the type & format for a given sensor I use everywhere. Sent to test.mosquitto.org.
Rtn fr client.publish = None for every call. Also ran (in a separate DOS window) a mosquitto-sub to test..org
to verify all sent msgs reflected back to my W10 box; all back correctly.
- Next test is ESP32 sub to local W10 box. Verified IP of W10 is 10.0.1.116. So using same simple publish main
EXCEPT for replacing host with this IP.
-- Used Windows Defender Firewall with Advanced Security to verify TCP port 1883 is open incoming & outgoing.
Using Sophos UTM 9 as my basic (software-based) router (have been for at least a few years). I can see there
The logging of from & to IPs on port 1883 for .116 & .211 (I don’t log data details).
-- Tried (fr w10 DOS prompt): mosquitto_sub -h 10.0.1.211 -t DC/Sensor
Got: Error: No connection could be made because the target machine actively refused it. This is the problem
I’ve had, despite what I’ve tried above.
Also tried machine name both with & without full FQDN; same error.
-- Used W10 DOS ping to verify I could see the IP; ICMP packets go thru ok (i.e., ping results ok).
- Note: I have NOT posted the py sources since I'm not sure where to place them (even though I refer them as 'below'). By that, I mean I have a detailed document detailing what's above (an RTF) w/in which i DO have all source.
- Do date, while I DID snap a copy of umqtt's simple.py & inserted prints to I could track where it fails, I haven't done so yet for socket. That's prolly next.
- I've tried a mosquitto_sub from a couple of MACs & a couple of Ubuntu boxes as well as the W10; they all the ESP32 target refusing. That's why I finally decided to post here; I'd guess I'm prolly not setting up my WiFi correctly or doing the mqtt setup correctly. WiFi seems less probably the culprit since testing documented above passes ('cept for only case I need which is a pub to my internal Ubuntu 17.10 box).
- FYI, the relevant code snippets in main.py are (DC.now() returns a UTC-based formatted string):
...
from simple import MQTTClient
...
host = b'10.0.1.116'
port = 1883
retain = False
topic = "DC/Sensor"
data = "ESP32-1\tHTU21D\t2019-09-14\t10:13:04\tH(P)\t40.16\tT(C,F)\t24.76\t76.57"

client = MQTTClient(id,host,port=port)
client.set_last_will(topic, "last will")
connectRtn = client.connect()
print('connect:',connectRtn)

def go():
publishRtn = client.publish(topic,data,retain=retain)
if (publishRtn != None):
print('publish:',publishRtn)
...
iterationCount = 0
iterationCountMax = 8
while iterationCount < iterationCountMax:
iterationCount = iterationCount+1
printf('%d of %d (%s): Publish to [%s] Topic[%s]: [%s]', iterationCount, iterationCountMax, DC.nowUTC(), host, topic, data)
go()
utime.sleep(5)
disconnectRtn = client.disconnect()
print('disconnect:',disconnectRtn);

DWIM
Posts: 3
Joined: Sun Aug 25, 2019 10:25 am

Re: Fixes related to specific uPython ESP32 versions

Post by DWIM » Fri Oct 11, 2019 11:21 pm

Sorry. One other thing: I am intending to drill down into usocket, mostly adding more diagnostics to determine where my 'problem' is. So, given I'm using MicroPython v1.11-417, where might I pull a source copy. I did a cursory look in https://github.com/micropython/micropython but didn't see it. So I thought it better to ask (so I'm using what I should use). TIA. I'll report back once I see what's up. One of my little discoveries I've already seen is the umqtt/simple module requires a non-None last will; don't know what else I'll find, but I certainly didn't see that requirement in many of the sample MQTT code samples I tried. Again, TIA.

User avatar
pythoncoder
Posts: 3607
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: Fixes related to specific uPython ESP32 versions

Post by pythoncoder » Sun Oct 13, 2019 7:52 am

If I'm reading this right your problem may have nothing to do with MicroPython.

I would establish whether you have MQTT connectivity by using mosquitto, mosquitto_pub and mosquitto_sub on PC's - ideally including a WiFi connected one. Although I agree with your doubts that your problem is with WiFi. It sounds like an issue with security software or network security settings. A topic well above my pay grade ;)
Peter Hinch

Post Reply