-
Notifications
You must be signed in to change notification settings - Fork 3
Running the sensor code
The wifi estimator is a sensor. That means it is more like a thermometer than anything else.
We're highlighting this for a moment as a reminder: this is a device that looks at the world around it and reports on what it sees. If you live in a house with a single thermostat and, therefore, a single heating zone for an entire house (like your humble documentation author), that means that the temperature at the thermostat has a statistical relationship to the temperature in the rest of the house. For example:
- The thermostat may read 68 (it's winter here in Maine), but the second floor is always warmer than the first floor, because heat rises. So, the temperature in one room might be 72 (with the door open), but in another, it might be 66 (because the door is closed).
- The thermostat may read 68, but the basement will be 70, because the steam generation plant (it's an old house) and heating pipes put out ambient heat. So, it's actually kinda warm down there.
So, similarly, the wifi estimator monitors the world around it; depending on where you put it will impact what it "sees." We're emphasizing this for you because developing a new, novel environmental sensor is a very different activity from writing a web app that sells PEZ dispensers.
cd into the imls-wifi-sensor directory.
If you have Go installed correctly, you might start by running the linter over the codebase, just to see that things are working.
make check
If all goes well, you should be able to make the sensor (linux-session-counter) and the app that looks for compatible adapters (wifi-hardware-search-cli).
make all
This will install compiled binaries into ~/go/bin. As part of your setup, you may have added /home/$USER/go/bin to your shell's search path. If you did, you should be able to run these to see that everything worked.
linux-session-counter version
will print the current version of the session counter, and
wifi-hardware-search-cli
will run the wifi hardware search. It will fail, because it must be run as root. (It was developed for execution on a Raspberry Pi, where the entire device is given over to being a sensor.) You can safely run it as root on a Debian-based/Ubuntu-based system... it runs lsusb to search for compatible wifi adapters. However, as with all software, you run it as root (i.e. sudo) at your own risk.
sudo wifi-hardware-search-cli
A successful run will look like:
USER@machine:~/git/estimating-wifi/imls-wifi-sensor$ sudo /home/USER/go/bin/wifi-hardware-search-cli
8:50AM INF using configuration: session-counter.ini
8:50AM DBG --------
8:50AM DBG looking at field key=configuration value="broadcast=yes driver=rt2800usb driverversion=5.15.0-52-generic firmware=N/A link=no maxpower=450mA multicast=yes speed=480Mbit/s wireless=IEEE 802.11"
8:50AM DBG looking at field key=product value="802.11 n WLAN"
8:50AM DBG looking at field key=description value="Wireless interface"
8:50AM DBG looking at field key=vendor value=Ralink
8:50AM DBG looking at field key="logical name" value=wlx9cfed6ff48b3
8:50AM DBG looking at field key=serial value=9c:fe:d6:ff:48:b3
8:50AM DBG looking at field key="physical id" value=1
8:50AM DBG looking at field key=version value=1.01
8:50AM DBG looking at field key=capabilities value="usb-2.00 ethernet physical wireless"
8:50AM DBG looking at field key="bus info" value=usb@1:1
8:50AM DBG searching one field field=vendor query=ralink
8:50AM INF obtained field result=wlx9cfed6ff48b3
Note that our session-counter.ini file has us set to DBG mode, so we are getting a lot of extra information when we run.
make test
It is possible to run the sensor code on a Linux workstation along side the backend. That is, you can run the backend containers on your desktop, and run the sensor code on the same workstation. There are two ways: with a compatible wifi adapter, or by faking the data.
When run in this way, the sensor code generates fake data for sending to the backend.
In the directory imls-wifi-sensor, you need to create a file called session-counter.ini. We are currently using the following config file for testing:
[api]
host=localhost
scheme=http
port=3000
login_uri=/rpc/login
heartbeat_uri=/rpc/beat_the_heart
presences_uri=/rpc/update_presence
[config]
maximum_minutes=600
minimum_minutes=2
device_memory=7200
[cron]
reset=*/10 * * * *
heartbeat=*/1 * * * *
data_collection_cron=*/1 * * * *
[device]
api_key=hello-goodbye
fscs_id=KY0069-002
tag=anything
[ip]
path=/usr/sbin/ip
[iw]
path=/usr/sbin/iw
[log]
level=DEBUG
loggers=local:stderr,local:tmp
[lshw]
path=/usr/bin/lshw
[mode]
run=prod
[wireshark]
duration=45
path=/usr/bin/tshark
fakeshark_min_found=50
fakeshark_max_found=200
fakeshark_num_macs=30
The details of this .ini file are detailed in the repository. The most important thing to note is that the connection parameters (e.g. host, port) and the fscs_id and api_key must match what you used when you loaded local/test configuration data into your system. If you loaded our test data directly, this should "just work."
Once you have created this file, you should be able to run with it:
linux-session-counter --mode dev --config session-counter.ini
We override the config value for the runmode, setting it to dev, and we indicate that we want to use this config file.
If all goes well, you'll see something like the following:
USER@machine:~/git/estimating-wifi/imls-wifi-sensor$ linux-session-counter --mode dev --config session-counter.ini
9:57PM INF using configuration: session-counter.ini
9:57PM INF session id at launch session_id=0
9:57PM DBG DEV MODE, RUNNING FAKESHARK (IT'S A DOLPHIN)
9:57PM DBG runEvery crontab="*/1 * * * *" id=1 process="Data collection loop"
9:57PM DBG runEvery crontab="*/1 * * * *" id=2 process="Heartbeat process"
9:57PM DBG runEvery crontab="*/10 * * * *" id=3 process="End of day reset"
9:58PM DBG Running heartbeat
9:58PM DBG runFakeWireshark number of devices generated=121
9:58PM WRN Cannot grab serial number.
9:59PM DBG Running heartbeat
9:59PM DBG runFakeWireshark number of devices generated=164
10:00PM DBG Running heartbeat
10:00PM DBG runFakeWireshark number of devices generated=87
10:00PM INF RUNNING PROCESSDATA
10:00PM DBG queueing to send session=0
10:00PM DBG How many are we inserting? InsertMany number to insert=30
10:00PM DBG starting batch send
10:00PM DBG sessions in queue to be sent sessionsToSend=[0]
10:00PM DBG sending durations to API duration=30 session=0
10:01PM DBG Running heartbeat
10:01PM DBG runFakeWireshark number of devices generated=55
10:02PM DBG Running heartbeat
10:02PM DBG runFakeWireshark number of devices generated=123
10:03PM DBG Running heartbeat
10:03PM DBG runFakeWireshark number of devices generated=138
10:04PM DBG Running heartbeat
10:04PM DBG runFakeWireshark number of devices generated=137
10:05PM DBG Running heartbeat
10:05PM DBG runFakeWireshark number of devices generated=176
10:06PM DBG Running heartbeat
10:06PM DBG runFakeWireshark number of devices generated=111
10:07PM DBG Running heartbeat
10:07PM DBG runFakeWireshark number of devices generated=134
10:08PM DBG Running heartbeat
10:08PM DBG runFakeWireshark number of devices generated=137
10:09PM DBG Running heartbeat
10:09PM DBG runFakeWireshark number of devices generated=129
10:10PM INF RUNNING PROCESSDATA
The values in that config file are doing the following:
- Every minute, a fake monitor runs, watching for fake devices.
- Between 50 and 200 devices will be found, drawing from a possible set of 30 devices.
- Every 10 minutes, that data will be flushed to the DB.
This is silly, because it suggests... we see between 50 and 200 wifi devices in a minute, but... there's only 30 possible devices. This is essentially guaranteeing that we'll see all 30 devices every minute. (A more realistic approach might be to say you see between 10 and 100 devices, from a possible set of 12000 devices, if you want to emulate a library in a small town. You would also change the reporting rate, so that the data was flushed once per day, at midnight.)
The reason for these test parameters is so we can see the "entire sensor cycle" run rapidly. It is not "realistic" data, but it forces the sensor to run through its entire cycle of capture and reporting every 10 minutes.
- Once Upon a Time
- Getting Involved