abalmos
commented
3 years ago This is what I was trying to work out on the Miro board a few meetings back. It might be worth revisiting that at some point as we work through this.
To start, I'll say this: We should be creating declarative interfaces where one provides the desired state and lorawand does what it needs to make that a realtilty. For example, NetworkManager takes configs of a network state and then it reacts to Linux network events/dbus/etc. to make that state true. You don't give NetworkManager commands to connect to this things now, set the password to this value, do DHCP now, etc. etc.
One exception is that lorawand is also doing the send / receive work. NetworkManager does have to worry about that. Clearly we will need some sort of imperative interface for that part.
Do we want to do state configs over NATS or a config file deploy next to the lorawand container? Is LoRaWAN network config an application issue or a deployment issue?
I pushed commit 0f44ce2bb4eb940ce15a5139130efd02a4c39c06 that contains the lorawand skeleton code.
I want to first focus on sending the sequence of AT commands to configuring the lora module to join a network. Maybe I am overthinking it but we haven't really discussed the pub/reply schemes in between the module and NATS.
Specifically, for a lora module to join a network:
AT commands (
AT+NJM=1...AT+JOIN), in between each command, parse out response, if not expected, put failed message on queue and have NATS publish it as a reply. If everything works as normal, put one single message to indicate success, and have NATS publish as reply.Or
For each command, parse out response, publish success reply in NATS.
What's your thought @abalmos ?