# Hammer project
Locate lost objects in a workshop

## Word used

* Device : Is called a device each object that has to be located througt this system

* Ground station : 

* Operator :

* Main system : The server which receive the data and process it

## Device

### Hardware
ESP 32 or NRF51 or NRF52
Cheap hardware with with high availability and well documented with plug and play codes

Temp sensor ? 
Humidity sensor ?
Reed switch ? 

2 versions ? 
Button cell and lithium battery with more capacity 



### Functions 
Send message to groud station with optional sensor data and battery status
Send selected range in meters


### Choices 
Eddystone (over bluetooth). Developped by Google against Apple iBeacon protocol, this standard allow more data to be sent to the server than other methods
Still well supported by libraries
 
Not directly LoRa beacause of price. Same price than ESP32 or NRF5x but need an additionnal MCU

## Main system (aka brain)

### Hardware 
Linux computer, probably Single Board Computer (RPi like)

### Function
Provide User Interface 
Provide search fonction 
Store data
Show data on a map or a picture with scale (in order to show estimated position)
Display battery alerts
Provide external API 

### Database
To be discused 
A first idea can be the fllowing table, where every row is a device

```
| Id  | deviceId | averageTimestamp | Ground stations | sensor data |
|-----|----------|------------------|-----------------|-------------|
| INT | INT      |    timestamp     | STRING          | STRING      |
```
Here the issue is that the device itself does not send data
Instead, the grounds stations will send the data

Because the system may find other uses and, we may want to store string in sensor data column 
Moreover, we don't know how many ground stations will be seen
We may be somewhere between SQL and NoSQL, but maybe closer to SQL

A second idea is to sort by ground station. Each device will appear several time and sensor data will be hard to process and store in an intuitive way
```
| Id  | groundStation | timestamp | FoundDevices |
|-----|---------------|-----------|--------------|
| INT | INT           | timestamp | STRING       |
```


A third idea is to store everything in a JSON NoSQL way

In conclusion, what can be a good solution is the combination of two tables
One to find easily the last position of the sensor, updated with the last 5 ground stations and some sensor data

```
| Id  | deviceId | groundStation1           | gS2 | gS3 | gS4 | gS5 | Temperature | Battery lvl  | Humidity | Other  |
|-----|----------|--------------------------|-----|-----|-----|-----|-------------|--------------|----------|--------|
| INT | INT      | STRING, name + timestamp | "   | "   | "   | "   | INT         | INT          | INT      | STRING |
```

And one where a search can be more difficult for log purposes
```
| Id  | groundStation | timestamp | FoundDevices |
|-----|---------------|-----------|--------------|
| INT | INT           | timestamp | STRING       |
```