picoweb error when client connect

All ESP32 boards running MicroPython.
Target audience: MicroPython users with an ESP32 board.
Post Reply
amirfh
Posts: 2
Joined: Sun Nov 18, 2018 10:34 pm

picoweb error when client connect

Post by amirfh » Mon Feb 25, 2019 9:59 am

need help pls :

INFO:picoweb:30.000 <HTTPRequest object at 3ffc3590> <StreamWriter <socket>> "GET /"
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<string>", line 903, in <module>
File "/lib/picoweb/__init__.py", line 298, in run
File "/lib/uasyncio/core.py", line 161, in run_forever
File "/lib/uasyncio/core.py", line 136, in run_forever
File "/lib/uasyncio/__init__.py", line 60, in remove_writer
TypeError: function takes 2 positional arguments but 3 were given

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

Re: picoweb error when client connect

Post by pythoncoder » Mon Feb 25, 2019 10:26 am

I think you have mismatched versions of firmware and uasyncio. If you are running the official firmware, the version of uasyncio on PyPi will not run. You need to replace __init__.py and core.py in the uasyncio directory with those from the official micropython-lib.

The code on PyPi is only guaranteed to work with Paul Sokolovsky's fork of the firmware.
Peter Hinch

GHPS
Posts: 2
Joined: Thu Mar 14, 2019 8:21 pm

Re: picoweb error when client connect

Post by GHPS » Thu Mar 14, 2019 8:36 pm

>I think you have mismatched versions of firmware

You perfectly nailed it - as always.

Now it's easy to get picoweb working again - just copy the two files

https://github.com/micropython/micropyt ... _init__.py
https://github.com/micropython/micropyt ... io/core.py

to /lib/uasyncio

>The code on PyPi is only guaranteed to work

The most important messages were en passant:
1) There is a difference between pypi and the github repo.
The upip installer will _not_ take the github version.
2) Just recently there was a split in the micropython community.
Last edited by GHPS on Sat Sep 21, 2019 2:12 pm, edited 1 time in total.

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

Re: picoweb error when client connect

Post by pythoncoder » Sat Mar 16, 2019 7:27 am

It is very unfortunate and causes a lot of needless confusion. @Damien has a solution but hasn't yet pushed it to the MicroPython repo.
Peter Hinch

GHPS
Posts: 2
Joined: Thu Mar 14, 2019 8:21 pm

Re: picoweb error when client connect

Post by GHPS » Sat Sep 21, 2019 2:10 pm

pythoncoder wrote:
Sat Mar 16, 2019 7:27 am
It is very unfortunate and causes a lot of needless confusion.
Just an update on this increasingly unpleasant situation:

1) First of all thanks for your great tutorial on this subject!

https://github.com/peterhinch/micropyth ... PICOWEB.md

2) I just tested the latest version of picoweb and got a new error

Code: Select all

AttributeError: 'StreamWriter' object has no attribute 'awritestr'
thrown by __init__.py and caused by this commit [1]. The function
was implemented at the same time in uasyncio [2].

Copying the changes to asyncio/__init__.py fixes the problem:

Code: Select all

def awritestr(self, s):
        yield from self.awrite(s.encode())
Seemingly picoweb is now closely tied to pfalcon's uasyncio which
again is tied to pfalcon's version of MicroPython.

MicroPython is becoming a number of walled gardens with
incompatible applications (picoweb in pycopy), protocol drivers
(asyncio again pycopy) or device drivers (displayio, busio in
CircuitPython).

Just like in closed source every owner of the garden in trying to
lock-in his users and get ahead towards domination of the
community.

1: https://github.com/pfalcon/picoweb/comm ... c71b89cdab
2: https://github.com/pfalcon/pycopy-lib/c ... 9e4bf4b57e

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

Re: picoweb error when client connect

Post by pythoncoder » Sun Sep 22, 2019 9:36 am

Thanks for that very useful work. It was on my to-do list.

Looking at the code, clearly Paul could have performed the encode() in Picoweb avoiding the need for changes to uasyncio. My guess is that he is anticipating future changes to uasyncio which will be more RAM-efficient. Support for unicode is clearly beneficial.

People can use the old copy in my repo which lacks Unicode support. To provide this, rather than modifying uasyncio, they could adapt picoweb/__init__.py:

Code: Select all

    def render_template(self, writer, tmpl_name, args=()):
        tmpl = self._load_template(tmpl_name)
        for s in tmpl(*args):
            yield from writer.awrite(s.encode())  # Change here
It is evident that Picoweb is diverging such that it requires Pycopy, just as Paul's original version of uasyncio has. I maintain a uasyncio fork which fixes various issues and works with official firmware, but I have no plans to do the same for Picoweb. It's not my field. It would be great if someone suitably experienced took this on.

As for the forks I appreciate why they exist. My interest is in solutions which work with official firmware. To be fair to Adafruit, with their knowledge I've ported drivers for their products to official MicroPython. The motive for their fork is beginner-friendliness rather than lock-in. Their commercial interest is in selling hardware rather than giving away software.
Peter Hinch

User avatar
jimmo
Posts: 646
Joined: Tue Aug 08, 2017 1:57 am
Location: Sydney, Australia

Re: picoweb error when client connect

Post by jimmo » Sun Sep 22, 2019 12:02 pm

For anyone looking for an alternative to picoweb (for the reasons already described in this thread), it might be worth taking a look at https://github.com/miguelgrinberg/microdot It also supports asyncio (yay!). It's basic (by the looks of it possibly not suitable for GHPS, maybe for the OP?), but might be all you need for a lot of use cases.

Another good (although non-async) option is https://github.com/jczic/MicroWebSrv The author is also helpful and responsive on this forum (see e.g. viewtopic.php?f=20&t=6963 ).

Anyway, if the forks are annoying you, then supporting libraries like these two seems like a good option.

Post Reply