I think Diederik does not want to transmit more often*, but just wants to sleep more?
But indeed, it seems that the EV_TXCOMPLETE not only takes receive windows into account, but also duty cycles†, and then keeps the device awake. But even then, 20-30 seconds seems far too long for about 21 bytes to send something like T:12.34H:12.34B:12.34 on SF7, where a 1% duty cycle yields something like 7 seconds waiting time after sending?
Or are the float values much longer than 12.34, @DiederikRhee?
* Even though the current sleep of 64 seconds seems very low for temperature readings, and yields a daily air time far above the TTN Fair Access Policy when sending 20+ bytes. So yes, send less often, and send binary, like already suggested.
† While, officially, a different frequency could be used for the next transmission much sooner?