I just tried the same process on my side. It worked fine.
I've opened the Pycom firmware updater and pasted the activation token.
Then firmware updater wrote the Pybytes device config to a device and updated the firmware.
Then the device restarted and was connected to Pybytes. The last connection time was updated.
I tried pymakr and I can evaluate expression in REPL
rst:0x1 (POWERON_RESET),boot:0x12 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
mode:DIO, clock div:1
Initialized watchdog for WiFi and LTE connection with timeout 1260000 ms
WiFi connection established
Pybytes connected successfully (using the built-in pybytes library)
Pybytes configuration read from /flash/pybytes_config.json
Pycom MicroPython 1.20.1.r2 [v1.11-06dfad0] on 2019-11-30; FiPy with ESP32
Pybytes Version: 1.3.0
Type "help()" for more information.
It's strange that it is not working for you.
Can you to change the Wifi network in your device profile and then try to provision it again?
Also, enable debugging, maybe you spot something there
import pycom; pycom.nvs_set('pybytes_debug', 6)
You can also try to completely erase a device with erase_all command
Beware that after doing erase_all device will not boot up properly until you the flash firmware (doing the firmware update with firmware updater)
Im using the latest version of Pysense, i realized that using any of the sleep functions even just setting up sleep would break the CLI. I manually changed the memory address for the sleep reason to 1. It was working as i would expect. After powering it up a day later the memory address for the sleep reason is back to 12.
A correction to what I wrote previously: I found that lte.deinit(detach=False, reset=False) followed by a deepsleep does not do what it is supposed to do: power consumption during deepsleep still varies between 27-90mA instead of the typical deepsleep power consumption of 22µA. This is not is line with the statement "lte.deinit(dettach=False) allows the modem to go into power saving mode (PSM, eDRX) without dettaching from the network." as posted here: New LTE Firmware release v1.18.1.r3 & CAT-M1 firmware. So the only thing that works for me is ending with lte.deinit(). If that is done, no reset is needed at the start of the next cycle, and re-connection is established reliably. But it takes time (with the lte.attach(... step taking typically 10s, and the total cycle (lte.init, lte.attach, lte.connect, lte.disconnect, lte.deinit, deepsleep) taking about 20-24s.
Am I correct that this means that it is not yet possible to switch off the modem completely during deepsleep without detaching from the network (PSM)? Or who managed to do this? How?
@CoachAllen As I learned from this site - it is because of the last bit (0 for reading and 1 for writing). I recommend to find that post - just search for "i2c address" or similar... To confirm that post conclusion I ran i2c.scan() and it gave me the slave address , meaning 0x42 and that's what I used for reading...
So it turns out, after messaging with Robert, that PyBytes was the culprit, apparently if not using it and trying to start your own WiFi connection, it'll possibly conflict with the connection that PyBytes tries to make even if not using it?
Why is this not mentioned in the docs? Or did I miss anything?
And, why doesn't the WiFi somehow disable when PyBytes is not used?
Anyway, thought I'd leave that info here for others who may also run into this same issue.
The weird thing is, I'm trying this code now on a WiPy too, both that and the Lopy have the latest firmware as of writing this. 1.20.1.r2.
wlan.ssid() doesn't return anything, even if I set it and then check it again...
in case you are still in need in CoAP implementation in micropython, we have created a minimal port that we internally use.
It is open-source and is available here: https://github.com/insighio/microCoAPy
Any comments are welcomed.
@handloomweaver It looks OK. What happens if you bridge RX/TX at the RS232 side. Then at least you can check that the data is passing through the Level converter. Then, the modem control lines could be the problem.
I've discovered that lte.attach() sets CFUN=1 and that subsequent AT+CFUN=1 commands cause the SYSSTART to occur.
Allowing the lte.attach() function to set CFUN to 1 seems to have cleared up the "spurious" restart issue.
I still cannot get the modem to attach, however. Any help is appreciated.
This problem does not occur when we use the LoPy-1.18.2.r7 firmware. Whereas the LoPy-1.20.0.rc13 doesn't run fine. The problem appear when the lopy run since a minimum of one day, and come when the LORA module was use (send or receive).
Don't care about power right now. I like to see version chaos for the pytrack as well. Why do they only improve the expansion board and don't place a better antenna and a plug on the pytrack? And a battery plug which is more common in my area?
Version chaos now!
And a wiki in which user can keep the documentation/examples in snyc with the firmware. Yes, it is a risk, but Pycom seems to small for keeping the documentation actual - and the forum is not the best place for user collected best practice and workarounds.