# Schedules {% hint style="warning" %} This information is only applicable for NEON Vibration Sensors using communication protocol v4. {% endhint %} 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: 
{
  "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 | 1 | | transmitter\_battery | 1 | | vb\_measurement | 10 | | vb\_machine\_fault\_indicator | 10 | | vb\_spectrum | 10 | | vb\_statistics\_x\_rms\_velocity | 1 | | vb\_statistics\_x\_rms\_acceleration | 1 | | vb\_statistics\_x\_peak\_acceleration | 1 | | vb\_statistics\_y\_rms\_velocity | 1 | | vb\_statistics\_y\_rms\_acceleration | 1 | | vb\_statistics\_y\_peak\_acceleration | 1 | | vb\_statistics\_z\_rms\_velocity | 1 | | vb\_statistics\_z\_rms\_acceleration | 1 | | vb\_statistics\_z\_peak\_acceleration | 1 | | vb\_statistics\_temperature | 1 | {% hint style="warning" %} Note that the maximum number of simultaneous schedules is 18. {% endhint %} ### 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: \ \ \ \ \. This expression provides the time for schedules to be executed. **Note that \ and \ 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*](https://github.com/TWTG-R-D-B-V/neon-product-documentation/tree/main/VB/LoRa%20Communication/Protocol%20v4)*.* ### 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 {% code title="Example's JSON 1.1" %} ```json { "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 } } } } ``` {% endcode %} ### 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 {% code title="Example's JSON 2.1" %} ```json { "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 } } } } ``` {% endcode %} {% code title="Example's JSON 2.2" %} ```json { "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 } } } } ``` {% endcode %} {% code title="Example's JSON 2.3" %} ```json { "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 } } } } ``` {% endcode %} ### 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 {% code title="Example's JSON 3.1" %} ```json { "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 } } } } } ``` {% endcode %} ### 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 {% code title="Example's JSON 4.1" %} ```json { "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 } } } } } ``` {% endcode %} 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 {% code title="Example's JSON 5.1" %} ```json { "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 } } } } } ``` {% endcode %} Note that since the command is reset, all other fields are ignored. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.twtg.io/docs/data-and-communication/schedules.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.