Previous posts:
EasyConfigure - Modular/Configurable System Intro
EasyConfigure - Hardware Components
EasyConfigure - BASH scripting
EasyConfigure - MQTT test setup
EasyConfigure - Remote sensor unit preparation
EasyConfigure - Sudden Impact Monitor
EasyConfigure - Electrolube PU Resin
EasyConfigure - Remote Sensor Unit Fail - Workaround demonstration
Configurator
This tool is used to setup all remote sensor units so that they can connect to wireless network and start sending data to central unit (no hardcoded WiFi APs and passwords - can be transferred to different locations and used right away).
I was using my old Raspberry Pi B as a central unit but it seems like it was a bit slow so I switched to BBONE-BLACK-4G - ELEMENT14 - BEAGLEBONE BLACK REV C, CORTEX A8 | Farnell element14.
BeagleBone Black is running Debian Linux and is connected to wireless network using a WIFI DONGLE - ELEMENT14 - USB DONGLE, WLAN, 150MBPS | Farnell element14.
BeagleBone Black is currently set up to use a static IP. so I can use it easier but this is not that great. This is probably the only place where intervention is required but I plan to make the BeagleBone Black automatically discoverable by Configurator application so that no manual intervention is required (at this moment, administrator would have to set the WiFi connection on the BeagleBone manually and use the assigned IP in configurator GUI). However, BBB still needs to connect to different, possibly(probably) protected WiFi APs. To make this easier, I could make a BASH script that is called with AP SSID and Password passed as parameters - Users would then just connect to BBB using USB cable and ssh to 192.168.7.2 or I could make a node.js program to make the setup accessible from browsers via http://192.168.7.2/.
Current status
GUI is now extended with additional tab for device management.
First tab is used to scan for and setup found devices and the second one is used to enter each device's ID (SSID), password and a friendly name.
Figure 1. First Configurator tab - Device scanning and configuring
Figure 2. Device management - Setup passwords and friendly names for client applications to show instead of si_12345 names.
The initial version of Configurator application was using ssh connection to BeagleBone Black but that was too complicated if anyone would like to run this application on Windows. That's why I decided to turn over to simple TCP connection for communicating with BBB.
Configurator application now relies on a couple of IP servers running on BeagleBone Black. While still in prototype phase, these servers are created using nc(1): arbitrary TCP/UDP connections/listens - Linux man page in listening mode on port 51081 (scan_server.sh), 51082 (configure_server.sh), 51083 (get_list.sh) and 51084 (set_list.sh). In a final product all these "server" scripts can be combined in a single server application (instead of BASH scripts).
Scanning is performed using a BASH script and its output is sent back to the Configurator application.
Similarly, configure_server.sh accepts client connections on port 51082 and receives configuration string from Configurator app. This string is then parsed and sent to corresponding remote sensor device.
"Load Devices List" button triggers a connection to BBB:51083 and the list of devices with their IDs, password and friendly names is received back from BBB. Similarly, "Save Device List" sends the list to set_list.sh listening on port 51084.
Future improvements
As it can be seen on Figure 2, There's a 4th column in the devices table. This column is reserved for a list of available sensors for each device. This field will be populated automatically as data starts to arrive to the broker (BBB). This is not yet implemented due to lack of time but it's not hard to do, Configurator will just have to subscribe to all topics and check the readings to see the list of sensors for each device. Remote sensor device scan the I2C bus to get the list of sensors that are connected (in future versions, sensors that are interfaced through SPI or analog sensors could be added - that would require an additional MCU for each of them that interfaces them and then talks to ESP8266 over I2C).
