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.

@martinnn My pycom devices is also connected via USB. I will try some scenario using battery connector. Thank you.

The reason I think that is not problem in my case is that error hapends on same line (part) of the code. In case of USB connection error I expect more randomness in error scenario.

I agree. But maybe it's just that your code spends most of the time doing SSL encryption (or wherever your crashes happen) so it's statistical. Or maybe the crypto module is as high quality as the ADC?
A true debugger with "catch unhandled exception" like the Segger J-Link would be nice. I wonder if something like this exists or everyone just does printf debugging? At least it seems possible https://www.esp32.com/viewtopic.php?t=7097

@paul-thornton I have five devices connected to a powered hub with external 5 V 2 A supply. I also have one that is directly connected to a laptop socket. So I'd say all of those should have enough power. All of those crash sooner or later.
Also I have five devices connected to a lab supply at 4.2 V, drawing 0.55 A, so the 2 A of the USB hub should be plenty.
I also unplugged the USB hub from my laptop so that there was no communication from the computer to the devices (just power from the external supply), still fails (today 2 out of 5 dead).
What does the controller (PIC) on the pysense do? Any chance it generates some glitches on supply/reset when connected to USB?

@martinnn What Amperage is the usb power supply your using rated for? I have seen a few situations where at peak power consumption it'll consume out more than a normal old style USB-A socket can put out (this was on an older laptop, however). causing these issues. Would explain why using a LiPo battery with presumably higher max amperage could fix the issues.

@milan I found that my devices (pysense+wipy) work fine when just powered by the battery connector and fail quickly when connected via USB. I also suspected MQTT, HTTPS, SSL first, but in my case it looks more like an issue related to the USB connection.

@oligauc I can't send your my code, sorry. Important thing is that this error occur when pycom is sending data to Azure IoTHub using HTTPS or MQTTS connections. Pycom is connected to WiFi. I'm suspecting that something is wrong with socket connections.

When I'm sending data every minute to server, error appears few times a day. It is tested with 2 devices and 2 different codes. Common thing is socket connection, and that error always appear after that.

@timh May be these methods don't belong in the class, but given they don't have preceding _ one tends to assume they are public and are there to be used.

the disconnect() method in the MSGHandler class is called by disconnect() in the MQTTClient, so any explicit disconnect will end up with sock poll registrations not being cleaned up as per previous post.

However you have a disconnect() method defined in MQTTMsgHandler class which has the following code.
if this is called then _sock is set to None, and will never be deregistered in the createSocketConnection method