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

Issues with use as a library #144

Open
kizniche opened this issue Oct 27, 2024 · 7 comments
Open

Issues with use as a library #144

kizniche opened this issue Oct 27, 2024 · 7 comments

Comments

@kizniche
Copy link
Contributor

kizniche commented Oct 27, 2024

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?

@kizniche
Copy link
Contributor Author

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?

@kizniche
Copy link
Contributor Author

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.

@kizniche kizniche changed the title Calibrate without influxdb? Issues with use as a library Oct 27, 2024
@David00
Copy link
Owner

David00 commented Oct 28, 2024

Hey @kizniche, I'm sure this can be done - I'll take a look at it soon.

@kizniche
Copy link
Contributor Author

kizniche commented Oct 28, 2024

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.

@David00
Copy link
Owner

David00 commented Oct 29, 2024

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.

@David00
Copy link
Owner

David00 commented Nov 24, 2024

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.

@kizniche
Copy link
Contributor Author

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.

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