Got the box

[Scott Seidman]

Oren-

Got the box, I installed a native LinuxMint, and think I have the toolchain installed.  JLinkExe recognizes the programmer, and I'll play more this week.

Scott

[Oren Lederman]

Great! Let me know how it goes. I don't know if you meant to post this on the forum or not, but in either way it's better if you describe your experience/ask questions here.

[Scott Seidman]

Very close now.  Launchpad was having some issues, so I downloaded the latest gcc toolchain right from ARM, and got a ton of errors on make

Then, I downloaded v5_4, and all those errors went away, but I have a new one:

scott@scott-Yoga:~/Desktop/openbadge-master/firmware/nRF_badge/data_collector$ make badge_03v6_tester flashUnlock flashErase flashS130 flashAPP
PROTOCOL_VERSION = 1
rm -rf _build
mkdir -p _build
make: git: Command not found
make: git: Command not found
make: git: Command not found
Compiling file: main.c
/bin/sh: 1: /opt/gcc-arm-none-eabi-5_4-2016q3/bin/arm-none-eabi-gcc: not found

Makefile:502: recipe for target '_build/main.o' failed
make: *** [_build/main.o] Error 127

This is a bit odd, as /opt/gcc-arm-none-eabi-5_4-2016q3/bin/arm-none-eabi-gcc  certainly exists, and with what looks like the right permissions.

Also, note that I had to edit the Makefile in the datacollector directory -- someone changed the nrf path to point somewhere strange:

# Michael: ADDED /nRF5_SDK_12.3.0_d7731ad
#SDK_PATH := $(NRF_SDK_PATH)/nRF5_SDK_12.3.0_d7731ad
SDK_PATH := $(NRF_SDK_PATH)

[Oren Lederman]

There are a couple of problems here:

1. the git error probably means that you download the code from github instead of closing it. There's a small piece of code that expects a git environment so it can embed the git commit # in the code and later of transmit it (not sure if we implemented it)

2. not sure that the gcc issue is. try fixing issue #1 and see if it still does work

3. The SDK path is indeed a bit messy (will create an issue to clean this up), but it's not really a problem if you run it from Docker - the docker compose files setup the environment correctly so the SDK points to the correct location. 

In general, I strongly recommend using docker-compose to run this. these annoying path and compiler compatibility issues is exactly why we created it...

[Scott Seidman]

Did a git clone, and it fixed the git error, but still can't find that file.  Might be a permissions issue.  In any case, I've installed docker, built nrf, and tried to build:

scott@scott-Yoga:~/Desktop/openbadge-master/openbadge$ docker-compose run nrf make badge_03v6_noDebug flashUnlock flashErase flashS130 flashAPP

PROTOCOL_VERSION = 1
rm -rf _build
mkdir -p _build

Compiling file: main.c
main.c:8:22: fatal error: nrf_gpio.h: No such file or directory
 #include "nrf_gpio.h"
                      ^
compilation terminated.

Makefile:502: recipe for target '_build/main.o' failed
make: *** [_build/main.o] Error 1

scott@scott-Yoga:~/Desktop/openbadge-master/openbadge$

I do find a nrf_gpio.h when I look for it:  ./nrf/sdk/nrf_sdk_12_3/nrf5_12.3.0_d7731ad/nRF5_SDK_12.3.0_d7731ad/components/drivers_nrf/hal/nrf_gpio.h

[Oren Lederman]

Strange. I'll try to run a clean build on my machine again tomorrow and see if I'm getting any errors.

Which version of docker and docker-compose are you using? Mine are:

Docker version 18.09.1-rc1, build bca0068

docker-compose version 1.21.2, build a133471

[Scott Seidman]

Docker is 17.05.0-ce build 89658b3, and docker-compose returns build 1.17.1, build unknown.

[Oren Lederman]

I just tried to build everything from a clean clone and I'm not getting these errors. 

Can you try with a newer version of docker? 

[Scott Seidman]

Updated to the latest, and still get the same error about nrf_gpio.h.  Am I right to assume that this must be referring to an h-file on the clone, and not on my local machine?  Are any of the paths set from any files on my machine that I might have screwed up on?  When the clone is formed, can it be copying a permission from my machine that I have wrong?

[Scott Seidman]

Does it make a difference which directory I'm in when I do the build?  The file in the top level seems to point to ./compose

On Wednesday, January 9, 2019 at 5:56:57 PM UTC-5, Scott Seidman wrote:

[Scott Seidman]

Which makefile on the clone is actually getting run?  

[Oren Lederman]

Everything runs on your local machine, inside a lightweight docker container. Clone simply creates a copy of the git repo on your machine. 

It doesn't seem to make a difference which folder you are in when you build and run (I tried). So I'm not sure what's going on there.

Your directory structure is a bit weird though. I see "~/Desktop/openbadge-master/openbadge". Can you create a clean clone right under Desktop, just to make sure there aren't two copies of the compose file somewhere? 

Got to ~/Desktop, and run "git clone https://github.com/HumanDynamics/openbadge.git" (or git clone g...@github.com:HumanDynamics/openbadge.git, if you set the keys for github). Then build and run.

If it still doesn't work, email me and we can setup a teamviewer session so I can have a look at it.

Oren

[Scott Seidman]

Sonofagun.  That seems to have worked!!

[Oren Lederman]

I'm as surprised as you :)

--
You received this message because you are subscribed to the Google Groups "Rhythm Badges" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rhythm-badge...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rhythm-badges/c798dc60-4a32-44ba-a00f-3ccd4c3a45f4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Scott Seidman]

Picked up the project again at the next step.  Attempting to get a terminal running, but really don't understand how to find the MAC address of the badge.

After reading a bit, it looked like the MAC address might be assigned by the loop programmer, so I tried running that, and it returns an error about inotifywait:

$ ./programming_loop_docker.sh prod
Using parameters: badge_03v6_noDebug flashCode
============================================================
Compiling code- badge_03v6_noDebug
============================================================

PROTOCOL_VERSION = 1
rm -rf _build
mkdir -p _build
Compiling file: main.c

Compiling file: adc_lib.c
Compiling file: spi_lib.c
Compiling file: uart_lib.c
Compiling file: flash_lib.c
Compiling file: system_event_lib.c
Compiling file: eeprom_lib.c
Compiling file: debug_lib.c
Compiling file: storage1_lib.c
Compiling file: storage2_lib.c
Compiling file: storage_lib.c
Compiling file: filesystem_lib.c
Compiling file: accel_lib.c
Compiling file: chunk_fifo_lib.c
Compiling file: systick_lib.c
Compiling file: ble_lib.c
Compiling file: sender_lib.c
Compiling file: request_handler_lib_01v1.c
Compiling file: request_handler_lib_02v1.c
Compiling file: protocol_messages_01v1.c
Compiling file: protocol_messages_02v1.c
Compiling file: common_messages.c
Compiling file: chunk_messages.c
Compiling file: stream_messages.c
Compiling file: storer_lib.c
Compiling file: advertiser_lib.c
Compiling file: scanner_lib.c
Compiling file: battery_lib.c
Compiling file: microphone_lib.c
Compiling file: circular_fifo_lib.c
Compiling file: sampling_lib.c
Compiling file: processing_lib.c
Compiling file: timeout_lib.c
Compiling file: selftest_lib.c
Compiling file: uart_commands_lib.c
Compiling file: tinybuf.c
Compiling file: system_nrf51.c
Compiling file: nrf_drv_uart.c
Compiling file: nrf_drv_common.c
Compiling file: nrf_adc.c
Compiling file: nrf_drv_spi.c
Compiling file: fstorage.c
Compiling file: softdevice_handler.c
Compiling file: app_error.c
Compiling file: app_error_weak.c
Compiling file: nrf_drv_clock.c
Compiling file: app_util_platform.c
Compiling file: nrf_drv_gpiote.c
Compiling file: app_timer.c
Compiling file: ble_advertising.c
Compiling file: ble_advdata.c
Compiling file: ble_nus.c
Compiling file: ble_srv_common.c
Compiling file: app_fifo.c
Compiling file: app_scheduler.c
Compiling file: gcc_startup_nrf51.S
Linking target: nrf51422_xxac_s130.out
make[1]: Entering directory '/app/firmware/nRF_badge/data_collector'
Preparing: nrf51422_xxac_s130.bin
Preparing: nrf51422_xxac_s130.hex

   text       data        bss        dec        hex    filename
  65900        300      16904      83104      144a0    _build/nrf51422_xxac_s130.out

make[1]: Leaving directory '/app/firmware/nRF_badge/data_collector'

============================================================
Place new badge. if a badge is already placed, remove it and place it in the programmer again
./programming_loop_docker.sh: line 64: inotifywait: command not found

[Scott Seidman]

Got the programming loop running.  It doesn't seem to want to program one of the boards you provided, but programs another fine.    The "bad" one seems to actually program when I run the nrf docker-compose sequence, but it doesn't seem to want to mount as a disk like the "good" badge.  I brought home 2 to play with this weekend, so I'm a bit dead for running this down at the moment.

I did use getMAC to pull the MAC, and it does seem to work with both badges:

docker-compose run nrf terminal FE:F4:6D:39:37:61
Connecting to badge FE:F4:6D:39:37:61
DEBUG:ble_badge_connection:Connecting...
Traceback (most recent call last):
  File "./terminal.py", line 282, in <module>
    main()
  File "./terminal.py", line 32, in main
    connection.connect()
  File "/app/BadgeFramework/ble_badge_connection.py", line 88, in connect
    self.conn = btle.Peripheral(self.ble_device, btle.ADDR_TYPE_RANDOM)
  File "/usr/local/lib/python2.7/dist-packages/bluepy/btle.py", line 318, in __init__
    self.connect(deviceAddr, addrType, iface)
  File "/usr/local/lib/python2.7/dist-packages/bluepy/btle.py", line 367, in connect
    "Failed to connect to peripheral %s, addr type: %s" % (addr, addrType))
bluepy.btle.BTLEException: Failed to connect to peripheral FE:F4:6D:39:37:61, addr type: random

It looks like it fails at the BTLE step, which isn't a real surprise, since my workstation doesn't have bluetooth -- its a little old.  Wasn't sure I'd need this for just using the terminal, but I guess I was wrong.

Next step is to get a hub running on the pi 3B+ -- Is it safe to assume that I start the directions at https://github.com/HumanDynamics/openbadge-hub-py#setting-up-raspberry-pi-with-hypriot??  I see raspbian hubs for pi zero.  Will Hypriot be very different to work in?

Thanks again!  I'm trying to maintain a set of step-by-steps to share later.

[Oren Lederman]

"Bad" badge - sometimes you need to try more than once, and/or give it a little bit more time to "mount". It happened to me before, and I can't explain it. Sometimes reboot the computer helps.

BLE and terminal - another part that is relatively new and not well documented. There are actually two different versions of the terminal, because we have two versions of the communication protocol. The entire system basically uses protocol version 1, but the badge supports a much nicer protocol. By default, when you program the badge you get version 1. However... the default terminal uses version 2. If you want to try the terminal, use "terminal_legacy.py" instead of "terminal.py".

It might explain why the connection fails. If you have bluetooth (BLE) on your computer it should just work. You can try running "sudo hcitool lescan" and see if it finds the badge.

Installing the hub - you can follow the regular raspi installation, as explained here. It will work for both - https://github.com/HumanDynamics/openbadge-hub-py#setting-up-raspberry-pi-using-raspian-for-raspberry-pi-zero-w

Hyperiot has a couple of nice cool features that makes the initial setup a bit easier (not by much), but it keeps having issues with pi zeros. I ended up using regular raspbian for all of my deployment. 

--
You received this message because you are subscribed to the Google Groups "Rhythm Badges" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rhythm-badge...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/rhythm-badges/d9bd5d04-194b-489a-825b-0b5bf4b1b9ba%40googlegroups.com.

[Scott Seidman]

Seems to be working -- I ran the hub on raspbian, and had three badges running.  The docker hub recognized all three, and seemed to generate two text files in the "data" directory -- one proximity and one audio.  I'm not sure how to interpret the data in there, but that shouldn't be a big deal.

I suppose the next steps would be to make a bunch of boards, create a bunch of hubs by duplicating the SD card for the Pi's and changing the host name, get a beacon running, and deal with all our networking issues.

[Oren Lederman]

Hi Scott, that's great! If you need to use more than one hub (for example, if you have more than 20 badges or you need to cover a larger area), you should setup a server and make the hub communicate with the server. It will allow you to monitor the status of the badges, and it pulls all the data and stores it in one place (the server).

For processing the data, you should checkout the analysis package (https://github.com/HumanDynamics/openbadge-analysis) and the examples (https://github.com/HumanDynamics/openbadge-analysis-examples). The examples are a bit mess (sorry), but I recommend focusing on these two:

1. https://github.com/HumanDynamics/openbadge-analysis-examples/blob/master/notebooks/meeting_simple_plots.ipynb - simple example for audio analysis. Note that the python code for audio analysis has a hard-coded timezone handling (it assumes GMT-4)
   
2. https://github.com/HumanDynamics/openbadge-analysis-examples/blob/master/notebooks/hub_proximity_example.ipynb - proximity data example. The proximity code is more up to date (and less messy), and has better support for timezones. The example shows how to generate the main data structures you might need - member-to-beacons (the beacons that member badges see) and member-to-member (the badges that each badge see at each point in time).
   

[Scott Seidman]

Thanks for ALL the guidance. It looks like it's fairly straightforward from here.  The biggest challenge might just be networking issues that arise in our pretty secure IT environment.  We might need to support our own LAN behind a firewall.

A quick question?  It looks like a beacon is nothing more than a stationary badge with a high ID number that allows a known geometry to sit in the project.  Is this right?

Lastly, can you hook me up with your assembler?  It looks like we can probably start up our fabrication process.  

[Oren Lederman]

Happy to help. If you setup the hubs behind a firewall, make sure they have a NTP server to sync their clocks with. Don't do it manually (you want them to be as precise as possible). We had a lot of issues with that with one of our collaborators. If you look at the list of hubs in your server (when you set it up), you'll see taht they report their internal time and the delta from the server time to help you find problematic hubs.

Beacons - yes, beacons are just stationary badges with high ID. It is best to use the built-in settings that we have in the standalone hub or with the server to configure them - beacons don't need to collect data, so when you set them up as beacons they'll just change their ID but won't start data collection. They can run on a single battery for 2-3 weeks (as opposed to ~3 days of data collection on a single battery, or 6-7 days with two batteries).

Assembler - yes, I can connect your with pcb.ng and see if they can copy my project to your account. The main problem you might have is availability of some of the components we use (mostly the capacitors), so you'll need to find alternative components. Do you know how to do that?

Oren

[Scott Seidman]

Do you have any recommendations about how far apart beacons should be?

I won't have a problem w/ any of the fabrication issues.  I've done a lot of boards in quantities like this before, all the way up from bare metal.  I'll take a pass through your BOM, generate replacement parts, and update the project with the fabricator.  I don't see anything odd about any of the capacitors on the board.  I'll peek at the Rigato docs an make sure there's no special issues about the 12pf caps on the crystal.  I'd be more worried about sourcing the switch and the nrF unit than the caps, but I don't think there's an issue.

I noticed (when I was looking for indicia on the back) that the battery holder on the back looks like it was hand-soldered.  Was that done at the fabricator, or separately?  If we only need a few days of use, would you recommend just leaving the back battery holder off?

Is there any objection to us printing the boards logoed the way they are now?  I'd rather not have to go into Eagle to dork around just because of a silk screen (not that I don't want to do it, but I really like to test a prototype if I do anything that touches the Gerber files before doing a real run)  If it's a problem, I'll probably just ask for silk screen on one side only.

I prefer to just give assemblers a BOM w/ part numbers and centroids, and let the fabricator generate a turnkey solution, with them doing all the ordering.  They know how their pick and place work well, and they tend to prefer buying all the reels -- especially if they have to buy partial reels.  Some of the "digi-reel" stuff that digikey sells jam up their robots.

Do you think it's work sending the fabricator a Rasp. Pi to program the boards w/ the test binary?  I recall you telling us their failure rate is very low.

[Oren Lederman]

I use location beacons as points of interest, do simply associate people with the closest beacon (after some smoothing). I don't use triangulation or anything similar. Therefore, it really depends on the resolution you need for your study - in the last study I had ~70 beacons, on each table in the working environment, in each meeting room, phone booth, a couple in the kitchen and some in communal areas. The location is going to be noisy whatever you end up doing (especially in open spaces), but it will give you a  sense of where people are. 

The problem with the caps is a world-wide shortage with pretty everything. Perhaps it gotten better in the last several months.

Yes, the battery holders on the back were hand soldered. We didn't need them at first when we set the badges to scan every 1 minute, but later on we changed the scans to 15 seconds intervals and needed more juice. Also, we didn't want to pay extra for two-sides assembly for something that can be easily hand-soldered. With one battery, the badge can run for 3-4 days using 15 seconds intervals, non stop. I have done some tests, and I HIGHLY recommend the Panasonic CR2032 batteries. They worked the best, and give you a nice slow voltage drop that makes it easier to track when the badge is going to die. The best place to get them is form DigiKey - https://www.digikey.com/product-detail/en/panasonic-bsg/CR2032/P189-ND/31939 

You are welcomed to use the logos and writings that are already in the gerber files. I don't mind having my name in more places :)

