Ad hoc networking

[jlin143]

As an alternative to the traditional externally-hosted server architecture (see image below), one method to reduce costs would be to implement NodeFlow with ad hoc networking.

Instead of all sensors uploading data to the external server through a LoRaWAN gateway, and then having the solenoid controllers react to (or be acted upon) the data, the server can be moved closer to where the devices are.

There are a few sub architectures that I am thinking of.

1. [Internal private server] One ENTS board acts as the wifi / LoRaWAN gateway, and acts as a pared down ENTS-backend plus the NodeFlow GUI. This board hosts a wifi hotspot (no external internet connection). Alerting only available locally.
   • As the ENTS-backend, the device must store data, respond to API requests, host the website, and manage loggers and cells.
   • As the NodeFlow GUI, the device must host the website and manage nodes. When communicating with nodes via LoRaWAN, calls must be made directly to the LoRa hardware rather than through a The Things Network API.
2. [Internal public server] One ENTS board acts as the LoRaWAN gateway, with a regular wifi router behind it. This board connects to the provided wifi network (with external internet connection). Must expose this one device to external networks (or VPN / etc) to allow external management.
3. [Internal private/public server, reduced] Same as above, but this one board is also the singular solenoid controller. Requires extensive firmware modification. Alerting only available locally if no internet connection.
4. [Extra ad hoc] No ENTS board acting as the server. All data is listened upon directly by the solenoid controllers. Solenoid controllers all can act as the NodeFlow instance at need, and will propagate NodeFlow configurations throughout the ad hoc network. Requires extensive firmware modification. Alerting only available locally.