The problem is that they want an interruptible sleep so that they can transmit at the unknown next future time they need to.
I have no idea if that is available. If it is not, a solution might be to just keep sleeping for a reasonable amount of time until there’s a change of count that crosses a threshold, and then send. Sometimes there might be 9 one-second sleeps before you hit the criteria, sometimes 10, it probably doesn’t really matter.
Given the many potential sources of packet loss, the system should also probably have an interval after which a send is triggered even with no movement at all.
I’d suggest sending at least 16 bits of count value to avoid any ambiguity of rollover. Unless other information is being sent you might as well do 32 bits; a LoRaWAN header and trailer cost something like 13 bytes, so at the small end it doesn’t make a big difference if you send a 1, 2, or 4 byte packet. (Though there is granularity imposed by the 4/5 coding - the actual airtime doesn’t increase with each byte, but rather jumps each time a new coding group must be added, so you “pay” in airtime for the number of coding groups sent, even if the last one is only partially filled).