search

computenodes / dragino

LoRaWAN implementation in python
GNU Affero General Public License v3.0
27 stars 11 forks source link

Routing downlink messages #2

Closed BNNorman closed 4 years ago

BNNorman commented 4 years ago

This time I have a question about the dragino.py code.

The app I'm developing will spend most of its time listening for (occasional) downlink messages and a short time transmitting responses.

What is the best way to do this with dragino.py?

Looking at the code it appears to me that it just sends MHDR.UNCONF_DATA_UP and MHDR.JOIN_REQUEST messages and responds only to MHDR.JOIN_ACCEPT. I cannot see how I can receive messages into my app without changing the dragino.py code.

This is how I see it (roughly):-

1) in init () add self.UNCONF_DATA_DOWN=None 2) add new method setDownlinkCallback(myCallback): set self.UNCONF_DATA_DOWN=myCallback 3) add a new IF clause to rx_done() elif lorawan.get_mhdr().get_mtype() ==MHDR.UNCONF_DATA_DOWN and self.UNCONF_DATA_DOWN is not None: self.UNCONF_DATA_DOWN(payload)

Your thoughts would be appreciated. Thanks

pjb304 commented 4 years ago

Hi,

You're right the dragino code isn't set up to receive messages. We haven't needed that functionality in our application so it never got written.

LoRaWAN can work in one of 3 classes: Class A: The end-node listens to messages from the gateway in specific windows after it transmits, the rest of the time it doesn't listen. Class B: (requires GPS locked gateways) end-nodes get given specific timeslots in which to listen for messages Class C: device is listening all the time.

It sounds like you want to operate as Class C, which requires support all the way through the stack. I've moved onto a new project so I haven't been following advances in the TTN stack, but it would be worth checking that TTN now supports Class C operation.

Your proposed changes make sense to me.

BNNorman commented 4 years ago

Thanks for considering my code - I'll fork a copy and make the changes. The TTN console allows us to send downlink messages - really that's all that will happen - very short manual config commands sent to the end node once in a blue moon.

Your transmit code sets the device into receive mode (after idle) so I assume it will receive - I'll be testing that.

I have done something similar with MQTT message routing in the past.

Thanks for your reply. I'll investigate Class C.