Schedules

This information is only applicable for NEON Vibration Sensors using communication protocol v4.

The device schedule is a type of configuration used to define trigger intervals for device tasks such as measurement and message transmissions. The device executes tasks based on two weekly schedules: synchronized and unsynchronized.

Schedule configuration

The device tasks and schedules are set using the schedule configuration which defines: the task to be executed, its execution interval, and whether it is synchronized or unsynchronized.

The schedule configuration uses the following structure:

Configuration structure for schedules

{
  "type": "schedule",
  "version": 0,
  "command": <schedule_set_command>,
  "timing": <string or number>,
  "triggered_on_button_press": <boolean>,
  "send": <bool>,
  "settings": <object>
}

The available schedule types and the maximum number of schedules the device can store are presented in the next table:

Schedule type

Maximum number of schedules

transmitter_status

transmitter_battery

vb_measurement

vb_machine_fault_indicator

vb_spectrum

vb_statistics_x_rms_velocity

vb_statistics_x_rms_acceleration

vb_statistics_x_peak_acceleration

vb_statistics_y_rms_velocity

vb_statistics_y_rms_acceleration

vb_statistics_y_peak_acceleration

vb_statistics_z_rms_velocity

vb_statistics_z_rms_acceleration

vb_statistics_z_peak_acceleration

vb_statistics_temperature

Note that the maximum number of simultaneous schedules is 18.

Command

The schedule command is a feature that instructs the device on how the schedule should be handled providing flexibility to the user. The available options are:

Set: Sets the schedule. Overwrites any existing schedule with the same settings type and configuration type.
Replace: Replaces all schedules with the same settings type with this one.
Execute: Runs the schedule immediately upon receipt, considering only the settings field.
Reset: Removes all schedules of the specified settings type, ignoring all other fields.
Remove: Removes the schedule of the same settings type and configuration tag.

Timing

The timing specifies when the schedule is executed, which can be defined either as a period in minutes or as a cron expression.

Cron expressions specify when the schedule is executed. The cron expression consists of 5 fields separated by a space: <minute> <hour> <day-of-month> <month> <day-of-week>. This expression provides the time for schedules to be executed. Note that <day-of-month> and <month> are not supported and should always be "*".

Examples:

Example 1: "0 */4 * * *" Schedule triggers every 4 hours.

Example 2: "/15 8-17 * * 1-5" Schedule triggers every 15 minutes between 8:00 AM and 5:00 PM on weekdays.

Example 3: "2,4,6 */2 * * *" Schedule triggers on 2, 4 and 6 minutes past every two hours.

More information is available in the communication protocol.

Synchronized

A schedule defined as synchronized is aligned to the real-time provided by the LoRa Network Server allowing tasks to execute at a precise time. To avoid congestion in the network, a random send delay post-measurement is added to the transmission of the message.

Unsynchronized

The unsynchronized schedule runs at an offset compared to real-time. This offset is randomized per device. This mode should be used whenever synchronization is not required. The measurements are done at a fixed interval, with a randomized offset.

Trigger on button press

If this option is enabled, the scheduled task is also triggered with a short button press by the user.

Send

This field defines if the schedule will trigger a transmission or not. This setting is handy to define which schedules are used for measurements and which schedules trigger data to be sent via LoRa.

For example, a schedule can configure the device to measure the overall vibration values in the X-axis every 15 minutes, and another schedule will configure the device to measure and trigger a transmission of the overall vibration values in the X-axis every hour.

Settings

This field specifies the schedule's type and its parameters. The supported types are listed in the table above. Please refer to the communication protocol for detailed information on the parameters and available options.

Examples

Example 1

The user wants to replace the transmitter status schedule from its default to send the status every 1440 minutes (24 hours).

Configuration update request

Example's JSON 1.1

{
    "configuration_update_request": {
    "version": 0,
    "tag": "0xfe2192c9",
    "payload": {
        "type": "schedule",
        "version": 0,
        "command": "replace",
        "timing": 1440,
        "triggered_on_button_press": true,
        "send": true,
        "settings": {
            "type": "transmitter_status",
            "version": 0
            }
        }
    }
}

Example 2

The user wants to receive the statistics of the RMS velocity of all 3 axes at the same time, every Monday at 9 A.M. For this case, 3 schedules must be configured.

Configuration update request

Example's JSON 2.1

