running server and connecting hubs

[Scott Seidman]

From the other thread:

he 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.

 

OK.  I have the server running, verified by navigation to <ip-address>:8000/admin  -- I get a login request for Grapelli, but I'm not sure what username and password to use, but at least I know it's running!

Next, on the hub, when I run docker-compose -f dev_jessie.yml up, everything seems to work just fine.  When I try to run it in server mode (....run openbadge-hub-py -m server pull)  I get "Error reading badges list from server" -- Is this because I haven't added the hubs to a project on the server?  I'm not real clear on where that needs to be done.  Is it from "addproject" on the server admin page?  I created a project, set the ID to the project ID in the config files on the hub, and added the hostname of the hub under Name and Uuid in the window. Do any of the other fields need to be filled?  

There's a few keys laying around, and I'm not sure where they go.  After I added the project, in provides a project key.  Is this the APPKEY in the hub .env file, or should that be set to the Django secret key in the server .env file??  Or, is that the AWS_SECRET_ACCESS_KEY in the hub .env file??  

Feels like I'm very close now, but it's a bit slow to try different things in the hub .env, as I guess I need to force a rebuild for each try.  Are there some detailed instructions for what needs to go into the .env, or steps to creating a project on the server?

 

[jjre...@gmail.com]

Hey Scott,

The APPKEY setting in your hub .env is separate from the project key, aws keys, and the django secret key - it should match the APP_KEY you set in the django .env file. It shouldn't really matter what it's set to, as long as they match. As far as detailed instructions for the .env file goes, I'm not sure I would call them 'detailed' but there are some instructions in the README files in the root directory of the projects. 

For creating a project on the server, I'm not sure there is a write-up of that anywhere, so I'll give it a go here:

if you navigate to <server address>:<server port>/admin, you'll get prompted to log into the admin page. You should use the username/password you provided when you ran the following command: 

docker-compose run django python manage.py createsuperuser

Once you've logged in, you can click 'Projects' and then the 'Add Project' button in the top right.

From there, you can name your project and add your badges(listed as members)/beacons/hubs in the corresponding fields

To add a 'member' (a badge), you just need to give it a name (e.g. 'A') and then add the MAC address under the 'badge' field. If you want to add a beacon it's the same deal. 

For hubs, you can give it whatever name you want and then add the hostname as the uuid. None of the other fields matter at this point.

That should do it for project creation, I think

Assuming your the app key in your hub's .env file matches the app key in your server .env file, and your hub's uuid has been added to the project, the hub(s) should be able to pull down the list of badges/beacons from the server and start collecting data

If your app keys don't match, that would explain why you're getting the "Error reading badges list from server". Not adding the hub to the project would probably also cause that to happen.

Cheers!

Jordan

If you've already done that, just use the username/password 

[Oren Lederman]

Just a short addition - you shouldn't get an error if you don't add any badges or location beacons to the project.

--
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/113e7aef-c09e-4d0d-8f9a-eded94140d70%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Scott Seidman]

SUCCESS!!  I did all the stuff you said, and I added one Member and no more error message. 

 I'm getting (on the hub)

Requesting devices from server

Updating devices list (1)

Updating beacons list (0)

Attempting to offload data to server

Scanning for members ...

Scanning for beacons...

I don't see any acknowledgement about finding a device, but I'm not sure I would see this on the hub side, and I'm not sure where to look on the server.

I'm a little foggy about the relationship between adding members on the host and the devices list on the hub.  What fields have to match??

[jjre...@gmail.com]

Nice!

If you have the badge that you added to the server turned on & close to the hub, you should see it showing up in your hub logs after the 'Scanning for members...' line. You will also be able to check for it in the project page (and a couple other places) on the server - every badge (or "member") has a "Last seen" time, which is the time that the badge was last picked up by the hub. If it's "(None)" it means it hasn't been picked up by a hub at all yet.

Re: the devices list vs the server - you should only ever need one or the other. If you have a server set up, then that is what provides the list of devices to the hub and the devices_list file is unused. The only time you use the devices_list file on the hub is if you are running it in standalone mode (i.e. without a server). Now that you have your server up and running, you don't need to worry about it.

[Scott Seidman]

Then on the server, when I enter a member badge, the Number must be the MAC address of the badge??  I guess I was assuming that the devices file was sort of a lookup table, and the number would be the badge number in that file?

[Jordan Reedie]

Ah, nope, they're totally unrelated. The 'Badge' value in the member table should be the MAC address of the badge. 

For some context : A 'Member' in the system originally represented a person, rather than a badge. A 'member' had a name, an email, and a Badge (which was identified by the MAC address). We don't really use the system in this way any more - we removed the 'email' field and we pretty much exclusively use 'Member' to represent a badge. Now, we use the 'name' field to give the badges a more readable label - usually an integer. It may be easier if you consider the 'Name' in the member table to be 'Label', and the 'Badge' field in the member table to be 'MAC Address'.

Hope this helps!

[Oren Lederman]

Let me add some more information on that, since it can be confusing. There are actually a few more fields you should be aware of. 

In the members table (in the server), there are the following fields:

• The number printed on the badge. This is just for convenience and bookkeeping purposes. I have sheets in which each number is associated with a MAC address so I can simply copy+paste the MAC. It has nothing to do with any other ID that you'll see in the system
• Name. This can be whatever you like. In my studies, I actually put the name of the person the badge was assigned to, and then in brackets I put the ID written on the badge, for example Oren Lederman (283). It helps keeping track of the badges. When we use the mobile app as a hub, we tend to put the number printed on the badge there for convenience 
• Key. Also referred to as member_key or key in our analysis pipleline. This is a unique identifier that we try to use everywhere for identifying a unique person using the badge. If, for example, someone looses a badge and is given a new one, you only need to enter the new mac address, and all the data will still be associated with the same key (makes life easier for the analysis...)
• Id. Also referred to advertisement_id (or other names, I get confused too). This is an internal ID that the badges use when they broadcast, and the IDs that the badge stores when it sees other badges. The ID is unique within each project, so we can keep it as a 2-byte number. The analysis pipeline converts these IDs to key using translation tables (or based on raw data, in older versions. the package supports both)
• Badge. That's just the mac address. If you assign a new badge to an existing person, just put the new MAC address here (It might take several minutes for the change to propagate) 
• Observed_id. This is used for monitoring, but you should worry about it too much. It's the id that the hub reports when it sees the badge in a scan. When you just add a badge to a  project and the hub sees it the first time, the ID that the badge broadcasts might be an old ID from an older project. After two rounds of scans, the observed_id should match the id. I added it when we made changes to the way badges are assigned it for monitoring purposes. You shouldn't worry about this
  
• 
  

--

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/9a7d361a-4935-4ded-a3e5-bc22d77f0d46%40googlegroups.com.

[Oren Lederman]

Actually, there are a couple of more fields worth knowing.

• Last seen - the last time the system saw a badge. Should update every time a hub scans for badges and the badge is within range
• Last voltage - last voltage seen by the system. Depending which batteries you are using, voltage under 2.6 or so means taht you might need to change batteries soon
• Last audio, last proximity - shows the last timestamp of data received from the badge. When the battery is very low, for example, you'll see an updated "last seen" field, but you might not see data from the badge
• Last unsync - this is basically the last time a badge reset (last time the hub noticed that the badge didn't have it's internal clock set). When you turn on  a badge, this field will update the first time a hub sees the badge and sets the clock (usually within several minutes) When the battery runs low, the badge will start resetting and this field will update. As mentioned below, the dashboard actually have a better way of showing you that. 
• Last contacted - last time the system successfully connected to the badge (as opposed to just seen it).

These fields are pretty technical, but very useful for debugging system issues if you know what you are doing. However... it requires experience. That's why we created a dashboard a "dashboard" that can be used for monitoring the badges, beacons and hubs in the system. It makes it easier to tell if batteries are low, if badges disappeared and if hubs are down. Another useful feature is the number of resets - if the badge shows many resents in the lat several hours, it usually means that the battery is about to die. The link to this dashboard is under /dashboard/bash/ , for example, http://openbadgeserver.media.mit.edu/dashboard/dash/ 

We should really document the dashboard somewhere...

To unsubscribe from this group and stop receiving emails from it, send an email to rhythm-badges+unsubscribe@googlegroups.com.

[Scott Seidman]

This is all incredibly helpful.  Everything is working great.  The last question would be about meeting creation.  Everything seems to work without creating a meeting.  Are meetings done after the fact, or are they created in advance?  The meeting page asks for a log file.  Is that a log file to store things in, or is it a log file where things are already stored??

To unsubscribe from this group and stop receiving emails from it, send an email to rhythm-badge...@googlegroups.com.

[Oren Lederman]

You don't nee to create meetings. We use the same sever to support the mobile app hub, and that app creates meetings. Just ignore it :)

I'll answer the other question about the data later, need to finish up some stuff.