PCB.NG order the parts themselves, they'll just need the part numbers from Digikey or Mouser. They don't program badges themselves though (so you can't give them a programmer). The last batch we made with them had 0 rejects, and the batches before that had less than 5% rejects (for ~120 badges batch). They were willing to fix faulty badges when the issue was their fault, and we did it once or twice (just added extra units for the next batch). 

[Scott Seidman]

Pretty funny -- I bought 50 of exactly that battery about 2 weeks ago for our testing.  The capacity was pretty impressive, at least on paper!

[Oren Lederman]

Yup. it's the best I found. Energizer batteries actually have slightly higher capacity, but they last the same amount of time and their voltage drops more sharply (when used in our badges). Tianqiu batteries from ebay lasts %30 less time.

To view this discussion on the web visit https://groups.google.com/d/msgid/rhythm-badges/f11b2b33-f2e5-414f-aaa8-4411cde1723b%40googlegroups.com.

[Scott Seidman]

When running the hub in standalone, does the application echo info about the beacons to the terminal?  I can't tell if my beacon is being id'ed.  Is there different code that needs to be installed on the beacon?

On Wednesday, January 9, 2019 at 5:56:57 PM UTC-5, Scott Seidman wrote:

[Scott Seidman]

Actually, that board doesn't seem to get picked up as a badge, either

[Scott Seidman]

I think its a docker caching issue.  I think I correctly cleared the cache, and now I'm rebuilding

[Scott Seidman]

No love --  I created some sort of indexing error:

pi@raspiScott:~/Desktop/openbadge-hub-py $ docker-compose -f dev_jessie.yml up 
Starting openbadgehubpy_openbadge-hub-py_1
Attaching to openbadgehubpy_openbadge-hub-py_1
openbadge-hub-py_1  | /usr/local/lib/python2.7/dist-packages/dotenv/main.py:24: UserWarning: Not loading /app/.env - it doesn't exist.
openbadge-hub-py_1  |   warnings.warn("Not loading %s - it doesn't exist." % dotenv_path)
openbadge-hub-py_1  | 2019-02-08 16:28:57,685 - DEBUG - Standalone version. Will request data since 1549661037 685
openbadge-hub-py_1  | 2019-02-08 16:28:57,691 - DEBUG - Standalone version. Will request data since 1549661037 691
openbadge-hub-py_1  | 2019-02-08 16:28:57,692 - INFO - Resetting bluetooth
openbadge-hub-py_1  | 2019-02-08 16:28:57,706 - INFO - Setting bluetooth connection parameters
openbadge-hub-py_1  | 2019-02-08 16:28:57,708 - INFO - Raspberry Pi detected, changing bluetooth connection parameters
openbadge-hub-py_1  | 2019-02-08 16:28:59,712 - INFO - Done resetting bluetooth
openbadge-hub-py_1  | 2019-02-08 16:28:59,714 - INFO - Started pulling
openbadge-hub-py_1  | 2019-02-08 16:28:59,715 - INFO - Start recording: Audio = True, Proximity = True
openbadge-hub-py_1  | 2019-02-08 16:28:59,721 - INFO - Reading devices from file: /config/devices.txt
openbadge-hub-py_1  | Traceback (most recent call last):
openbadge-hub-py_1  |   File "./badge_hub.py", line 685, in <module>
openbadge-hub-py_1  |     pull_devices(mgr, mgrb, args.start_recording)
openbadge-hub-py_1  |   File "./badge_hub.py", line 432, in pull_devices
openbadge-hub-py_1  |     mgr.pull_badges_list()
openbadge-hub-py_1  |   File "/app/badge_manager_standalone.py", line 75, in pull_badges_list
openbadge-hub-py_1  |     file_badges = self._read_file(self._device_file)
openbadge-hub-py_1  |   File "/app/badge_manager_standalone.py", line 50, in _read_file
openbadge-hub-py_1  |     {"mac": device_details[0],
openbadge-hub-py_1  | IndexError: list index out of range
openbadgehubpy_openbadge-hub-py_1 exited with code 1
pi@raspiScott:~/Desktop/openbadge-hub-py $ 

[Robert White]

Hi Oren, I am working with Scott, and have been looking at the GitHub site trying to identify which Python analysis files I need. Is there an order to them, do I just clone the openbadge_analysis file and run that? I am new to Python but working my way through. Any tips? Does the openbadge_analysis package still exist? I was trying to find the documentation file but it doesn't seem to exist.

Also I am wondering it the openbadge_analysis Python code is still applicable, as it appears that the proximity data that Scott has obtained (attached) is somewhat different than the proximity data in the analysis example file.

Pardon me if there are some obvious things I am missing..If all should work and my amateur Python abilities are the problem, just say the word and I will find a more skilled user..

Thanks so much!

Robert

[Oren Lederman]

Hi Robert,

Please open a different thread on analysis questions so it's less confusing. I'll answer there.

Oren

[Oren Lederman]

It's very easy to break the devices file... we kinda neglected it since we had the server :) Can you attach the devices file so I can look at it?

In general, you'll want to but "badges" (for participants) in the devices file, and "beacons" in the beacons file.  The main difference between badges and beacons is that badges actually record data. Beacons just broadcast their ids. Just make sure to give beacons ids that are > 16000, and make sure that all beacons adn members are part of the same project id (they'll ignore other project ids).

When the hub uses the pull command, it will do two steps:

1. Scan for badges, and then connect to each one, activate it (if needed) and pull data

2. Scan for beacons, and then connect to beacons that has the wrong id and tell it to change the id

So if you are waiting for it to show you beacons in the scan, wait for the second scan that looks for beacons.

(Note - the hub code isn't pretty, I know. But it survived many generations of undergrads contributing to it. One day I hope to rewrite it...)

[Scott Seidman]

That's what's going on?  Just a bad devices file??

[Scott Seidman]

Looks like I needed a line in the beacons file.  It didn't like all the beacons commented out.

[Scott Seidman]

Having a little trouble understanding the server system, probably relating to my unfamiliarity with setting up ssh.  As near as I can tell, the server will be running as a docker machine on a host machine.  Is the docker machine ssh-ing into the host machine, or is the host machine ssh-ing into the docker machine??

So, in the command:

docker-machine create --driver generic --generic-ssh-user <username> --generic-ssh-key <ssh-key-location> --generic-ip-address <ip-address> <machine-name>




is the command setting up an ssh user <username> on the docker machine, or is it asking for the name of the ssh user on the host?




Do I create an ssh user on the host, generate a key, and then give the public key to the docker server and all the hubs?







[Oren Lederman]

The dockier-machine command uses SSH to connect to another machine and install a daemon process there. This allows you to deploy a docker into that remote machine as if it was your local computer. 

Back to your question, you need to setup a user and ssh key so you can use them to connect to the remote server. Which is basically what you described in the last one. A good way to do it is to use the "ssh-copy-id" tool. Once you have a key, you can use it to connect to the other machines and drop the public key in the right place.

--
You received this message because you are subscribed to the Google Groups "Rhythm Badges" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rhythm-badge...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/rhythm-badges/1a704f6f-78c2-4b2a-8589-8efc8f2bd920%40googlegroups.com.

[Scott Seidman]

Aah, I did have a misunderstanding!  So, if I want to run the server on my local Machine, all I need to do is the instructions on the Github site under "development"?  This seems to work, and I have the server running  -- confirmed by pulling up the website.

In the .env file, does the host list need to be the local machine IP, or the IP of the hubs??  If it's the hubs, do I separate IP addresses with spaces or commas?  When I configure the hubs, do I give them the IP address of the host machine, or some IP address for the docker machine?  Is running the hub in server mode no more complex than creating the appropriate .env and running

docker-compose -f dev_ubuntu.yml run openbadge-hub-py -m server pull

[Oren Lederman]

The short answer is that yes, you can just run it in dev mode on your local machine. It mostly makes configuration easier and gives you more detailed logs that the production mode doesn't give you. 

host list - I'm assuming that you are referring to ALLOWED_HOSTS in the .env file of the server. It's a Django setting (the underlying web server) that defines the domains handled by the server itself.  In production mode, it's a comma-separated list of the domains handled by the server (e.g. some-opendage-server.media.mit.edu). I think that putting the IP works as well, and if you aren't sure you can put a star (*) as a wildcard. It's less secure though. Also, as far as I remember, it doesn't matter what you put there in dev mode.

setting up the hubs - you give them the IP and port in which they can reach the server. To test it, try to login from a browser to the admin page on that ip and port (e.g. http://some-opendage-server.media.mit.edu:8000/admin or some-opendage-http://server.media.mit.edu/admin , depending on which mode you are using).

dev vs. prod - it's almost the same complexity, and the env files are very similar. the dev is more forgiving and gives more detailed logs. You can actually run the prod mode on your local machine and a dev mode on a remote machine, we just describe the best practice in the README. 

Another note - you will need to add the hubs to a project on  the server, otherwise they won't be allowed to connect. Use the hostname of the hub in both the name and UUID.

Last note - if possible, please open new discussions for different topics. It'll be easier for other people to search for answers.