Modules overview

FruityMesh consists of a number of different Modules. There are the core modules which are part of the open source distribution, which deliver standard functionality. Also, there are other modules, some developed by us or by other developers that can provide specific functionality and built on our mesh framework.

General

All modules share a set of commands for loading and retrieving their configuration, for activating and deactivating them and for triggering actions.

Each Custom Module should extend the Module class to have a set of methods that it can override. Some of these methods are explained below:

Method Description

Module Constructor

The constructor must only define variables and should not start any functionality.

ConfigurationLoadedHandler

This handler is called once the module should be initialized. A pointer to the configuration will be given and all initialization should happen in this method. If the module configuration says that the module is inactive, the module should not initialize any functionality.

TimerEventHandler

Will be called at a fixed interval for all Modules. If functionality should only be executed e.g. each 5 seconds, use the SHOULD_IV_TRIGGER macro in the handler.

TerminalCommandHandler

Will receive all terminal input that can then be checked against a list of commands to execute.

ButtonHandler

Called once a button has been pressed and released.

MeshMessageReceivedHandler

Will be called once a full message has been received over the mesh (e.g. after all message parts were reassembled)

BleEventHandler

Implement this to receive all other ble events that have not been preprocessed, such as received advertising packets, new connections, e.g.

PreEnrollmentHandler

Allows a module to e.g. enroll an attached controller before accepting the enrollment. Check the EnrollmentModule for more info.

RecordStorageEventHandler

When saving a record, this handler is called once the flash access was done. Check the RecordStorage documentation.

CheckMeshAccessPacketAuthorization

See MeshAccessModule

CheckComponentUpdateRequest

Implement to ask a 3rd party controller about compatibility with the Dfu.

StartComponentUpdate

Called once the Dfu image is ready and can be sent to a 3rd party controller.

Commands are given with arguments in brackets [arg]. These must be entered by the user. Arguments in curly brackets {arg} are optional.

Configuring a Module

Sends a new module configuration to any node. The resulting binary configuration will be copied to the module-configuration of the specified module.

set_config [nodeID | "this"] [module-name] [hex-string] {requestHandle}

//Set binary configuration for io module
set_config 0 io 06:01:01:00:00 0

Requesting the Configuration of a Module

Prints the configuration of a specific module

//Display the current module configuration, shorthand notation is: getconf
get_config [nodeID  | "this"] [module name]

//Print the configuration from the current node's advertising module
get_config this adv

Activating / Deactivating a module at runtime

Activates or deactivates a specific module.

//Activate or deactivate a module, shorthand notation is: setactive
set_active [nodeID | "this"] [module name] [on | off]

//Examples
set_active 0 scan on //activates the scan module
set_active 0 adv off //deactivates the advertising module

Module Commands

Most module commands are structured in the same way. You have to give the nodeId that should process the command, specify the module and a command that should be triggered.

//Trigger some module action, shorthand notation is: action
action [nodeID  | "this"] [module name] [command]

//Examples
action 0 io led on //Switch on the LED for all connected nodes
action this io led off //Switch off LEDs for the current node
action 0 status get_device_info //Get the device info of all nodes
action 123 status get_status //Get the current status from node 123

Open Source Modules

The following modules are currently part of the open source release:

Proprietary Modules