send_on_wait increments the header_id automatically, but breaks after 256 messages sent

[barryhunter]

Found a small issue. The send_on_wait automatically increments a counter, to use as header_id, so it can match up ack's

But Lora messages are composed of bytes, so the header_id is limited to 0-255. So the once sent 256 messages, ack's no longer works. The sender technically sents header_id say 260, but due to interger wrap around the ack the server replies with has header_id=5, hence the sender thinks it doesnt receive any ack (header_ids mismatch).

I think the easiest solution would be just to wrap the counter.

I've changed around line 265

def send_to_wait(self, data, header_to, header_flags=0, retries=3):
    self._last_header_id += 1
    ....

to

def send_to_wait(self, data, header_to, header_flags=0, retries=3):
    self._last_header_id = (self._last_header_id + 1) % 256
    ....

which so far seems to have worked to keep ask reliable. NOt sure if there is better pythonesq way of writing that, but seems pretty clear.

Suppose could also/instead change line 279 to

                        self._last_payload.header_id == self._last_header_id%256:

Because the payload header_id will always come back wrapped, but let _last_header_id keep growing

Note sure if should submit as a PR?

Will be posting this upstream on https://gitlab.com/the-plant/raspi-lora/-/blob/master/raspi_lora/lora.py?ref_type=heads too