Nice, but beware:
-
In general you’ll want OTAA, not ABP, so you need to store the result of the OTAA Join Accept.
-
For Class A devices (the only thing supported by TTN’s community network right now), LMIC needs to await possible downlinks. For an OTAA Join Accept, that is sent after either 5 or 6 seconds; for a regular uplink after 1 or 2 seconds.
So, a command line
ttn-sendwill always run for at least 1 second, and most often 2 seconds as in general no downlink will be sent at all for which LMIC needs to check both RX1 and RX2. Things will be worse when an OTAA join fails, or when using a confirmed uplink and no ACK is received, and LMIC needs to repeat the uplink.Hence, if you want any sensors to be read in the meantime, you’ll need to run multiple processes simultaneously, and take care that at most one instance of
ttn-sendwill run at any time. When adding one’s own code to LMIC instead, then LMIC can do its housekeeping whenever runningos_runloop_once, and sensors can be processed even while awaiting a possible downlink; see also https://www.thethingsnetwork.org/forum/t/how-do-i-run-non-lorawan-code-in-lmic/22575/8. -
LMIC keeps track of many more things: most importantly the duty cycle and frame counters, but also things like ADR for which it needs to keep specific counters, and then in some uplinks might need to set a specific bit to trigger ADR or include a MAC command to confirm the settings that the server gave it earlier. So, you’ll need to store the full LMIC state between invocations of the command line version, and make sure it uses the correct time to do its duty cycle calculations. See What LMIC state must be preserved during sleep mode?