Coming back to this again after quite a bit of testing, I have now managed to identify a somewhat more reproducible way of causing resets on T-beams v1.0 over the air.
A single node running 1.2.30 with one encrypted channel can sit without resets permanently (I tested 23+h without a single reset)
With four nodes on the mesh, all flashed with 1.2.30, I see a reset every ~24 min or so (based on about 25 resets in 10h). These occur even if no messages are actively sent. On the two nodes that have a screen I can see that they often reset almost simultaneously.
I’ve tested this with the nodes nodes connected via bluetooth and not, with and without admin channels enabled.
The most reproducible way has been to have a remote node with an admin channel enabled. A reset is triggered in the remote node when meshtastic —debug is sent to a USB connected node. (one might have to wait a couple of minutes if the remote device is sleeping).
I am unable to reproducibly induce this behaviour if the remote node does not have an admin channel enabled.
I therefore thought the resets occur only if the admin channel is enabled on the remote node, but after reflashing and only activating the primary channel in all nodes, two nodes nevertheless still reset after a few minutes (even without meshtastic —debug) just as I was writing this (both without USB connection, externally powered nodes don’t seem to reset).
It seems whatever is sent periodically in the mesh without user interaction might also be sent when running meshtastic —debug, and that this can cause the resets.
Can anybody else reproduce this? As mentioned previously, I cannot seem reproduce this if the nodes are powered.