The meta_data Structure¶

The meta_data variable contains a complete definition of all of the features this module will provide. The structure is complex so we have broken it down into the main components.

Some notes on the data

The structure is a Python dict that is also used as json
All Boolean values must be quoted i.e. “true” NOT True

The ‘header’ section¶

This section contains basic information about the module and how it should be displayed in the installer and module manager.

Name	Description
name	The name of the module. Displayed in the module manager
description	Brief description of what he module does, this is displayed in the module installer and module manager
module	The module name allsky_XXXXX. Note the allsky_ must be present
version	The version of the module. This uses then MAJOR, MINOR,PATCH convention. i.e. v1.2.3
centersettings	If the module has a large amount of settings then set this to “false” to display the module dialog at the top of the screen. Setting it to “true” will vertically center the module dialog
testable	If the module can be tested, see later then set this to “true”. NOTE: At present no modules that process images can be tested
group	This is the group the module belongs to, this is used in the module manager to group like modules together
extradatafilename	(Optional )This is the name of the extra data file that any data generated by the module will be saved in. By convention it’s the module name with .json appended
events	These are the pipelines (flows) that this module can run in
experimental	(Optional) If set to “true” then the module will be flagged as experimental in the module manager
deprecation	This section allows control over the deprecation of a module. It can provide both warnings of an upcoming deprecation or a complete deprecation of a module
fromversion	(Optional) The version a deprecation will be advised from
removein	(Optional) The version the deprecation will happen in
notes	(Optional) Any notes related to the deprecation
replacedby	(Optional) The name of the module replacing the deprecated functionality
deprecated	“true” to deprecate a module, if “false” then the optional values above can be used

The ‘Extra Data’ section¶

This section defines what data the module will generate for use in the overlays. It also controls what data can be written to the database for use by the charting system.

The ‘databases’ section¶

Name	Description
enabled	(Optional) “true” if this module will write data to the database. Normally you would set this to true, typically on setting it to false when developing or testing
table	(Optional) If enable then this field IS required and contains the name of the table to write data to. The convention is the module name.
pk	(Optional) If enable then this field IS required and contains the name of the primary key for the database. This should always be 'id'
pk_source	(Optional) If enable then this field IS required and contains the variable that the primary key (id) will be obtained from, If omitted the last ime timestamp or current timestamp will be used
pk_type	(Optional) If enable then this field IS required and contains the primary key. Set this to ‘int’
Include_all	(Optional) If enable then this field IS required and determines if all extra data values are written to the database. If “false” then you can specify which data is written against the extra data fields definitions
time_of_day_save	(Optional) Determines how data is saved for each pipeline.

The ‘values’ section¶

This section defines all of the extra data that the module will generate for use in overlays. The information defined here is used throughout core Allsky to format and present the data. The section is a list of values, the table below just shows the available fields for a single value

Name	Description
Key	The name of the variable, generally prefixed with AS_
name	The variable as it will appear when added to an overly
format	The default format for the variable. See the section in the main Allsky documentation on formats for more details
sample	This is a sample value used in the Overlay manager, typically this is not needed as you can preview live data in the overlay manager
group	This the group the variable belongs to. This is used in the variable manager to group variables.
description	The description of the variable, used in the variable manager
type	The type of the variable. To find all of the available options look at the 'type' field on the 'Text Properties' editor in the overlay manager, diblue click on a field to display this
dbtype	(Optional). If writing this field to the database this specifies the type of column created
database
include	If the database is enabled but include_all is ‘false’ then setting this to ‘true’ will write this value to the database

The ‘arguments’ section¶

This is a list of all of the arguments the module requires along with their default values. This list MUST match the ‘argumentdetails’ section. If an entry exists in the ‘argumentdetails’ section but not here then It will not be available to the module.

This is the ‘params’ variable passed into the module function when the module is run.

The ‘argumentdetails’ section¶

This section defines all of the fields that are displayed in the module manager for a module.

The boilerpate module is setup to display all of the field types allowing you to see how they work

Each field has a type, this defines how the field appears. The fields are documented in the Available Fields section

The Boiler plate module implements each of the field types so can be used to see how they work.

Common field attributes¶

The following keys are available on all fields

Key	Description
required	“true” or “false” to indicate the field must be filled in
description	The label used when displaying the field
help	Help text displayed under the field
tab	The tab the field is displayed on
secret	This indicates that the value in this field will contain sensitive information. Any details entered into a ‘secret’ field are stored in a separate file away from the pipeline json files. If the field is a text type field then the value will not be visible in the module manager. A button is displayed allowing the field value to be displayed or hidden

Filtering¶

Filtering allows fields to be displayed or hidden based upon the value of another field. A good example of this is when selecting a sensor in the Environment module. Each sensor has different settings so rather than display all of them, which would make the modules dialog large and confusing only those relevant to the sensor are displayed.

To utilise this feature add the ‘filters’ section to a field. The filters section contains the following values

filter – The field that controls the filter

filtertype – Either ‘show’ or ‘hide’ This determines if this field will be shown or hidden based upon the value of the ‘filter’ field

values – A list of values from the ‘filter’ field that trigger the filtering on this field

So in the example below the ‘input’ field will be shown if the ‘type’ field is either DHT22, DHT11 or AM2302

"inputpin": {
    "required": "false",
    "description": "Input Pin",
    "help": "The input pin for DHT type sensors, not required for I²C devices.",
    "tab": "Core",
    "type": {
        "fieldtype": "gpio"
    },
    "filters": {
        "filter": "type",
        "filtertype": "show",
        "values": [
            "DHT22",
            "DHT11",
            "AM2302"
        ]
    }            
}

This is a very powerful feature and developer are encouraged to use it to keep the user interface easier for the end user.

The ‘businfo’ section¶

This section is optional and defines which buses on the Pi the module uses.

"businfo": [
    "I²C"
]

In this example the module uses the I²C bus

"businfo": [
    "I²C",
    "onewire"
]

In this example the module uses both the I²C bus and the onewire bus

The ‘changelog’ section¶

This section contains the changelog for the module. The latest version is at the end of the changelog. In this example there are several different types of entries in the changelog

v1.0.0 – This is a dingle change made by one author
v1.0.1 – This is multiple changes made by one author
v1.0.2 – This is multiple changes made by one author and a single change made by another

"changelog": {
    "v1.0.0" : [
        {
            "author": "Alex Greenland",
            "authorurl": "https://github.com/allskyteam",
            "changes": "Initial Release"
        }
    ],
    "v1.0.1" : [
        {
            "author": "Alex Greenland",
            "authorurl": "https://github.com/Mr-Groch",
            "changes": [
                "Change 1",
                "Change 2"
            ]
        }
    ],
    "v1.0.2" : [
        {
            "author": "Alex Greenland",
            "authorurl": "https://github.com/allskyteam",
            "changes": [
                "Change 1",
                "Change 2"
            ]
        },            
        {
            "author": "Andreas Schminder",
            "authorurl": "https://github.com/Adler6907",
            "changes": "Change 1"
        }
    ],
    "v1.0.3" : [
        {
            "author": "Alex Greenland",
            "authorurl": "https://github.com/allskyteam",
            "changes": [
                "Updated for new module structure",
                "Another change"
            ]
        }
    ]                             
}