{
    "configuration_update_request": {
        "version": 0,
        "tag": "0x88173491",
        "payload": {
            "type": "schedule",
            "version": 0,
            "command": "set",
            "timing": "0 9 * * 1",
            "triggered_on_button_press": false,
            "send": true,
            "settings": {
                "type": "vb_statistics_x_rms_velocity",
                "version": 0,
                "range": "gscale_16",
                "sample_speed_divider": 1,
                "f_min": 5.0,
                "f_max": 6300.0
            }
        }
    }
}

Example's JSON 2.2

{
    "configuration_update_request": {
        "version": 0,
        "tag": "0x88173491",
        "payload": {
            "type": "schedule",
            "version": 0,
            "command": "set",
            "timing": "0 9 * * 1",
            "triggered_on_button_press": false,
            "send": true,
            "settings": {
                "type": "vb_statistics_y_rms_velocity",
                "version": 0,
                "range": "gscale_16",
                "sample_speed_divider": 1,
                "f_min": 5.0,
                "f_max": 6300.0
            }
        }
    }
}

Example's JSON 2.3

{
    "configuration_update_request": {
        "version": 0,
        "tag": "0x88173491",
        "payload": {
            "type": "schedule",
            "version": 0,
            "command": "set",
            "timing": "0 9 * * 1",
            "triggered_on_button_press": false,
            "send": true,
            "settings": {
                "type": "vb_statistics_z_rms_velocity",
                "version": 0,
                "range": "gscale_16",
                "sample_speed_divider": 1,
                "f_min": 5.0,
                "f_max": 6300.0
            }
        }
    }
}

Example 3

The user wants to set a schedule to measure the overall vibration values of all axexs, every 15 minutes, without sending the data unless the peak acceleration reaches 75 g.

Configuration update request

Example's JSON 3.1

{
"configuration_update_request": {
    "version": 0,
    "tag": "0x7a78f1af",
    "payload": {
        "type": "schedule",
        "version": 0,
        "command": "set",
        "timing": "*/15 * * * *",
        "triggered_on_button_press": false,
        "send": true,
        "settings": {
            "type": "vb_measurement",
            "version": 0,
            "axis": "all",
            "range": "gscale_16",
            "sample_speed_divider": 1,
            "f_min": 5.0,
            "f_max": 6300.0,
            "enable_confirmed_message": false,
            "send_condition": {
                "value_type": "peak_acceleration_above",
                "threshold": 75.0
                }
            }
        }
    }
}

Example 4

The user wants to receive a new envelope FFT spectrum on the Z axis as soon as possible as their team is currently inspecting the assets.

Configuration update request

Example's JSON 4.1

{
"configuration_update_request": {
    "version": 0,
    "tag": "0x3696cedf",
    "payload": {
        "type": "schedule",
        "version": 0,
        "command": "execute",
        "timing": 10080,
        "triggered_on_button_press": false,
        "send": true,
        "settings": {
            "type": "vb_spectrum",
            "version": 0,
            "axis": "z",
            "range": "gscale_16",
            "sample_speed_divider": 1,
            "f_min": 5.0,
            "f_max": 6300.0,
            "spectrum_type": "envelope",
            "averaging": 0,
            "time_to_transmit_min": 10,
            "send_condition": {
                "value_type": "always",
                "threshold": 0.0
                }
            }
        }
    }
}

Note that since the command is set to "execute" only the "settings" fields are considered.

Example 5

After testing with multiple configurations for the FFT spectrum, the user would like to return to the default configuration.

Configuration update request

Example's JSON 5.1

{
"configuration_update_request": {
    "version": 0,
    "tag": "0x3696ced1",
    "payload": {
        "type": "schedule",
        "version": 0,
        "command": "reset",
        "timing": 10080,
        "triggered_on_button_press": false,
        "send": true,
        "settings": {
            "type": "vb_spectrum",
            "version": 0,
            "axis": "z",
            "range": "gscale_16",
            "sample_speed_divider": 1,
            "f_min": 5.0,
            "f_max": 6300.0,
            "spectrum_type": "envelope",
            "averaging": 0,
            "time_to_transmit_min": 10,
            "send_condition": {
                "value_type": "always",
                "threshold": 0.0
                }
            }
        }
    }
}

Note that since the command is reset, all other fields are ignored.

PreviousMeasurements & Messages NextData Visualization

Last updated 4 months ago