@martinnn Found the issue with your firmware updater. If you would want to update to a dev version, you need to download the development version of the firmware updater (here). They will release it as stable soon, but not until then, use this dev version.

@jpaul Good to hear. Our tutorials don't cover auto-connect very well yet, we'll work on that!

@changeddaily Good to hear. Yes I agree, our documentation could definitely use an update.

Thank you @paul-thornton, I just saw the addition to the web page with the mechanicals. I'll start drawing my board ;)

Last few days: 2 of 6 dead with power only connection, also 2 of 6 dead with USB. So my previous assumption that the crashes are related to the USB cable doesn't hold. I have to say if this wouldn't be a simple pretty stateless (serial in, MQTT out) sensor application (where I don't mind the sledgehammer approach of an external watchdog reboot), I'd be getting nervous by now and having second thoughts whether these boards were the right choice.

@paul-thornton I seem to get the notification now, but I'm guessing it's the mentions specifically, since I turned on the "replies in topics you watch". I'm pretty sure it's not browser related since it's not in the notifications view, but I'm using google chrome Version 71.0.3578.98 I'm guessing you get the notifications because of the reply and you're watching the topic, not because of the mention. I'm going to put mentions on emails only and replies on notifications. That should send me an email when I get mentioned and a notification because there's a reply if you reply to this topic.

@nervencid With autoconnect to false, it indeed tries to connect to the address 192.168.4.1, so the output you posted is as expected. To connect you can either: connect to the devices wifi and klik connect again, or: change the auto_connect setting to true, or: set the address setting to the correct comport (you can find it using the 'list serialports' command)

when you click run just the single file your editing it sent to the board its literally as if you typed each line into the Repl. this is fine if its just your main.py script. but when libs need updating they dont get sent as you have discovered. The reason for the reset being required is to force micropython to reload its previously loaded and cached copies of libraries There are work arounds for hot reloading code, but its way easier to just reset the board during development

@graham said in lora.join does not attempt every 15 seconds in background: while not lora.has_joined(): pass I would add something like sleep(1) into the loop, giving the background tasks more time.

@gmedlicott it's not True by default, because older firmware doesn't support it. We have documentation for pymakr settings here

@shp96 That does not seem correct. Your gateway is only listening on channels 48 to 55 and 70... Can you show logs of packets received with the associated channel?

Thanks heaps @dan Its working fine for me now on VSCode 1.27.2 :-)

Hi @John-Baird I hope you (and I) find a satisfying environment to work with these devices. Another project I've come across since then is balena (which used to be called resin) https://www.balena.io/ It's a very cool project, with almost everything open source and which can be self hosted. I talked about my use case on their forum https://forums.balena.io/t/edge-node-manager-for-wipy-micropython/2549 and someone replied with this https://github.com/Bucknalla/resin-pycom-ota project which I haven't had the time yet to try out. The idea is that you have a device that acts as and "edge manager", that device runs balena and whenever you upload new code (git commit & push) the edge device will update your pycom devices.

@dan Yep I have never put anything in boot.py, have always had main.py run without intervention.

@alvaroav Good to hear it's solved. I'm still not sure if it's another plugin, because another user had this and it was gone after a window reload. Might be some edge case in button usage.

@catalin I finally managed to perform tests of releases between 1.14.0.b1 and 1.18.0.b1. Otii ARK traces are available here: https://drive.google.com/open?id=1kIZL0HJHn_dEIPDM_jv6fEhDhb_Ukfqj Significant execution time increase occured between versions: 1.17.0.b1: MP: d0dc708a0197d2900a5620648725794a1fb5c8f3 IDF: 3b54cd7473aefdb8b75531a21ce340c4bd2221da and 1.17.2.b1: MP: 1bf377b08e2162e8534b6cbe78dcdeeb930f64b8 IDF: 4eab4e1b0e47c73b858c6b29d357f3d30a69c074

@dan, how did you fix this problem? Would you please post the code on both devices that you used? I am running in to the same issue. Thanks