Application Schemas
This document describes schema files that you will write while developing applications.
Application schemas are the following three:
- Setting Schema: the schema of application configs to fit its operating environment (
setting_schema.json) - Data Schema: the schema of data sent as Act Log (
data_schema.json) - Manifesto: a description of resources needed at runtime
By creating act_settings.json you can test your data schema.
setting_schema.json
A Setting Schema defines a format of configurations within an application.
Applications can use files that conform to the schema using the environment variable ACT_SETTINGS_PATH.
At the application start-up, ACT_SETTINGS_PATH is bound to the JSON file path, then it is accessed like an ordinary JSON file.
The setting schema specifies the JSON described above. You have to write it on setting_schema.json with the JSON Schema[^json schema].
For example, the following schema:
{
"$schema": "https://actcast.io/schema/v7/setting_schema_schema.json",
"type": "object",
"properties": {
"display": {
"title": "display",
"description": "output video to HDMI display",
"type": "boolean",
"default": false
},
"threshold": {
"title": "probability threshold",
"description": "notify when over this threshold",
"type": "number",
"default": 0.9,
"minimum": 0.0,
"maximum": 1.0
}
},
"required": [],
"propertyOrder": ["display", "threshold"]
}is conformed by the following JSON:
{
"display": true,
"threshold": 0.7
}This JSON will be passed to applications.
Items available in the setting schema
The following fields are available in the setting schema.
| Field name | Type | Required? | Content |
|---|---|---|---|
$schema |
string | Yes | Specify the schema of this JSON Schema |
type |
string | Yes | Only "object" is allowed |
properties |
object | Yes | Specify each property of the setting |
required |
array | Yes | Specify required properties |
propertyOrder |
array | No | Specify the order in which properties are displayed on the Web UI |
Write "https://actcast.io/schema/v7/setting_schema_schema.json" to $schema, "object" to type.
When propertyOrder is omitted, propertyOrder will be inserted when uploading to Actcast, in the order of appearance in properties.
properties
The following items are available in properties.
| Field name | Type | Required? | Content |
|---|---|---|---|
description |
string | Yes | Description of the field |
descriptions |
object | No | Description of the field in languages other than English |
type |
string | Yes | Type of the field |
title |
string | No | Name of the field |
default |
No | Default value used when the field is omitted | |
minimum |
number | No | (Only when type is number) Minimum value of the field |
maximum |
number | No | (Only when type is number) Maximum value of the field |
minLength |
number | No | (Only when type is string) Minimum length of the field |
maxLength |
number | No | (Only when type is string) Maximum length of the field |
enum |
array | No | (Only when type is string) possible values of the field |
x-ui-type |
string | No | How to display in Web UI |
We recommend supplying title and default as far as possible, though they aren’t required.
descriptions
Write description in languages other than English in descriptions. Use language codes described in ISO 639-1 as property names and put the description in that language to values.
For example, the following value:
{
"ja": "これはフィールドの説明です",
"eo": "Ĉi tiu estas la ekspliko de la areno"
}type
The following items are available in type:
| Value | Description |
|---|---|
"boolean" |
Boolean |
"integer" |
Integer |
"number" |
number |
"string" |
String |
x-ui-type
The following items are available in x-ui-type:
| Value | Description |
|---|---|
"textarea" |
Textarea |
"password" |
Password |
data_schema.json
The data schema describes the format of the output of your application.
The data schema is used in Casts. For example, they are used to realize behaviors like “When the confidence score is greater than 90%, POST the data to somewhere”. Each line of the output of Actcast applications must conform with the data schema. The strings printed to standard output will be transferred to Actcast as the Act Log.
You have to write the data schema to the file data_schema.json in JSON Schema.
For example, the following value:
{
"$schema": "https://actcast.io/schema/v7/data_schema_schema.json",
"type": "array",
"items": {
"type": "object",
"properties": {
"prob": {
"title": "probability",
"description": "matching score",
"type": "number",
"minimum": 0.0,
"maximum": 1.0
},
"label": {
"title": "label",
"description": "the most matching class name",
"type": "string"
}
},
"required": ["prob", "label"]
}
}is conformed by the following JSON:
[
{
"prob": 0.3,
"label": "cat"
},
{
"prob": 0.7,
"label": "dog"
}
]The application outputs JSON like this.
Items available in the data schema
The following fields are available in the data schema.
| Field name | Type | Required? | Content |
|---|---|---|---|
$schema |
string | Yes | Specify the schema of this JSON Schema |
type |
string | Yes | "array" only |
items |
object | Yes | Specify the array items |
items
The following items are available in items
| Field name | Type | Required? | Content |
|---|---|---|---|
type |
string | Yes | Only "object" is allowed |
properties |
object | Yes | Specify each property of the data |
required |
array | Yes | Specify required properties |
properties
The following items are available in properties.
| Field name | Type | Required? | Content |
|---|---|---|---|
| description | string | Yes | Description of the property |
| descriptions | object | No | Description of the property in languages other than English |
| type | string | Yes | Type of the property |
| title | string | No | Name of the property |
| enum | array | No | (Only when type is string) possible values |
| items | object | No | (Only when type is array) the schema of the items of the array |
| properties | object | No | (Only when type is object) the schema of object |
In both items and properties, you can write the contents of items and properties recursively.
descriptions accepts the same content as in Setting Schema.
type
The following items are available in type:
| Value | Description |
|---|---|
"boolean" |
Boolean |
"integer" |
Integer |
"number" |
number |
"string" |
String |
"array" |
array |
"object" |
object |
act_settings.json
The act_settings.json file in the current directory is automatically transferred and then used by the application.
act_settings.json must follow the JSON schema file setting_schema.json.
The following command validates act_settings.json, setting_schema.json and data_schema.json.
$ actdk validate-jsonactdk run also performs an equivalent validation.
manifesto/*.json
In the manifesto, you specify the resources needed at the application runtime. You can write different settings for each device. In that case, write them to different files.
At initialization, actdk generates some manifesto files.
For example, default.json, as shown below, is the standard setting applied to all Raspberry Pis with VideoCore IV and allows access to the camera, VideoCore, and no special network.
{
"boards": [
"RSPi1A",
"RSPi1B",
"RSPi1APlus",
"RSPi1BPlus",
"RSPi2B",
"RSPiAlpha",
"RSPiCM1",
"RSPi3B",
"RSPiZero",
"RSPiCM3",
"RSPiZeroW",
"RSPi3BPlus",
"RSPi3APlus",
"RSPiCM3Plus",
"RSPiZero2W"
],
"devices": [
{
"type": "camera",
"device": ["/dev/video0"]
},
{
"type": "videocore",
"device": [
"/dev/vcsm",
"/dev/vcio",
"/dev/vc-mem",
"/dev/vchiq",
"/dev/gpiomem"
]
},
{
"type": "framebuffer",
"device": ["/dev/fb0"]
}
]
}boards
You can specify the following boards in "boards":
| notation | description |
|---|---|
RSPi1A |
Raspberry Pi 1 Model A |
RSPi1B |
Raspberry Pi 1 Model B |
RSPi1APlus |
Raspberry Pi 1 Model A+ |
RSPi1BPlus |
Raspberry Pi 1 Model B+ |
RSPi2B |
Raspberry Pi 2 Model B |
RSPiAlpha |
Raspberry Pi Alpha (early prototype) |
RSPiCM1 |
Raspberry Pi Compute Module 1 (CM1) |
RSPi3B |
Raspberry Pi 3 Model B |
RSPiZero |
Raspberry Pi Zero |
RSPiCM3 |
Raspberry Pi Compute Module 3 (CM3) |
RSPiZeroW |
Raspberry Pi Zero W |
RSPi3BPlus |
Raspberry Pi 3 Model B+ |
RSPi3APlus |
Raspberry Pi 3 Model A+ |
RSPiCM3Plus |
Raspberry Pi Compute Module 3+ (CM3+) |
RSPi4B |
Raspberry Pi 4 |
RSPiCM4 |
Raspberry Pi Compute Module 4 |
RSPiZero2W |
Raspberry Pi Zero 2 W |
At the application launch, the Actcast device agent checks the boards of manifesto/*.json files and determines which manifesto should be applied.
So, elements of boards of manifesto/*.json must not be duplicated.
(E.g., if both manifesto/a.json and manifesto/b.json contain RSPi4B in boards, it results in an error.)
devices
The "devices" can be a list of devices required by the application. The elements of the list are described as objects with the following fields.
| Field name | Type | Required? | Default | Content |
|---|---|---|---|---|
type |
string | Yes | N/A | Type of requested device |
device |
array | Yes | N/A | A list of requested devices |
required |
bool | No | true | Existence of the device is required or not |
The following device types can be specified for "type".
"camera": Camera device"videocore": VideoCore"framebuffer": Frame buffer device"gpio": Device using GPIO pins"sound": Microphone or Speaker"other": Device that does not apply to the above.
The fact that required is true indicates that the device is required for the application to work. If a device is specified as required, the presence of the specified device file will be checked at the startup of the Act using that application.
If the corresponding device file does not exist, the Act installation will fail to launch with an error.
Here is an example.
"devices": [
{
"type": "camera",
"device": [
"/dev/video0"
],
"required": true
}
]As "/dev/video0" is set required:true in this settings, the presence of the device file will be checked at the startup of the Act.
networks
If you want to communicate with the outside, use the network manifesto, and your app will be able to communicate externally via the SOCKS proxy we provide.
See Network Manifesto for more detail.
allow_all_networks
This property can be specified when you want to allow the application to communicate with the outside without any restrictions.
The application will be able to communicate externally without going through the SOCKS proxy.
- When this setting is enabled, the settings of
networksare ignored. - Both TCP and UDP are allowed.
{
"version": 2,
"target_type": "raspberrypi-buster",
"boards": ["RSPi4B"],
"devices": [],
"allow_all_networks": true
}published_ports
This property can be listed ports to be published to the outside world.
This enables the application to run a server and access it from the outside.
To specify published ports, use an array of objects containing three fields: the port number used in the container (container_port), the port number actually used on the host side (host_port), and the protocol used (protocol).
- This property is only available when
allow_all_networksistrue. host_portmust be a number between 1024 and 65535.- 8000 is unavailable because it is reserved by actsim
protocolcan betcp,udp, andsctp.
{
"version": 2,
"target_type": "raspberrypi-buster",
"boards": ["RSPi4B"],
"devices": [],
"allow_all_networks": true,
"published_ports": [
{
"container_port": 8080,
"host_port": 8080,
"protocol": "tcp"
}
]
}New notation of manifesto/*.json
Actcast Agent version > 1.6.0 accepts the new notation of Manifesto (Manifesto V2). Major changes are:
versionfield has been addedtarget_typefield has been added- device file can be omitted in some
types in thedevicesproperty. - new device
typeofdisplayhas been added
You cannot use the former notation of Manifesto and Manifesto V2 at the same time.
Detailed notation is described below.
Example
{
"version": 2,
"target_type": "raspberrypi-buster",
"boards": [
"RSPi4B"
],
"devices": [
{"type": "camera"},
{"type": "videocore"}
]
}version
Input number in "version". This property is for future extension and it is always 2 in Manifesto V2.
target_type
Input the target type for the manifesto to apply to. Non-overwrapping multiple "target_type" can be specified for each board.
This property is for future extention and it is always "raspberrypi-buster" in Manifesto V2.
boards
You can write the same "boards" as Manifesto V1.Combination of "targe_type" and "boards" cannot be duplicated.
devices
The "devices" can be a list of devices required by the application. The elements of the list are described as objects with the following fields.
| Field name | Type | Required? | Default | Content |
|---|---|---|---|---|
type |
string | Yes | N/A | Type of requested device |
device |
array | No | N/A | A list of requested devices |
required |
bool | No | true | Existence of the device is required or not |
The following device types can be specified for "type".
| Type name | Are files omittable | Description |
|---|---|---|
"camera" |
Yes | Camera devices |
"videocore" |
Yes | VideoCore |
"display" |
Yes | Display |
"framebuffer" |
No | Framebuffer |
"gpio" |
No | Devices those use GPIO pins |
"sound" |
No | Mice/Speakers |
"other" |
No | Other devices |
When "device" is omitted, the Actcast Agent determines files to mount based on "type".Those files mounted are notified to the application via Device handling in Applications.
The fact that required is true indicates that the device is required for the application to work. If a device is specified as required, the presence of device files will be checked at the startup of the Act using that application.
If the corresponding device file does not exist, the Act installation will fail to launch with an error.
Here is an example.
"devices": [
{
"type": "camera",
"required": true
}
]As required is set true in this settings, the presence of the appropriate device files will be checked at the startup of the Act.
networks
See Network Manifesto for more detail.