Home

RFC Platform

Rename device to driver

Everything is a driver

Rename interface to class

Underscore driver

Underscore is the driver containing all relevant info from the platform.

It's for internal purposes only

Topic: "_"

Structure attribute

must be retain in order to avoid needing a scan mechanism

JSON payload.

Info

Each level contains an optional "info" field with a any value. The purpose is to let the platform, and the developer of a driver to pass info to the clients. The format is entirely free, can be a JSON, a string, anything

Model and manufacturer are attributes

model and manufacturer become attributes of a driver. They are optional.

Example: If you have a driver for a SSH connection, they don't make sense anymore.

Tags

List of strings. Each tag represents an incentive for the app to understand better how to show/treat data.

We will have a fixed list of supported tags.

Introduction of tags for drivers

To help the app understand if the driver is an instrument, a service, or anything else, we can tag a driver.

This way, you could have a tag instrument, that would tell the app to expect these model and manufacturer attributes.

Could then help to show clear info for the user that this is an instrument etc.

Clear separation of tags and info

With this reflexion we could imagine that info could serve this purpose and be used to provide info like model and manufacturer.

But this is going to be very error prone if the format is not exactly correct. Tags are well-known, defined, and not flexible. Which is nice for apps, less implicit == less bugs.

Format

Top

{
    "drivers": {},
    "info": ""
}

Driver object

"driver_name": {
    "classes": {},
    "attributes": {},
    "tags": ["list_of_strings"],
    "info": ""
}

Class object

Classes can be nested

"class_name": {
    "classes": {}
    "attributes": {},
    "tags": ["list_of_strings"],
    "info": ""
}

Note that the JSON object for classes is exactly the same than driver.

Makes sense, classes are optional "virtual" representation of data, but a driver is a none optional representation of data too.

The key difference is that a driver is a top-level topic, it's mandatory, and classes cannot live on their own without a driver.

Attribute object

"attribute_name": {
    "type": "string",
    "mode": "RO",
    "settings": {},
    "info": ""
}

Type

String

List of known types (number, string, bool, JSON object), with array variants.

Mode

Either RW, RO, WO from the client perspective.

Settings

• Settings can be any json data
• Settings data depends on "Type", each "Type" expect a specific data format on Options

Type == enum

• settings=> [ "val1", "val2", "val3" ]
• a list of strings

"attribute_name": {
    "type": "enum",
    "mode": "RO",
    "settings": [ "val1", "val2", "val3" ],
    "info": ""
}

Type == si

• Options => { "unit": "A", "range": [0, 30] }
• parameters of the si

"attribute_name": {
    "type": "si",
    "mode": "RO",
    "settings": { "unit": "A", "range": [0, 30] },
    "info": ""
}