# iSeries IoT
---

## Overview

### About the iSeries service

flowchart TB
    Cloud(fa:fa-cloud Cloud)
    oAuth[oAuth Provider]
    PageReader(iSeries PageReader)
    Client(Client)
    
    Cloud <--> oAuth
    Cloud <--> Client
    oAuth <--> Client
    
    Cloud <---> Reader
    
    subgraph Client [Client]
        Phone(fa:fa-mobile Phone) 
        PC(fa:fa-desktop Computer)
    end
    subgraph Reader [Thales Hardware]
        PageReader(fa:fa-passport iSeries PageReader)
        FP(fa:fa-fingerprint Fingerprint Scanner)
    end

More detail

flowchart TB
    oAuth[oAuth Provider]
    
    subgraph Cloud [fa:fa-cloud Cloud Services]
        Rest(fa:fa-cloud REST service)
        DB[(fa:fa-database Database)]
        Mqtt(fa:fa-cloud Device Service)
        Q(fa:fa-cog Work Queues)
        
        Mqtt --> Q --> DB
        DB <--> Rest
        DB <--> Mqtt
    end
    
    subgraph Reader [Thales Hardware]
        PageReader(fa:fa-passport iSeries PageReader)
        FP(fa:fa-fingerprint Fingerprint Scanner)
    end
    
    subgraph Client [Client Devices]
        Phone(fa:fa-mobile Phone) 
        PC(fa:fa-desktop Computer)
    end
    Rest  <---> oAuth
    Rest <---> Client 
    Mqtt <---> Reader
    Client <--> oAuth
    
    style FP stroke-width:2px,stroke-dasharray: 4 4

### User Authorization Interface

> TODO:
> - Needs to be an oAuth Provider.

### The Device Control Interface

> TODO:
> - **MQTT**?
> - **AWS Devices**?

### The Device Capture Interface

> TODO: description, but workflow idea below.

    stateDiagram-v2
    Q: Add to Work Queue
    DB: Update Data Model
    POST: Device sends http POST of capture
    
    [*] --> POST
    POST --> Q 
    Q --> Processing
    state Processing {        
        PostProcess: Process Image
        [*] --> PostProcess
        [*] --> DB
        PostProcess --> DB
        DB --> [*]
    }
    Processing --> [*]

### The Data Model

The API is represented as a JSON document with top-level attributes of metadata, devices, and structures. Your products use this JSON document to interact with, and react to, devices and related state changes.

Structures represent physical structures in the real world. They serve as an organizing point for devices and store data for the building as a whole. Typically, a structure is a user place of business.

Devices represent physical devices (Document Readers) within a structure.

> **Key Point:** All devices belong to a structure. A structure can have many devices.

Every data element in the JSON document is addressable by URL (also known as "data locations"). Products can read and write to sections of this document and subscribe to changes. This subscription capability allows products to react in real time to changes made to the system, such as turning off a reader when a gate goes out of service.

> see [iSeries IoT API](Api.md)

> TODO:
> - **lambda service**?
> - **dynamoDB**?
> - Can we use redirects to seperate customer data by region etc?

### Intended state

The service stores the authoritative state of the system, and devices subscribe to changes. Modifying this state causes the service to push a change notification to all subscribers.

ecause this propagation has some delay and networks can be unreliable, the state observed by a product may not be the state currently observed by other products or the service. State is eventually synchronized as messages are transmitted between various products.

> **Key Point:** The state stored in the service is the current "intended" state of the system.

This document-oriented publish/subscribe model provides responsive application interactions.