Thanks - so connect would work as-is if it just did a CEREG when not going for GSM/LTE?
Good point about the cell changing - it'd def make sense as a method that could be called then. It'd be great if you were able to suggest what might be required.
Odd about power - I've only had any luck running the boards directly off a LiPo, but when that's done it has been file.
Not sure what to suggest there - if it's not advertising it's because it thinks it is connected. It sounds like somewhere along the line Mac OS is probably still maintaining a connection but Web Bluetooth thinks it's lost - and I'm afraid all that code in the middle is very much out of my control.
I know it's not a great solution but I'd say when you're developing and you want an active connection, maybe just don't let your Mac go to sleep?
Could you post a new issue here with the results of running something when gprs.at.debug() has been run right after connect?
AT+QICLOSE=sktnum should be called by Espruino, which I think is what's required: https://github.com/espruino/EspruinoDocs/blob/master/devices/QuectelBG96.js#L37
Or is it the case that Espruino gets a QIURC 'closed' message, but it actually still has to issue a QICLOSE` before the socket can be used again?
I should add that I have an agreement with RAK Wireless where I maintain the build of Espruino for the RAK8211/8212 - but I'm paid quite a small amount per month for that and it doesn't cover supporting RAK's customers. I'll try to help out and take in any changes you might suggest but I can't afford to offer the same level of support that I would to folks that were buying my own boards.
Even so the QICLOSE thing is something I'd really like to get sorted properly as that sounds like something that definitely should have been working from the beginning.
© Espruino, powered by microcosm.
Report a problem