Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to persist values across Fledge/South Plugin restarts #1538

Open
kwitekrac opened this issue Jan 15, 2025 · 4 comments
Open

How to persist values across Fledge/South Plugin restarts #1538

kwitekrac opened this issue Jan 15, 2025 · 4 comments

Comments

@kwitekrac
Copy link

Consider the following scenario:
A South plugin receives a message containing an event's start time. After some time, it receives another message containing the corresponding end time. The goal is to calculate the duration between the start time (t_start) and the stop time (t_stop).

  1. What is the recommended approach to store t_start in a way that persists even after a plugin or Fledge restart?
  2. Is it possible to directly access assets or the storage database from a South plugin?

Would using a built-in storage service be preferable, or is there a better pattern for persisting and retrieving stateful data across reboots?

@MarkRiddoch
Copy link
Contributor

Yes, you can set the SP_PERSIST_DATA flag in the plugin information entry point.
`/**

  • The plugin information structure
    */
    static PLUGIN_INFORMATION info = {
    FILTER_NAME, // Name
    VERSION, // Version
    SP_PERSIST_DATA, // Flags
    PLUGIN_TYPE_FILTER, // Type
    "1.0.0", // Interface version
    default_config // Default plugin configuration
    };`

This will then alter the shutdown and start procedure to persist data and reload that data.

The data that is persisted should be in JSON format and is passed in and out of the plugin as a string. Unfortunately this is not currently included in the online documentation and needs to be added.

The plugin_shutdown entry point should return the data to be persisted
`/**

  • Call the shutdown method in the plugin
    */
    std::string plugin_shutdown(PLUGIN_HANDLE *handle)
    {
    FILTER_INFO *info = (FILTER_INFO *) handle;
    Sigma *filter = info->handle;
    std::string state = filter->saveState();
    delete filter;
    delete info;
    return state;
    }`

The plugin_state entry point will be called with a string that contains the persisted data from he previous run
`/**

  • Pass saved plugin configuration
    */
    void plugin_start(PLUGIN_HANDLE *handle, string& data)
    {
    FILTER_INFO *info = (FILTER_INFO *) handle;
    Sigma *filter = info->handle;
    filter->loadState(data);
    }`

The example here is from a filter, but it works in the same way for south and north plugins.

@kwitekrac
Copy link
Author

Thank you, @MarkRiddoch, for your response! I have two additional questions:

  1. Is this feature available in Python-based plugins as well?
  2. Where is the data saved? My assumption is that it's stored in the configuration DB rather than the readings DB—could you confirm?

@MarkRiddoch
Copy link
Contributor

MarkRiddoch commented Jan 22, 2025

Thank you, @MarkRiddoch, for your response! I have two additional questions:

  1. Is this feature available in Python-based plugins as well?

I believe they are available in some but not all types of Python plugins. I would need to go and check to give a definitive list and will report back once I have done this.

  1. Where is the data saved? My assumption is that it's stored in the configuration DB rather than the readings DB—could you confirm?

Yes, the data is stored in the configuration database rather than the readings database. This was done because the readings database could be an in-memory database.

@MarkRiddoch
Copy link
Contributor

Documentation has now been added to the repository and should update shortly in the readthedocs documentation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants