New firmware release, version 1.6.0.b1
i can confirm that problem was not with wifi
pin.value()mentioned by you
i also fix my software to prevent such situation like None returned instead of value (maybe never happen again but...)
None value was send by wipy by wifi and i automatically drop connection on server side because of wrong packets sended and i then i see
OSError: [Errno 104] ECONNRESETwhich was ok
now after your fixes may software work back ok
@Pete you can test now - it looks promising :)
after few minutes of testing i see only one thing not work
but all others are fixed - i see if it will be working tomorrow through night :)
@daniel can you test my sample from post below with getNTPTime
it still doesn't work
daniel last edited by
Apologies for the bugs introduced on the latest release. There were 2:
- pin.value() was not working correctly for OPEN_DRAIN pins, and this broke the one-wire library.
- Bluetooth callbacks were not being called for characteristic read/write events.
Both are fixed now. We just published firmware 1.6.1.b1 with the following changes:
- esp32/mods/modbt.c: Protect against writing chars value over 20 bytes long.
- esp32/util: Increase callbacks stack size to 5K.
- tools: Make the certification script compatible with US915 too.
- esp32/mods/modbt.c: Mark the is_char field as true on characteristics.
This ensures that the read and write callbacks are actually called.
- esp32/mods: Fix bug introduced when reading the value of an output pin.
Simply run the updater tool again and the new firmware will be flashed on your boards.
Pete last edited by
My patience is now wearing very thin and I am now forced to consider switching to another platform, because as far as I can tell, the issues preventing me from using these devices in a real live environment are still many, many months away.
I know what you mean. I bought WiPys because I need to quickly simulate a large piece of equipment we won't have our hands on for a couple of months. I had been waiting for some specs from its supplier before I got stuck into implementation (just received them this morning), but the few things I tried already and many of the posts I'm reading have me worried that the WiPy won't be stable during our tests in the field, when we'll be relying on it working all day while we debug our actual product and can't easily do resets and suchlike on the WiPy.
If it had been advertised as an alpha/beta product I'd have approached it differently, keeping an eye on it as an interesting future possibility but not building our test plan on it.
Fortunately I'm sufficiently cynical as to have also ordered a different brand of WiFi IoT module as a backup. This one runs a full Linux which is more complexity than I really wanted (serial -> Python -> UDP-over-Wifi and nothing more, as promised by the WiPy, was ideal) but at this point I'm rather glad I have them on the shelf as well.
I'm going to stick with WiPy for now in case our simple use-case happens to dodge round all the bugs, but posts like Livius's on this thread saying that WiFi station mode (which is what we need to use) is not stable, are not encouraging.
I still have objection to pycom did not you inform on your website which is already implemented and what still needs to be improved before buying.
As I have once wrote - people will buy your product but do not expect that everything is fine and dandy and beautifully.
as you can see that another criticise post from new user @crankshaft.
Informing that the device consumes this much power in a deep sleep, or so and so enabled wifi it seems to me also pure guesswork until deep sleep mode will not be available. You can indicate that the promises esp so be it.
Additional - issue tracker - github is not very good for that - could you use something like jira -
e.g. Firebird use free version of it
but summarize this
i believe in pycom team i see many, many progress but without first point you loose more and more.
livius last edited by
unable to run the onewire / ds1820b code any longer
you point me in direction to dig first why my working code in 1.5.0 not work in current firmware
i suppose that
OSError: [Errno 104] ECONNRESETis because i got
Nonefrom onewire instead of value - but i can check this in the evening
crankshaft last edited by crankshaft
@daniel - I realise that this is similar to another post I made a few weeks ago, but I feel I need to vent this again.
For IOT, I committed to PYCOM about a month ago and purchased a handful of wipy2 / lopy devices, based on the understanding that the following advertised features which are essenital (and very attractive) were available right now and were not 'planned specs' that would be available 'some time in the future':
- 14ma with WIFI enabled
- Dual Core
- Threading & Interrupts
However it is now clear that this is not the case, that many are only partially working, what is working is not very stable, and that PYCOM devices are most certainly not ready for any production environment by a long way.
Unhandled Guru mediation crashes, unresponsive and dead sockets and intermittent wifi connections alone are a problem, but when you have all of them together, it is just too much, and it does seem that fixes or for these are a lesser priority than releasing new hardware ?!
It is extremely frustrating when I am eagerly waiting and expecting the next release to address problems that I have so that I can move forward only to discover that effort has only been focused on releasing things line new hardware (sipy) and new IDE plugins rather than addressing the existing problems.
It's quite clear that the team are overloaded with too many things to do and the pressure or desire to release new hardware is resulting in users such as myself who just want to use a turbo-charged WIFI enabled IOT device having to wait for all the other new bells and whistles to be completed first, and the device to become production ready, which my gut feeling tells me is probably 6 months away.
Low battery power, reliable wifi and bullet proof firmware are absolutely fundamental to a IOT micro-controller, and I would really like to know if there is any user anywhere in the world that is actually using a WIPY2 device in a real live project ??
My patience is now wearing very thin and reluctantly I am now forced to consider switching to another platform, because as far as I can tell, fixes for the issues preventing me from using these devices in a real live environment are still many, many months away.
I just noticed a new web page with several new hardware announcements, I guess this means that effort is going to be further diverted into developing the firmware for these new boards making the current situation even worse :-(
crankshaft last edited by crankshaft
@daniel - just updated, now the project that i've been working on for the last month is broken, have not had chance to troubleshoot yet but it is unable to run the onewire / ds1820b code any longer :-(
Also, does this update address the posts that nobody has responded to regarding guru mediation crashes and the instability of the threads, interrupts and sockets as these are driving me crazy ?
What is the parameter you added mentioned here "Add parameter to enable/disable WLAN power save mode."
Can we please get a proper bug reporting / tracking system in place as I am getting very frustrated with issues that are show stoppers for me and that nobody seems interested in responding to or addressing ?
PCA last edited by
@daniel good job ! Bluetooth stack seems in progress : my Lopy with GATTService is now visible with Bluegiga debug tools and read/write characteristics works.
BUT the read characteristic callback never fires (worked in 1.5.1-b1)
i have minimized code but it work without sensors and do not raise OSError
i will try extending it step by step but it take time
whole code work ok without any change in 1.5.0
in the meantime you can test another issue
test this to see what happened inside
code never finished and never bring error
file ntest.py - i execute it as
print('start') import machine import socket from socket import AF_INET, SOCK_DGRAM from machine import RTC from network import WLAN print('def') def getNTPTime(host = "pool.ntp.org"): port = 123 buf = 1024 address = socket.getaddrinfo(host, port)[-1] msg = '\x1b' + 47 * '\0' msg = msg.encode() TIME1970 = 2208988800 # 1970-01-01 00:00:00 # connect to server client = socket.socket(AF_INET, SOCK_DGRAM) client.sendto(msg, address) msg, address = client.recvfrom(buf) t = ustruct.unpack("!12I", msg) t -= TIME1970 tuple_time = utime.localtime(t) rtc.init((tuple_time)) client.close() print('adef') wlan = WLAN(mode=WLAN.STA) nets = wlan.scan() #time.sleep_ms(100) for net in nets: print(str(net.ssid)) if not wlan.isconnected(): wlan.ifconfig(config=('192.168.1.110', '255.255.255.0', '192.168.1.1', '192.168.1.1')) wlan.connect('livius', auth=(WLAN.WPA2, 'secretpass'), timeout=5000) while not wlan.isconnected(): machine.idle() #time.sleep_ms(10) #pass #machine.idle() # save power while waiting print('WLAN connection to the router succeeded!') rtc = RTC() print(rtc.now()) getNTPTime() print(rtc.now())
daniel last edited by
@livius can you share a minimal code example that reproduces your problem? Thanks!
faster wifi connection(join) and faster connect
AP mode is really stable - but not STA
OSError: [Errno 104] ECONNRESET:(
rst:0x1 (POWERON_RESET),boot:0x3b (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0x00 clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:QIO, clock div:2 load:0x3fff9010,len:8 load:0x3fff9018,len:248 load:0x40078000,len:4056 load:0x4009fc00,len:920 entry 0x4009fde4 I (2307) wifi: frc2_timer_task_hdl:3ffd4a00, prio:22, stack:2048 I (2312) wifi: Init lldesc rx mblock:10 I (2312) wifi: Init lldesc rx ampdu len mblock:7 I (2312) wifi: Init lldesc rx ampdu entry mblock:4 I (2315) wifi: pp_task_hdl : 3ffdbb3c, prio:23, stack:8192 I (2320) wifi: sleep disable I (3309) wifi: mode : softAP (24:0a:c4:00:6e:c3) 16.09167 102101.2 133.7686 wifi_sta I (4058) wifi: sleep disable I (4059) wifi: mode : sta (24:0a:c4:00:6e:c2) livius UPC77A39D9 TP-LINK_9A6D1E UPC Wi-Free UPC Wi-Free UPC0838976 2.4G-vnet-1C0A58 DIRECT-y6-BRAVIA UPC248017814 2.4G-Vectra-WiFi-B7C11C keke UPC8578324 vnet-A6EA06 UPC Wi-Free vnet-EC0D8E 2.4G-vnet-08CC4C UPC1334070 Dobra Jama UPC Wi-Free vnet-35A54A UPC Wi-Free XY UPCB243C94 UPC7321003 I (7611) wifi: n:9 2, o:6 0, ap:255 255, sta:9 2, prof:6 I (8599) wifi: state: init -> auth (b0) I (8601) wifi: state: auth -> assoc (0) I (8607) wifi: state: assoc -> run (10) I (8623) wifi: connected with livius, channel 9 WLAN connection to the router succeeded! (1970, 1, 1, 0, 0, 6, 425460, None) (1970, 1, 1, 0, 0, 6, 426040, None) connected to socket [UID=24:0a:c4:00:6e:c2] None, 1, 35, 10 Traceback (most recent call last): File "main.py", line 14, in <module> File "wifi_sta_router.py", line 159, in <module> OSError: [Errno 104] ECONNRESET MicroPython v1.8.6-442-gccd949ca on 2017-02-14; WiPy with ESP32 Type "help()" for more information. >>> I (18608) wifi: pm start, type:0
and problem with ntp - try e.g.:
from socket import AF_INET, SOCK_DGRAM from machine import RTC def getNTPTime(host = "pool.ntp.org"): port = 123 buf = 1024 address = socket.getaddrinfo(host, port)[-1] msg = '\x1b' + 47 * '\0' msg = msg.encode() TIME1970 = 2208988800 # 1970-01-01 00:00:00 # connect to server client = socket.socket(AF_INET, SOCK_DGRAM) client.sendto(msg, address) msg, address = client.recvfrom(buf) t = ustruct.unpack("!12I", msg) t -= TIME1970 tuple_time = utime.localtime(t) rtc.init((tuple_time)) client.close() rtc = RTC() print(rtc.now()) getNTPTime() print(rtc.now())
it never print second line :(
no error no print
Pete last edited by
Thanks guys - fixes to WiFi stability sound very welcome :-)