I would like to hook into log_data() so global sensor logging target plugins can be written
prash3r opened this issue · comments
Hello again,
i would like to implement a new Plugin class for being able to hook into the log_data() function.
I was originally trying to modify the influxDB logic to be able to choose between influx(cloud and server) and mariadb but i realized i would be writing a pull request not only with a new package mariadb but also with an external dependency (mariadb C Connector) and i guess it just wouldnt be accepted so i want to try and implement it as a plugin.
But from a Plugin side i only have the option to create something like a cbpi4_mariadbLoggedSensor which takes the configuration argument as well as one (or more) sensor and then logs that sensors data into the database. But i dont find that particular elegant because it would be listed as a sensor with a limited amount of sensors attached.
But a hook inside log_data() would allow us to write plugins for global sensor data log targets like influxdb, mariadb, mysql, home automation integration etc without having to select all those sensors in the individual plugin settings.
So should i put in the effort to create hook and write a new plugin base class?
I would also move the influxdb functionality into such a plugin as well as writing a mariadb plugin, and add the new base class to the plugin development documentation.
I am hoping for your feedback.
are you also a member of the facebook user group? It would be great if we could chat a bit in the next couple of days.
I am planning to copy the add/remove/call listener logic from the notifications for this function.
then i pass all the data available on to the listeners and they can do with it whatever they want. With this approach an additional data logging target can be implemented as CBPiExtension class alone. There doesnt need to be an extra plugin base class.
The listed commit 545f722 is based on my branch dev-config-changes. There are major differences due to the dynamic log folder location. So it wouldnt work on the current dev branch.
(please ignore the commit 69669a9 (if still listed) where i tried to make it work in the current dev branch as well. Ill just wait if dev-config-changes will be merged and then either write a pull request or try again.)
I added the desired log_data() hook and moved the InfluxDB support into a plugin.
https://github.com/prash3r/cbpi4-SensorLogTarget-InfluxDB
since i dont use InfluxDB it would be great if someone could test this plugin with my hookable-log-data branch and maybe open issues over there.
@prash3r did you pursue further activities on this topic? I like the listener idea :-)
I did. I have an out of date branch where I managed to implemented the hook for plugins to make use of. I also move the influx db functionality into a plug-in. I also wrote a mariadb plugin. Both of these plugins would make use of the new hook.
I am unsure if it's wanted to move the influx functionality out of the core project. But I think it is plausible. (We can implement the hook for all other tag-logging target plugins to be used even if influx stays in the core).
I was starting to write a tag-logging plugin example plugin documentation page based on my MariaDB plugin when I ran out of time.
Let me know if you would prefer the influx integration to stay in the core or not and I will update and finish up all the work on this old branch and write a pull request in 3 weeks.
I think it would be good to implement this. Although Influx should remain in the core as we also have grafana charts already implemented in the UI, it could be transferred to the extension folder as core plugin like other core plugins. We could create a feature_test branch based on the latest development branch, as some things have changed for the influx parameters
.. unfortunately, https://github.com/prash3r/cbpi4-SensorLogTarget-InfluxDB results in '404'
my plugin repo cbpi4-SensorLogTarget-InfluxDB was set to private because it would only work with my branch hookable-log-data at that point and i didnt want to confuse anyone. I set it to public again and added you as collaborator although i would really like to work on this myself.
I am unsure of the current state of the branch and the plugin. I would look into the recently made changes to the influx logic and i would rewrite it from scratch as i now know how i want to do it. I plan to implement the hook as it is in my branch three functions for adding and removing listeners which would result in a plugin logic like here where one could add their own function to the listeners list which then gets called automatically with a fixed set of parameters that can be used by the plugin.
Sound like a plan :-). I would just prefer to have the parameters addition still in the configupdate as it is for the other 'core' plugins. And the listener should be only started if inlfuxdb is set to yes -> will most likely require a cbpi restart if you change it. But then it is not activated for users that don't use this function.
@prash3r I saw that you were working on this topic on two of your branches. Is this now working?
I am freeing up a pi for testing tomorrow.
merged into development branch