Add userID and projectID to Sensor registration event

[pmorrill]

We have updated the Motus api (v2.0) entrypoints for the sensor registration, so that they now accept both userID and projectID. I've updated the entry in the v 2.0 docs:

https://github.com/MotusDev/MotusAPI/blob/master/Motus_API_2.0.md

Let me know of concerns.

This change is in the beta server right now. EG:

https://beta.motus.org/api/receiver/register

And we will push it to the live server in the next couple of days. If you happen to have a sensor registration to be processed, and can insert these parameters into the request json structure, we will track the result.

[jbrzusto]

Does the userID have to be one with permissions for the projectID?
Most receivers get registered when they're put on the testing rack at
compudata.ca, before being shipped. At that point, I'm not going
to have either userID or projectID to supply with the API call.

There needs to be a way to register a receiver deployment separately from
just getting a deviceID for it, which is all I really need when the SGs
self-register.

We could assign compudata a motus userID and projectID, and just use
those if the intial self-registration by the SG comes from compudata's
network.

[pmorrill]

Yes: the userid is meant to be the one associated with the specific project. I will let Denis chime in here I guess. I can't say that i really 'get' the registration steps!

BTW: we will continue to support the receiver deployment function, where these parameters can be added as well.

[denislepage]

It's useful to know (about compudata). Any chance that the process at compudata can be modified to include those details? I'm not sure I understand the current flow. Compudata connects to SG data, which then registers with Motus? Is that something you (we) have to initiate, or something that CD does?

If there is a way to link those units to a Motus user and/or Motus project ID right at the source, then I think that would resolve the question of the initial registration and link between units and projects, and do away with the need for adding a user-driven process upon deployment, which is something I have been keen to resolve for a while. It would at least work for new receivers coming out of Compudata, but not for those already in operation being transferred between projects.

As Paul says, the deployment API will continue to accept a project ID, so the new feature is really only an alternative way to assign a receiver to a project without having to send a full deployment.

[jbrzusto]

It's nothing particular to compudata at the moment - anyone who builds an SG and installs one of
our software releases on it just has to plug an ethernet cable into it and the unit will connect to our server and self-register. That means it gets a set of ssh keys and a unique port assignment. From then on, that unit can only connect using those keys, and only to a locked-down ssh server listening on port 59022
that lets the receiver do two things:

• push live parameter changes, gps fixes, and detections of tags in the onboard database to our server
• map the unique port on our server back to the SG's own ssh server port, so that:
  • our server can sync data from the SG
  • users can view the SG's web interface from anywhere
  • we can ssh into the SG itself for troubleshooting.

Only the "sync" function feeds anything into the motus data stream; the rest is for low-latency status
display.

Some receivers run a version of the software that sends UDP datagrams instead of establishing a
TCP port, to keep cell modem bandwidth and power consumption to a minimum. The datagrams are signed using the credentials from registration, and we run another
server (program) that listens for those datagrams, verifies their signature, and when valid, records
them and used to optionally post them to twitter. Twitter now
refuses access despite having agreed to it a few years ago, but there are better ways to go anyway.
That also has not been feeding into the motus data stream.

Obviously, bits and pieces have been added as users have requested them, so the functionality is
spread among various paths. It all needs reorganization and streamlining.