Pull networkProtocol handlers and reportingProtocol handlers up from their respective API into their respective models. Explanation below.
Add support for IP devices
Share Postgres and Redis between LPWAN Server and LoRa servers in development
Use one docker-compose file with Prisma, Postgres, and Redis. Add script for more conventient db commands.
Make app startup asyncronous. Only listen for connections if initialization is successful.
Structured Prisma so that code generated by Prisma is not committed.
Do you have any concerns with this PR?
IP device messages need to be tested and web-client needs to be updated.
How can the reviewer verify this PR?
Run tests
Any background context you want to provide?
Right now the device's IP/port and a timestamp are being cached in Redis, as well as a message queue for messages that can't go out yet to NB-IoT devices. I chose to use a connectionDuration setting in the DeviceProfile, which if set, will determine how long after the LPWAN Server receives an uplink from an IP device it is able to send a downlink message. If duration has passed, all queued messages will be sent as separate requests after the next uplink.
There are serveral DB hits on an IP device uplink:
find and ensure the device network type link still exists
get the device
get the application and make sure it is running
Caching any of these would also mean listening to changes from Prisma to make sure the cache isn't stale. The effort to do this one use case would be similar to implementing a more generic DB caching solution. There are many redundant DB reads in the LoRa network push/pull flows. After testing IP devices I'll work on a generic DB caching solution.
The network protocol handlers were behind the network protocol API, which assumes there's a network. I exposed the handlers at the model level to make them available to device types without networks.
I refactored a bit so that LoRa Server and LPWAN Server could share a development instances of Postgresql, without public schema collisions, and Redis.
Screenshots or logs (if appropriate)
Questions:
Have you connected this PR to the issue it resolves? #269
Does the documentation need an update? After successful testing
Does this add new dependencies? redis and bluebird
Have you added unit or functional tests for this PR? No
What does this PR do?
Do you have any concerns with this PR?
IP device messages need to be tested and web-client needs to be updated.
How can the reviewer verify this PR?
Run tests
Any background context you want to provide?
Right now the device's IP/port and a timestamp are being cached in Redis, as well as a message queue for messages that can't go out yet to NB-IoT devices. I chose to use a
connectionDurationsetting in the DeviceProfile, which if set, will determine how long after the LPWAN Server receives an uplink from an IP device it is able to send a downlink message. If duration has passed, all queued messages will be sent as separate requests after the next uplink.There are serveral DB hits on an IP device uplink:
Caching any of these would also mean listening to changes from Prisma to make sure the cache isn't stale. The effort to do this one use case would be similar to implementing a more generic DB caching solution. There are many redundant DB reads in the LoRa network push/pull flows. After testing IP devices I'll work on a generic DB caching solution.
The network protocol handlers were behind the network protocol API, which assumes there's a network. I exposed the handlers at the model level to make them available to device types without networks.
I refactored a bit so that LoRa Server and LPWAN Server could share a development instances of Postgresql, without public schema collisions, and Redis.
Screenshots or logs (if appropriate)
Questions: