Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Skey Network Ecosystem - a set of open source licensed tools that enable providers to delegate access to their IoT assets via blockchain.
Supplier - a service provider that, by design, has its own IoT platform that communicates with physical devices and provides the API needed to communicate with, for example with front-end applications such as administration panels and mobile applications.
dApp - Decentralised application on a blockchain network owned by the Supplier.
Oracle - Skey Network Ecosystem's set of tools for Suppliers, which includes Supplier API and Listener. The ecosystem creates a set of servers that are used to pull data from the Internet and store it on the blockchain in a smart contract form. These tools are intended to provide a bridge between the blockchain and the Supplier's IoT platform.
Supplier API - is one of Skey Network's components that allows the Supplier’s dApp to be managed. It allows for example:
creation of new accounts for devices in the blockchain, known as wallets
moderation of devices' metadata such as name, description, geolocation
management of the devices' keys ( creating, transferring, blocking, assigning expiry time).
Listener - One of Skey Network's Oracle components. Listens for an event in the Supplier's dApp and sends a command to the Supplier's IoT platform.
Data Service - A publicly available server that each Supplier can optionally deploy in its server infrastructure. This tool allows the implementation of advanced filtering, sorting and aggregation of data.
Skey Network Node - a server which stores a copy of the complete blockchain. Each Supplier maintains a blockchain network by deploying a Node Skey Network in its infrastructure.
Explorer - Skey Network’s block explorer. It is a developer's tool acting as a search engine for wallets' addresses or transactions. It allows the account balance, number of tokens held and transaction tracking to be viewed.
Key Manager - an administration panel for Supplier API, which the Supplier can optionally place in his server infrastructure. Suppliers can replace Key Manager with their own IoT Platform management tool and extend it with Supplier Api maintenance.
Device key - NFT token generated by the Supplier, using the Supplier API, for a certain device's wallet. Only users who have it in their wallet will be able to run scripts in the blockchain which are responsible for executing actions on the device.
Skey Network allows users to create and manage dApps. DApps(shorthand for “decentralised applications”) are scripts uploaded to a blockchain account allowing other accounts to perform actions on the dApp with invokable functions defined in the script.
Skey Network has created multiple dApps to ease the process of implementing blockchain capacities to your IoT devices.
The dApps are as follows:
Name | Type | Required | Value | |
---|---|---|---|---|
refill_amount
number
required
Amount to refill in Skeylets
supplier_<address>
string
“active”
Supplier allowed to refill
org_<address>
string
“active”
Organisation allowed to refill
The diagram above shows how the Skey Network Ecosystem works with multiple Suppliers. The applications are connected to each other through the blockchain. Suppliers have their own decentralised application - dApp - within this blockchain network. The dApp is managed using the Supplier API; optionally, this can be done using the control panel for the Supplier API - i.e. the Key Manager. If a Supplier wants to be fully integrated, it will need to deploy a Listener in its infrastructure to allow it to execute actions on its own devices from other Suppliers' applications. The overall solution forms Oracle's Skey Network Ecosystem.
Each provider may optionally use a publicly accessible server - Data Service - in its ICT infrastructure. This enables faster reading of information from blockchain.
In order to connect to Skey Network's technical blockchain, each Partner is recognised as a "provider" of a new service, who implements elements of Skey Network's architecture, such as:
REST API as an interface to manage the Supplier's main dApp
Listener, which listens for events from the Supplier dApp and at the appropriate moment sends a signal to the IoT cloud with the relevant command
Elements that make up the rest of the Oracle ecosystem, such as Supplier API and Key Manager.
After connection to the Oracle ecosystem, partners can communicate and transfer data across the blockchain network.
The tangential element between providers is blockchain and the device's keys and NFTs generated by the blockchain.
For proper functionality, each element is described with procedures to enable easy and intuitive integration of the Partner into the Skey Network ecosystem platform. Among the main procedures are, among others, the following processes:
creation of a user account, namely a wallet, from the access level of a dedicated application
adding an IoT device
generating and transmitting the Skey Network's key to the user application
Additionally, the Supplier API's key may have properties/information necessary for the service provider, such as:
the time during which the contract is valid. For example, access to a hotel room may be active from 16:00 until 10:00 the next morning
the date of expiry of the contract. For example, a car may be available for 24 hours
payment and method of payment.
The Skey Network standard can be used by the company to manage access to both assets and services - e.g. providing employees access to the company's office, as well as by individuals for their own needs - e.g. locking and unlocking the house or providing access to the house emergency services.
Functions are listed bellow:
This dApp can be used by Suppliers to manage Devices accounts on the blockchain. When dAppFather is defined and Supplier is added in the dAppFather, actions performed by users will be refunded up to an amount set in the dAppFather.
Name | Value | Description |
---|---|---|
device_<address>
string
Registered Device
device_counter_<address>
number
Actions counter for registered Device - created and updated automatically
org_<address>
string
Registered Organisation allowed to perform actions on Devices
dapp_father
string
Address to dApp Father - used for account recharge
Functions are listed bellow:
Carries out some action on device (tries to refill account on success).
keyID
- id of nft token
action
- action to be carried out
Valid key (timestamp, issuer)
Key whitelisted in device's wallet
Asset (key) in invoking user's wallet
[E1] Key not owned
- Key not found in user's wallet
[E3] Wrong key issuer
- Key issuer is other than Supplier
[E4] No such device
- There is no such device in Supplier dApp
[E5]Key not whitelisted
- Key is not whitelisted in device's data
[E6]Device not connected
[E7] Device not active
[E8] Key expired
[E19] Not a key
- there is no asset with given id
[E20] Not a device key
- there is no device info in key
Carries out some action on device using a Key owned by an Organisation (tries to refill account on success).
keyID - id of nft token
action - action to be carried out
keyOwner - address of Organisation owning the key
mobileId - mobile ID of User performing the action
Valid key (timestamp, issuer)
Key whitelisted in device's wallet
Asset (key) in invoking user's wallet
Account performing the action needs to be added to Organisation
User account and Mobile ID in Organisation must match
Organisation has to be added in Supplier data
[E1] Key not owned - Key not found in user's wallet
[E3] Wrong key issuer - Key issuer is other than Supplier
[E4] No such device - There is no such device in Supplier dApp
[E5] Key not whitelisted - Key is not whitelisted in device's data
[E6] Device not connected
[E7] Device not active
[E8] Key expired
[E9] Not permitted by organization - User invoking the function is not a member of the Organisation
[E10] Mobile id not set - User invoking the function does not have Mobile ID set in Organisation
[E11] Id mismatch - Mobile ID of User does not match Mobile ID set in Organisation
[E12] Organization not permitted - Organisation not added to Supplier
[E19] Not a key - there is no asset with given id
[E20] Not a device key - there is no device info in key
Transfers key to other user (DAppFather tries to refill both accounts on success).
recipient
- address of recipient
key as payment
- key to send
valid key (issuer, timestamp)
key in users wallet
[E3] Wrong key issuerr
- asset issuer is other than Supplier
[E8] Key expired
- timestamp in key description expired
[E15] Wrong payments count
- more or less than one asset provided as payment
Creates key for device if possible.
If no price is specified in the "key_price" entry, such a key cannot be purchased
Can only be purchased by the owner of the device ('owner' entry in the device)
A default token payment equal to <key_price> * <time in minutes>
is required
The validity of such a key is calculated from the date of purchase
deviceAddr
- address of device
duration
- time in minutes
price per minute defined in device
user is owner of device
the payment amount is equal
[E13] Not an owner
- device not owned by user
[E14] Wrong price
- wrong amount of asset
[E16] Wrong payment
- supported only native token
[E17] Wrong payment value, expected <value>
[E21] Price not specified in device
[E22] Owner not specified in device
[E1] Key not owned
[E2] Not permitted by key owner
[E3] Wrong key issuer
[E4] No such device
[E5] Key not whitelisted
[E6] Device not connected
[E7] Device not active
[E8] Key expired
[E9] Not permitted by organization
[E10] Mobile id not set
[E11] Id mismatch
[E12] Organization not permitted
[E13] Not an owner
[E14] Wrong price
[E15] Wrong payments count
[E16] Wrong payment - supported only native token
[E17] Wrong payment value, expected <dd>
[E18] Unknown asset id
[E19] Not a key
[E20] Not a device key
[E21] Price not specified in device
[E22] Owner not specified in device
Device dApp is a blockchain account representing a physical entity - an IoT device, car, gate, or something else connected to the Internet.
Functions are listed bellow:
Adds an existing NFT Key to device whitelist.
keyID
- id of NFT
Invoking wallet must be owner of device or main dApp
Key issued by Supplier dApp
[E102] Wrong key issuerr
- issuer of asset is other than Supplier
[E103] Not permitted
- user is not a device owner
[E104] This key is banned
- key is banned by Supplier
[E105] This key is already assigned
Data are listed bellow:
Data properties:
Data properties:
Data properties:
NOTE: all properties in Device details
and Physical address
are optional.
Key | Type | Required | Default value | |
---|---|---|---|---|
name
string
Name of the device
description
string
Device description
type
string
required
“device”
Type of entity
supplier
string
required
Supplier blockchain address
owner
string
required
Owner blockchain address
active
boolean
required
Flag signalling if Device is active
visible
boolean
required
Flag signalling if Device is visible
connected
boolean
required
Flag signalling if Device is connected
version
string
required
“1”
Device dApp version
lat
string
Device latitude
lng
string
Device longitude
alt
string
Device altitude
custom
object as stringified JSON
Custom Device properties
key_<assetId>
string - “active” or “inactive”
Key allowed to perform actions
details
Object as stringified JSON
Device details - see schema below
deviceType
Enum string
Device type
Supported values:
'car barrier' | 'human barrier' | 'elevator' | 'human' | 'mobile' | 'other'
deviceModel
string
Device model
additionalDescription
string
Additional description
assetUrl
string
URL to an optional asset(like an image)
url
string
URL related to the Device
contactInfo
string
Contact info to the owner of the Device
physicalAddress
object
Physical Address of the Device - see schema below
Key
Type
Description
addressLine1
string
Device address
addressLine2
string
Device address cd.
city
string
City
postcode
string
Postcode
state
string
State
country
string
Country
number
string
Building number
floor
string
Building floor
Updates data in device wallet.
List of actions written as string (max. 15 entries at once) in schema: action#type#key#value
. Types of action set/delete.
action
- set (create new/update old entry), delete (remove entry)
type
- type of entry (int/string/bool), skip for delete
value
- value of entry or delete#key, skip for delete
key
- key of entry
[E103] Not permitted
- user is not device's Supplier
As part of the popularisation of the Skey Network application, the blockchain account has been extended with features (dApp) to extend its usability. dApps in the SmartKey ecosystem are accounts not only for Suppliers but also for Organisations.
The Organisation account allows multiple users to use keys that are contained in that account. Access to the keys is secured through an ACL. A user can add themselves to the ACL by calling a method in the Organisation dApp attaching an activation token in the transaction.
An ACL (Access Control List) is a whitelist of wallet addresses that have access to Organisation keys.
The dAppFather in this case represents an account on the blockchain storing a list of all the Organisation audited and described decentralised applications.
Activation tokens
- these are licence tokens generated by the Organisation, giving you the ability to add your account to the Organisation's ACL. They are generated by the Organisation in any quantity and then distributed to end users’ wallets.
Data properties:
Key | Type | Required | Default value | Description |
---|---|---|---|---|
user_<address>
string
no
mobile id
Rgistered user, value is mobile Id, '?' when not set, otherwise device id string or wildcard '*'
user_note_<address>
string
no
encrypted note
Encrypted note about the account set by Organisation used for identification of blockchain addresses.
token_<assetId>
string
no
active
Activation token, value: 'active'/'inactive'
manager_<address> => <publicKey>
string
no
binary address of manager
Binary entry containing blockchain address and public key of a Manager
Functions are listed bellow:
activates organisation user, writes its mobile id
activation token
activation token must be whitelisted
mobile id must be string other than '?' and '*'
[E202] Wrong payments count - more or less than 1 payments attached
[E203] Wrong asset - wrong asset sent as payment
[E207] Forbidden id string - id string cannotcant be * or ?
[E208] Activation failed, token is inactivee - asset was deactivated
Removes key to device from organisation’s wallet
keyID - id of nft token
Invoked by owner of device or supplier
[E201] Not a key" - there is no token with given asset id
[E204] Not a device key - asset is not a device key
[E205] Not an owner address - owner address in token is incorrect
[E206] Owner not specified in device - device has no owner address specified
[E209] Not permitted - if invoking user is not supplier/owner of device
Sets mobile id if user is added to organisation and has no id specified.
user written in organisation with '?' as mobile id
[E207] Forbidden id string - mobile id is forbidden string (?/*)
[E210] Not a memberr - organisation has no such user
[E211] Cant change existing id - id was already set
Functions are listed bellow:
Transfer Activation Token(s) as a Manager.
manager
- Address of Manager performing the action
token
- Asset ID of Activation Token to send
recipient
- Address of Activation Token Recipient
amount
- Amount of Activation Tokens to send
Manager has to be added to the Organisation
Amount has to be a positive number
Organisation has to have sufficient amount of Activation Tokens on it’s wallet
[E209] Not permitted
[E212] Incorrect user address
[E213] Not an asset
[E214] Not issued by organisation
Adds user to organisation as a Manager
mamanager
- Address of manager performing the action
address
- Address of user to add
mobileId
- Mobile ID of user to add
note
- Note about added account. For security reasons we recommend encrypting this value beforehand. It will be stored on the blockchain as-is. Provide an empty string to not set one.
Manager has to be added to the Organisation
Address cannot be added already
Mobile ID needs to be unique
[E209] Not permitted
[E212] Incorrect user address
[E201] Not a key
[E202] Wrong payments count
[E203] Wrong asset
[E204] Not a device key
[E205] Not an owner address
[E206] Owner not specified in device
[E207] Forbidden id string
[E208] Activation failed, token is inactive
[E209] Not permitted
[E210] Not a member
[E211] Cant change existing id
[E212] Incorrect user address
[E213] Not an asset
[E214] Not issued by organization
Required packages: nodejs, npm (prefered instalation via nvm)
Clone repository
Navigate to iot-worker
folder
Install dependencies npm install
Copy .env.example as .env, and modify its contents as in Configuration file section
Copy device config config.json.example
as config.jsonm
and modify it's contents as in Devices configuration file section
Run command npm start
Execute command in project directory:
docker build -t supplier-listener-iot-worker .
Result should look like:
(...)
Successfully built IMAGE_ID
To run image execute (config.json and docker env as file or params are required):
docker run -i -v `pwd`/.config.json:/app/config.json <place docker envs here> IMAGE_ID
When config.json
file is in another location, provide absolute path to it on left side of ":" (instead of `pwd`/config.json
, where pwd returns actual working directory, eg /user/home/xyz/listener/config.json
).
If there is no env specified, Iot Worker will stop execution.
All-in-one command which will build image and run it (ensure that path to config is correct)
docker run -i -v `pwd`/config.json:/app/config.json <place docker envs here> `docker build -q .`
Running from sources – It will expect .env
and config.json
in project folder.
Running in docker container - path to config.json
file should be provided as described in this section, including the rest of env specified as docker env file or parameters.
Token for IoT:
IOT_PLATFORM_TOKEN='abcdef...'
Url for sending command to devices where, for example {device_address} will be replaced with device's blockchain address (more variables are available as specified below)
IOT_PLATFORM_URL='http://localhost:3000/{device_address}/commands'
Method used for requests:
IOT_METHOD='POST'
Variables available for url/json
device_address
- blockchain address of device
action_name
- name of requested action (command)
key_id
- id of key asset
function_name
- name of used function
device_model
- type of device
Redis server address
REDIS_HOST="127.0.0.1"
Redis server port
REDIS_PORT="6379"
Devices configuration is defined in config.json in JSON format (remove comments before use).
"devices"
– array of supported devices
"supportedAction"
– array of supported action for device
"json"
- json for request
"jsonByAction"
- request json can be dependent on action:
"action"
- action to override json
"json"
- json to be used instead
Example of configuration:
Data Service is a publicly available server that each Supplier can optionally use in its server infrastructure. This tool allows the implementation of advanced filtering, sorting and aggregation of data.
Data Service functionality is based on communication via gRPC (https://grpc.io/ ). Skey nodes send information to subscribed data service workers about any changes happening on blockchain.
Data Service consistconsists of two elements connected to the same database:
Data Service Worker - its task is to subscribe to gRPC and filter relevant blockchain data and handle changes. It filters and reacts to state updates such as transfers, issuing new keys, dApp invocations, data entries etc. Changes are saved in a structured form in the mongoDB database.
Data Service API - an application used to retrieve data from a database. It has no possibility to modify or create new documents. It uses graphQL interfaces to create multiple queries and pipelines for example fetching the list of devices that the selected address has access to.
The communication is authenticated using the api key added as the http header - for example:
{ "x-api-key": "superhiper=secret=key" }
Run with docker
docker compose build && docker compose up
Environment variables
Property | Default value | Description |
---|
APP_PORT | 3000 | Port used by the server |
APP_DEFAULT_PAGINATION_LIMIT | 25 | Number of items returned by default |
APP_MAX_PAGINATION_LIMIT | 1000 | Maximal number of items returned |
APP_REQUIRE_API_KEY | true | Whether app should require api key |
APP_API_KEY | super-secret-api-key | Api key |
DB_NAME | admin | Database name |
DB_HOST | localhost | Database host |
DB_PORT | 27017 | Database port |
DB_USERNAME | root | Database username |
DB_PASSWORD | password | Database password |
Run with docker
Environment variables
APP_LOGS
true
Enable logging
APP_MIN_HEIGHT
1
Blockchain height from which worker starts synchronizing data
APP_TRACK_ALL_ACCOUNTS
true
Synchronize data for all blockchain accounts, even those that are not smart contracts
BLOCKCHAIN_DAPP_FATHER_ADDRESS
Address of blockchain account containing list of approved addresses
BLOCKCHAIN_NODE_URL
http://localhost:6869
Blockchain node url
BLOCKCHAIN_CHAIN_ID
R
Blockchain chain id
DB_NAME
admin
Database name
DB_HOST
localhost
Database host
DB_PORT
27017
Database port
DB_USERNAME
root
Database username
DB_PASSWORD
password
Database password
GRPC_HOST
localhost
Blockchain node GRPC service host
GRPC_PEERS
List of additional grpc nodes
GRPC_UPDATES_PORT
6881
Port of GRPC updates services
GRPC_API_PORT
6877
Port of GRPC api services
REDIS_QUEUE
default
Name of redis queue
REDIS_HOST
localhost
Redis host
REDIS_PORT
6379
Redis port
TEST_DAPP_FATHER_SEED
Dapp father address used for testing
TEST_GENESIS_SEED
Seed for address with tokens used for testing
TEST_INTEGRATION_DELAY
1200
Delay in milliseconds used for some tests
id - String!
begin - Float!
- Unix timestamp in milliseconds pointing to date when to start the chart. For example,to draw a monthly chart starting in January 2021, use 1609459200000.
n - Int!
- Number of objects to be returned for chart. For example, to draw a monthly chart, use 30.
length - Float!
- Amount of time in milliseconds from one time period to another. For example, to draw a monthly chart, use 1 day (86400000 milliseconds).
[DeviceChartDocument!]!
{"id": "abc123", "begin": 987.65, "n": 987, "length": 123.45}
Required packages: nodejs, npm (prefered instalation via nvm):
Clone repository
Navigate to iot-worker folder
Install dependencies npm install
Copy .env.example
as .env, and modify its contents as in Configuration file section
Run command npm start
Execute command in project directory:
docker build -t supplier-listener-unique-worker .
Result should look like:
(...)
Successfully built IMAGE_ID
To run image execute (config.json and docker env as file or params are required):
docker run -i <place docker envs here> IMAGE_ID
If there is no env specified Unique Worker will stop execution.
All-in-one command which will build image and run it (ensure that path to config is correct):
docker run -i <place docker envs here> `docker build -q .`
Running from sources - It will expect .env & config.json in project folder.
Running in docker container - path to config.json file should be provided as described in this section, including rest of env specified as docker env file or parameters.
Redis server address
REDIS_HOST="127.0.0.1"
Redis server port
REDIS_PORT="6379"
order - String
- Order in which records will be sorted. Correct values are "asc
" for ascending and "desc
" for descending . Default = "asc
"
orderBy - String
- Field name used for sorting. For example { order: "desc
", orderBy: "updatedAt
" } returns most recently updated items first
search - String
- Used to search for match in multiple fields. It appends a new field (score) to returned items. For example query devices { search: "teltonika
", order: "desc
", orderby: "score
" } returns devices that have "teltonika" string in one of the fields and places best matches first
skip - Int
- Used for pagination. Indicates how many records starting from the first one should be skipped. For example, { skip: 20, take: 10 } equals 3 page and 10 items for each page. Default = 0
take - Int
- Used for pagination. Indicates how many records should be returned in the current request. For example, { skip: 20, take: 10 } equals 3 page and 10 items for each page. Default value is 25. Maximum amount is 1000 . Default = 25
filter - DevicesFilter
Default = {}
geoSearch - GeoSearchInput
- Returns list of devices that are inside of selected rectangle. For example, for points [lat:49, lng: 16] as bottomLeft and [lat:54, lng:24] as upperRight, it's going to return all devices in Poland
geoSearchCircle - GeoSearchCircleInput
- Returns list of devices within radius of a selected point
keysOwner - String
- Returns list of devices to which an address has keys. For example, User with address user_1 is the owner of keys key_1 and key_2, key_1 is for device_1 and key_2 is for device_2. There are also user_2, device_3 and key_3. The method will return [device_1, device_2]. This is helpful when user need a list of devices he can interact with
includeRemoved - Boolean
- By default the list will not include Devices which have been removed by the Supplier. To also get Devices removed, set this flag to true. Default = false
Returns a PaginatedDevices!
id - String!
begin - Float!
- Unix timestamp in milliseconds establishing the date when to start the chart. For example,to draw a monthly chart starting in January 2021 use 1609459200000
n - Int!
- Number of objects to be returned for chart. For example, to draw a monthly chart, use 30
length - Float!
- Amount of time in milliseconds from one time period to another. For example, to draw a monthly chart, use 1 day (86400000 milliseconds)
[KeyChartDocument!]!
{"id": "abc123", "begin": 987.65, "n": 123, "length": 123.45}
order - String
- Order in which records will be sorted. Correct values are "asc" for ascending and "desc" for descending . Default = "asc
"
orderBy - String
- Field name used for sorting. For example { order: "desc", orderBy: "updatedAt" } returns most recently updated items first
search - String
- Used to search for match in multiple fields. It appends a new field (score) to returned items. For example query devices { search: "teltonika", order: "desc", orderby: "score" } returns devices that have "teltonika" string in one of the fields and places best matches first
skip - Int
- Used for pagination. Indicates how many records starting from the first one should be skipped. For example, { skip: 20, take: 10 } equals 3 page and 10 items for each page. Default = 0
take - Int
- Used for pagination. Indicates how many records should be returned in the current request. For example, { skip: 20, take: 10 } equals 3 page and 10 items for each page. Default value is 25. Maximum amount is 1000 . Default = 25
filter - EventsFilter
Default = {}
PaginatedEvents!
order - String
- Order in which records will be sorted. Correct values are "asc" for ascending and "desc" for descending . Default = "asc
"
orderBy - String
- Field name used for sorting. For example { order: "desc", orderBy: "updatedAt" } returns last updated items first
search - String
- Used to search for match in multiple fields. It appends a new field (score) to returned items. For example query devices { search: "teltonika", order: "desc", orderby: "score" } returns devices that have "teltonika" string in one of the fields and places best matches first
skip - Int
- Used for pagination. Indicates how many records starting from the first one should be skipped. For example, { skip: 20, take: 10 } equals 3 page and 10 items for each page. . Default = 0
take - Int
- Used for pagination. Indicates how many records should be returned in the current request. For example, { skip: 20, take: 10 } equals 3 page and 10 items for each page. Default value is 25. Maximum amount is 1000 . Default = 25
filter - KeysFilte
r - Default = {}
PaginatedKeys!
id - String!
begin - Float!
- Unix timestamp in milliseconds indicating the date when to start the chart. For example, to draw a monthly chart starting in January 2021 use 1609459200000
n - Int!
- Number of objects to be returned for chart. For example, to draw a monthly chart, use 30
length - Float!
- Amount of time in milliseconds from one time period to another. For example, to draw a monthly chart, use 1 day (86400000 milliseconds)
[SupplierChartDocument!]!
{"id": "xyz789", "begin": 123.45, "n": 987, "length": 123.45}
skip - Int
- Used for pagination. Indicates how many records starting from the first one should be skipped. For example, { skip: 20, take: 10 } equals 3 page and 10 items for each page. . Default = 0
take - Int
- Used for pagination. Indicates how many records should be returned in the current request. For example, { skip: 20, take: 10 } equals 3 page and 10 items for each page. Default value is 25. Maximum amount is 1000 . Default = 25
input - String!
SearchResults!
{"skip": 0, "take": 25, "input": "xyz789"}
order - String
- Order in which records will be sorted. Correct values are "asc" for ascending and "desc" for descending . Default = "asc
"
orderBy - String
- Field name used for sorting. For example { order: "desc", orderBy: "updatedAt" } returns most recently updated items first
search - String
- Used to search for match in multiple fields. It appends a new field (score) to returned items. For example query devices { search: "teltonika", order: "desc", orderby: "score" } returns devices that have "teltonika" string in one of the fields and places best matches first
skip - Int
- Used for pagination. Indicates how many records starting from the first one should be skipped. For example, { skip: 20, take: 10 } equals 3 page and 10 items for each page. Default = 0
take - Int
- Used for pagination. Indicates how many records should be returned in the current request. For example, { skip: 20, take: 10 } equals 3 page and 10 items for each page. Default value is 25. Maximum amount is 1000 . Default = 25
;
filter - SuppliersFilter
Default = {}
PaginatedSuppliers!
The Boolean scalar type represents true or false.
A date-time string at UTC, such as 2019-12-03T09:54:33Z, compliant with the date-time format.
id - ID!
address - String!
supplier - String
owner - String
name - String
description - String
lat - Float
lng - Float
alt - Float
location - Location
distance - Float
- Returned only when fetching Devices from a circle using geoSearchCircle. This is the distance between the Device and a chosen point measured in meters.
visible - Boolean
active - Boolean
connected - Boolean
removed - Boolean
details - Details
custom - String
whitelist - [String!]!
createdAt - DateTime
updatedAt - DateTime
whitelisted - Boolean
score - Float
The Float
scalar type represents signed double-precision fractional values as specified by IEEE 754.
987.65
The ID scalar type represents a unique identifier, often used to refetch an object or as key for a cache. The ID scalar type appears in a JSON response as a String; however, it is not intended to be human-readable. When expected as an input type, any string (such as "4") or integer (such as 4) input value will be accepted as an ID.
issuer - String
owner - String
name - String
device - String
burned - Boolean
deviceWhitelisted - Boolean
- Filter keys by Supplier device whitelist. For example, if set to true, this will return only keys for devices that are whitelisted by their Suppliers. If set to false,it will return only keys for devices that are not whitelisted by their Suppliers.If not given, it's not filtered at all.
The String scalar type represents textual data, represented as UTF-8 character sequences. The String scalar type is most often used by GraphQL to represent free-form human-readable text.
Skey Network Key Manager is a control panel dedicated to service suppliers. It allows access keys for devices to be generated and IoT devices which use our connector to be managed.
The operator of the applications and the systems that provide its services can decide on their parameters. In other words, Key Manager creates smart contracts containing parameters such as: the time of access to sensors or devices, the date of expiry of the contract (access to the device), the cost of access, user verification, and other parameters relevant to a given service.
A service supplier (resource owner), for example a hotel, creates a model contract which it puts up for sale. A given contract is a digital equivalent of a service delivered by the supplier, for example room rental. In creating the contract, the supplier will select basic parameters, such as the period of access to the service, e.g. hotel room, and the method of user verification, e.g. hotel guest. The contract will be visible in the wallet for managing basic keys or paid services. Keys can be created based on the economic parameters of the supplier, so the key can be paid for or free.
Creating a device using Key Manager is done directly through the Supplier API using the POST /devices endpoint and involves generating a blockchain address, uploading the appropriate script to this address and storing the information about it in the Supplier dApp. The new device address must then be stored in the Supplier IoT Platform and paired with a physical device, such as a lock on a hotel room door. This pairing is necessary because further identification will only take place through the blockchain address, and the IoT Platform has to see which physical device is involved.
Supplier API is one of the Skey Network's components that allows the Supplier’s dApp to be managed. It allows for example:
the creation of new accounts for devices in the blockchain, known as wallets;
moderation of devices' metadata such as name, description, geolocation;
management of the devices' keys ( creating, transferring, blocking).
Documentation, usage examples and error codes can be found at https://demo.supplier-api.SkeyNetworkplatform.com/api_docs/ . The analysis of documentation should start with the tools, in particular /utils/setup.
Listens for an event in the Supplier's dApp and sends a command to the Supplier's IoT platform.
It consists of three elements:
Blockchain Worker - Parses blockchain transactions, supplies data for Iot Worker or Unique Worker.
IoT Worker - Builds requests to IoT server, uses data from queue supplied by Blockchain Worker or Unique Worker (filters unique data from many Blockchain Workers).
Unique Worker - Filters unique actions by transaction id between Blockchain Workers and Iot Workers.
The idea of Skey Network, as a communication and access control standard, is to give NFT tokens real, physical value and usability throughout world. The key to a Skey Network device should be a combination of three different technologies packaged in a form that is transparent to the user.
The first technology is BoT (Blockchain of Things). BoT is used to connect an IoT device’s unique IT record to the Blockchain. IoT devices can be installed in all kinds of physical objects such as cars, gates, homes, parking lots, offices, parcel locker systems, and so on.
The second technology is the Oracle system. Skey Network uses the second generation Oracle system. It’s goal is to connect IoT platforms with blockchain state.
The third technology, used to create the access token is the Smart Contract conditions. These conditions can be decided by the person/company/institution issuing the contract with various levels of customization. These conditions include (but are not limited to): contract expiration time, time of access, price, rules for user verification and deposit amount, and others.
The result of these technologies’ usage is a platform that connects physical devices to blockchain and creates a reliable protocol to grant permissions to access those devices.
This value can then be sold using a simple website or application, traded on exchanges, or used to build new business models.
From a business perspective, NFT access tokens are unique non-destructible keys created from a combination of the above technologies. Such keys can then be:
rented
sold
replaced
used to create new business models based on the Sharing Economy
This approach has taken NFT tokens to a completely new ideological level, giving them usability and specific functionalities.
Additionally, each NFT access key has a supplier-defined expiration date, after which it loses its functionality. The cost of generating an NFT access key depends on its lifetime, which is counted per minute. The longer the lifetime, the higher the cost of generating the key.
This document is a description of the world of Skey Network as a standard for communication and access control for services based on device communication.
Skey Network's vision is to lay the foundations for the smart cities of the future. To do that, we are developing a range of products, partnerships, and technical solutions. These products use the universal BoT (Blockchain of Things) system to connect devices, technologies, systems, and clouds to blockchain platforms.
The Skey Network project is largely focused on automatization of the billing process and access to services. All operations, beginning with reservations and ending with access to facilities, are mostly implemented using simple systems such as sensors or electronic locks. They can easily be connected to the Skey Network Ecosystem, which in this case, acts as a communication bus for the IoT clouds of different suppliers. These devices are becoming increasingly common in our modern world. Skey Network is focused on devices that give access to resources such as gates, cars, car parks, parcel lockers, flats, buildings in terms of widely understood access control. However, there are many more uses and they can be limited only by our creativity.
Skey Network’s products are more than just an application for each of our partners. Our solutions are a universal base on which our partners and later other companies or individuals can build their own applications using the products available through the Skey Network Ecosystem. This allows for a wider implementation of SmartKey in various business models building a global marketplace of services, including access control.
Skey Network will provide the universal platform on which partners, companies, and individuals can build their own applications. This will allow for wide implementation of Skey Network in various business models. By building bridges between the on-chain and off-chain world, we allow blockchain and smart contracts to access off-chain assets, making them far more powerful and interoperable.
Required packages: nodejs, npm (prefered instalation via nvm)
Clone repository
Navigate to blockchain-worker
folder
Install dependencies npm install
Copy .env.example
as .env, and modify its contents as in Configuration file section;
Run command npm start
Execute command in project directory:
docker build -t supplier-listener-blockchain-worker .
Result should look like:
(...)
Successfully built IMAGE_ID
To run image execute (docker env as file or params is required):
docker run -i <place docker envs here> IMAGE_ID
If there is no env specified Blockchain Worker will stop execution.
All-in-one command which will build image and run it (ensure that the path to config is correct).
docker run -i <place docker envs here> `docker build -q .`
Running from sources
- it will expect .env in project folder.
Running in docker container
- it will expect env specified as docker env file or parameters.
dApp monitored for action requests:
DAPP='3NBPqqjDH2eYmoHeXNPnHhLvA7D4UDQXQcx'
Functions called in dApp in order to make action on device (separated by "|"):
DAPP_FUNCS='deviceAction|deviceActionAs'
Url to node used for monitoring state of dApp:
NODE_URL='
https://nodes-testnet.wavesnodes.com
'
Number of blocks over parsed one higher values are safer but slower.
SAFETY_LEVEL=0
Checking interval for new transactions
CHECK_INTERVAL=1000
Blockchain updates extension port
NODE_GRPC_EVENTS_PORT='localhost:6881'
Grpc extension port
NODE_GRPC_PORT='10.0.0.7:6877'
Redis server address
REDIS_HOST="127.0.0.1"
Redis server port
REDIS_PORT="6379"