I seem to remember the reset button not being enough to turn off the USB side, try a power cycle then repeat the tests? I’ll admit to never delving deeply into the power consumption side, but others on this forum have and there are threads about it (you’re not using Vext but maybe turning it off is a good defensive measure too, as one example).
That 11mA might be the cost of the delay() CPU burn loop…last time I looked there was some yield()'s in the implementation but it was a busy-loop (rather than sleeping). Alternatively, wow, those GPIOs are supplying a lot of current. Maybe the pull-up resistors didn’t engage? You can double-check/ensure they are by
digitalWrite(pin, HIGH); to them.
I’ve expanded your code a little, but not tested it at all (!!), here. The main change is to remove the delay(), I’m impressed the stack continues ~working with the delays you had in there, some background processing continues but I’m unclear if it stays healthy - it’s much better to let loop() complete ASAP. It should send packets on both open & close if they’re more than a minute apart.
As you saw on the TTN thread, retransmitting while the radio is in use won’t work, and in fact I think you should reconsider transmitting on each open & close. I put some code in there to limit to a max of one send per minute, it may even be better (but more complicated) to log the open and then after n(60?) seconds transmit the current state - you would effectively send one packet with “it opened and then closed/stayed open” type of information. Doing it like that accounts for things like wind with a half-open door flickering open/closed over and over. That’ll burn through your battery quickly.
Anyway, my code is just another way of extending it and I’m not 100% sure I got the open/close state the right way around, and almost certainly didn’t get the door vs mailslot GPIOs correct. It was a fun distraction on a Sunday night though.
Keep going, you’re almost there.