-
Notifications
You must be signed in to change notification settings - Fork 103
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
Issues with use as a library #144
Comments
Now that I'm digging into the code, I'm seeing there's no way to load a configuration that doesn't include a config file. Previously, this could be acomplished by passing config variables to the RPiPowerMonitor class at initialization. This poses another issue, since using the RPiPowerMonitor in a pure Python application, like Mycodo, there's no config file, since the application itself stores the relevant config variables and needs to be able to pass them to the class at initialization. I haven't looked into the latest version of the code extensively, so I may be wrong... Is there a way to pass configuration variables to the class rather than using a file? |
As I look into it more, it seems v0.3 is not backwards compatible with v0.2. If influxdb were made optional and configuration variables could be passed to the class, this would make it able to be used as a library for other software. Otherwise, I'm afraid I won't be able to upgrade the Mycodo Input to use beyond v0.2. |
Hey @kizniche, I'm sure this can be done - I'll take a look at it soon. |
Thanks. I was going to take a crack at it when I have a few good hours I can sit down and test. Are there any significant issues with using v0.2, accuracy-wise I should know about? I have a project I'm currently using the v0.2 in Mycodo and am just curious if there were any major changes to 0.3 that corrected any measurement/calculation issues. |
Accuracy-wise, v0.3 should be slightly better because the delay in time between the voltage and current samples is reduced. However, the difference is probably negligible. The changes were not to correct any issues per-se; I just realized that the way I had originally written it made the original complicated calibration process a hard requirement to even use the power monitor. With v0.3, the calibration process is vastly simplified to a simple spot-check of the amperage reading of each CT against a trusted handheld amperage meter. The downside is that anyone coming from v0.2 can't simply move their calibration values over to v0.3 as the specific values are meaningless in v0.3. Hopefully that makes sense. |
Hey @kizniche, is there a standard interface that Mycodo relies on to set configuration options? Or, is it kind of custom for each external plugin? I would be leaning towards accepting a dictionary object containing the configuration settings in the class constructor because this most closely resembles how the config is loaded from the TOML file that standalone users setup. |
There's no standard, so whatever works best for your library will do and I'll update the Mycodo Input Module to use that method. A dictionary would do just fine. |
Is there a way to run the calibration method without influxdb?
When I originally made the pull request to turn this into a class (#62) for a Mycodo Input (https://github.com/kizniche/Mycodo/blob/e5be39b864702c93b0f72ff0438de504f898bb72/mycodo/inputs/power_monitor_rpi.py, https://github.com/kizniche/rpi-power-monitor/) and other software that wants to use it as as library, calibration could be performed in the terminal without influxdb. Now it seems it exits if terminal mode is used and it can't conenct to influxdb. This presents an issue, since Mycodo uses influxdb 2.x by default and you can't have 1.8 and 2.x installed at the same time. Additionally, it would be a hassle to do that just for a simple calibration. Perhaps a non-database calibration argument can be added for applications where influx 1.8 can't be installed or isn't desired?
The text was updated successfully, but these errors were encountered: