Close

Comms protocol

A project log for Medcheck

IoT pill dispenser with alerts to ensure compliance

bsuttonbsutton 05/17/2015 at 12:450 Comments

So there are a couple of questions around how we are going to communicate with the medcheck device.

In this case I'm not talking about NFC/RFID/bluetooth etc, but rather how the central medcheck site will talk with the medcheck device.

The reality with home routers is that the devices will all be nat'ed so we are unlikely to get direct access to a devices.

This may make several issues difficult. Firstly, we won't have direct ssh access to the device (despite a suggestion otherwise in a previous log) so how do we manage devices.

The obvious answer is that we need the device to call home. https is the obvious protocol for the device to send any notifications to us. We can also use a similar technique to long polling (without the long bit). The idea is to device check in on a regular basis (and may be initiated by a phone tap on the device) to see if the central system has any instructions for the device. This is often referred to 'phoning home' (no ET references please, it was a completely crappy film. Can anyone tell me why ET was able to fly to catch the ship at the end, but couldn't fly to catch the ship at the beginning. If he had only flown at the start it would have saved us all from having to sit through a complete load of rubbish).

So using the phone home concept the medcheck will use a two phase approach.

Every 'n' seconds the medcheck phones home by making a https request to the medcheck central server(s).

When a medcheck admin needs access to the medcheck device he instruct the medcheck server to return an 'ssh connect' command to the device.

On seeing the 'ssh connect' command the device issues an ssh request such as:

sh -N -R <port>:localhost:22 <user>@cmdserverhttp://.medcheck.com

The 'ssh connect' command also sends a port and one time use 'user' account (actually we probably one to send an one time use certificate - need to do some research here). We don't want to give the device any real access to our systems see need to look into how we secure the ssh connection from the device.

Once the device connects to us we can then connect to the device by:

ssh -l piUser -p <port> localhost

So we now have a basic method of secure communications. We still need a means of authenticating the device. We can use the device's Mac address or its RFID (will it have one of theses) or do we need a public key.

The actual protocol over https can just be REST we don't need anything fancy.

Some likely commands

PUT: Error: <Error Code>, <Error Message>

PUT: Notification <Warning Code>, <Warning Message>

PUT: Notification <Notification Code>, <Notification Message>

GET: Command - used for the phone home process

Discussions