I think I finally found an answer on how to properly reset the modem in case it just won't attach to a network. Reset the modem by sending following AT-command: lte.send_at_cmd('AT+SQNSFACTORYRESET=?') Unlike lte.factory_reset() - which seems to use AT-command AT+SQNSFACTORYRESET - this command will successfully reset the modem to factory state. A reboot of the device is necessary to finalize the reset! After this process the modem should attach to the network without any issues! Also, for further information see: AT Commands Reference Manual, 15.1 Device Reset to Factory State

I continue to wait patiently for Pycom to support its product it sold me.

@naveen I paid EUR 2.90 for the return postage.

@project2501 Ill see what I can find out.

@robert-hh Thank you. I missed that update.

@paul-thornton Thanks for the response and information to this important thread. Just to let you know, the blocking and unstable lte.init()/deinit() behavior is forcing me to consider totally switching platforms, and abandoning Pycom. I am running the newest modem firmware.

@wghirakawa The code seems to be ok. I don't have access to Cat M1 network (only NB-IoT available here) so I cannot test with the same Sequans firmware. Are you able to perform communication on the same APN and with the same SIM using different hardware? @iwahdan could you please take a look?

Will messages be stored temporarily, until a PyGo has contacted another node for a certain amout of time and then hop the stored message? Thinking of eg. communication net between busses or so.

@dan An empty string is returned in cases, when the LTE modem takes longer than 10 seconds to respond. Sending an empty AT command (lte.send_at_command('')) may show such a late resonse.

Entlich mal. I've got connection. Got finally a new SIM from KPN and it worked immediately . Thanks all for the encouraging words:-) Now I can start my project. Keep you posted.

@reidfo Sure looks like it. Change line 294, see if you get a different behavior. http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Toc385349238 https://github.com/pycom/pycom-micropython-sigfox/blob/f517b1df5083ddc158c075852d7f2497480b0d84/esp32/frozen/Common/MQTTClient.py#L294

Hi @tanmay07, Could you check the firmware version of the devices? (os.uname()) What code are you running on them? Are you using WiFi, Bluetooth, or LTE?

Hi @sh4nnongoh, Please check this post for updates about the modem upgrades. Hope this helps!

@ahmedach At the moment we offer the Smaller IP67 Case for Pysense/Pytrack. We are looking at options for a universal IP67 case but don’t yet have any committed timelines for this. The earliest we could deliver this would be late Autumn but there’s a good chance it will be pushed into next year

Dear @tanmay07 and @Martinnn, if you feel lucky, you might want to try our custom build just released on [1]. More background about this is available through [2]. Please be aware that when upgrading from a lower firmware version to this custom build based on 1.20.1.r1, you will have to erase your device completely before flashing in order to keep things straight. You will find respective references to this on the forum. Hint: Use pycom-fwtool-cli --port /dev/ttyUSB0 erase_all, see also [3]. With kind regards, Andreas. [1a] https://packages.hiveeyes.org/hiveeyes/foss/pycom/vanilla/GPy-1.20.1.r1-0.6.0-vanilla-dragonfly.tar.gz [1b] https://packages.hiveeyes.org/hiveeyes/foss/pycom/vanilla/FiPy-1.20.1.r1-0.6.0-vanilla-dragonfly.tar.gz [2] https://community.hiveeyes.org/t/investigating-random-core-panics-on-pycom-esp32-devices/2480 [3] https://community.hiveeyes.org/t/installing-the-recent-pycom-firmware-1-20-1-r1-requires-erasing-the-flash-memory-completely/2688