v0.3.0-beta

[David00]

This is a beta release for v0.3.0. Help testing would be much appreciated! For upgrade instructions, please see the release page.

If testing, you'll need to create config.toml manually and put it next to power_monitor.py, or specify the path when you launch the power monitor with: python3 power_monitor.py --config /path/to/config.toml

Config file link:

config.toml

---

This discussion was created from the release v0.3.0-beta.

[bobstanl]

Error in manual install instructions.
In preparing my ssd for the 0.3.0 install, I ran into a problem on Step 7:
https://github.com/David00/rpi-power-monitor/wiki/Software-0.-Installation

It seems that influx is changing the locks and keys, so I got an error when trying to update:
rms@powermon:~ $ sudo apt update
Hit:1 https://packages.grafana.com/oss/deb stable InRelease
Get:2 https://repos.influxdata.com/debian bullseye InRelease [7,022 B]
Hit:3 http://raspbian.raspberrypi.org/raspbian bullseye InRelease
Hit:4 http://archive.raspberrypi.org/debian bullseye InRelease
Err:2 https://repos.influxdata.com/debian bullseye InRelease
The following signatures couldn't be verified because the public key is not available: NO_PUBKEY D8FF8E1F7DF8B07E
Reading package lists... Done
W: GPG error: https://repos.influxdata.com/debian bullseye InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY D8FF8E1F7DF8B07E
E: The repository 'https://repos.influxdata.com/debian bullseye InRelease' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.

Following the instructions on this web page got me through this key problem:
https://www.influxdata.com/blog/linux-package-signing-key-rotation/

It still failed to update until I realized you and they differ on some file names.
I had to carefully find the files to delete as per this paragraph from that page:
The above specifies paths to files and configuration from the most recent documentation. Users who use a different file than /etc/apt/sources.list.d/influxdata.list need to update the file to use signed-by=/etc/apt/trusted.gpg.d/influxdata-archive_compat.gpg. Similarly, users who installed the old key in a different location than /etc/apt/trusted.gpg.d/influxdb.gpg need to use that location to remove the old key.

I think these were the deletions:
rms@powermon:~ $ sudo rm -f /etc/apt/trusted.gpg.d/influxdb.gpg
rms@powermon:~ $ sudo rm -f /etc/apt/sources.list.d/influxdb.list

[David00]

Thanks @bobstanl. Great find! I just updated the Wiki page containing the manual install instructions. The keys changed for Grafana, too, so I updated that part as well.

[5ft24dave]

So calibration is the same as the accuracy calibration in the old config.py?
And I see there isn't a place for the phase calibration...

[David00]

Right - the "phase correction" procedure has been removed, because the way samples are collected has been changed.

Calibration is really just comparing the amperage reading of the sensor to the amperage reading of your handheld AC clamp meter now! (And even this is optional if you ordered the CTs from my shop, since I'm able to provide pre-calibrated standards for those)

Edit:
I should say that the accuracy calibration in the old config is slightly different because it was a combination of CT rating * accuracy calibration... meaning, a 20A sensor would have required a base value of approximately 0.20 +/- the needed calibration. Version 0.3.0 has separate requirement for sensor rating, and a separate rating for calibration, so the values don't directly translate from v0.2.0 to v0.3,0.

[Cube3SGM]

Hello David,

I loaded 0.2.0 on a new SD Card set up as before, then ran through the upgrade path to 0.3.0. Everything went smooth, no issues :) I stopped at the "run as a service" as the documentation is not yet there for that. The config.toml deployment is much nicer to use, so all good from me, thank you.

I was looking for information on using 1 CT for each circuit or 2 CTs. I was sure I saw a panel diagram showing 2 CTS used. I believe the link is broken on the getting started page. Can you point me in the right direction or explain when or why to use 1 or 2 CTs please. For me, I am just logging data for grid supply and individual circuits feeding my property. The more circuits I can log the better!
Regards Simon

[David00]

Great! Thanks for confirming the upgrade to v0.3.0 from the v0.2.0 image went well.

I stopped at the "run as a service" as the documentation is not yet there for that.

Ah yes, still have quite a bit more to build on the Advanced Usage page for the v0.3.0 beta docs. I'll see if I can find time to write that tonight.

I believe the link is broken on the getting started page.

I have updated the old Wiki's Getting Started page, which is where that sample diagram was located. You should be able to see it on this page now.

Can you point me in the right direction or explain when or why to use 1 or 2 CTs please. For me, I am just logging data for grid supply and individual circuits feeding my property. The more circuits I can log the better!

In order to understand when, where, and how to use the CTs properly, you should know a little bit about how the electrical service comes into your panel. Here's a very generalized and high level overview:

If you're in the US or Canada, your electrical panel is going to have two "legs". Each leg is essentially one half of the 240V main supply, which is how we get 120V at the outlet. An interesting characteristic with this "split-phase" delivery is that the two legs are opposite in phase from one another. So, our standard appliances normally take 120V, which means they pull current from only one of the split phases. Very generally speaking, roughly half of your house's appliances will be connected to one of the legs, and the other half will be connected to the other leg. To measure the whole house power, you'd have to use two CTs (one on each leg, such as in the sample panel image in the link above). Also, high power appliances, like EV chargers, electric dryers, and electric heaters, will usually connect to both legs via a "two-pole" breaker. The config.toml has the two_pole setting to tell the software to double the measurements from a single CT, iff:

• you have a "split phase" panel described above
• the sensor is measuring a two-pole circuit
• you only have one sensor on one of the legs
• you trust that doubling the measurement from a single leg will be reasonably accurate for your needs.

---

For non-North American panels, it's much simpler. Your service is usually single-phase, 230V. So, there's nothing about two pole or multiple sensors. You generally have one sensor on your main incoming feed, and then up to five additional sensors for individual circuits in the electrical panel.

I hope I've understood your question and provided the detail that you're looking for. If not, please feel free to clarify the ask and I can elaborate more!

[Cube3SGM]

Thats perfect, understand exactly whats going on now. thank you. Please don't feel you have to write any further pages for me, I am more than happy to wait. Really appreciate your help and sharing your project.

[5ft24dave]

Followed the upgrade procedure from 0.2.0 to 0.3.0 edited config.toml, started the power_monitor.py per the instructions. Dashboard shows solar as negative. looking at the raw CT data, it shows as it should, as positive values, but even though I am using 2 CT's for the solar, the value it does show is the difference between the two... so 31.4W on CT3, 33W on CT4 and it shows -1.6W solar...

[David00]

Do both channels in config.toml have a type of production?
Can you start the software with the -v flag (for verbose) and share the output? I'll be back to my desk in a bit and can look more closely at it then.

[5ft24dave]

Ok, Sun was going down. In sleep mode, the inverter draws a watt or two from one leg of the mains to keep it alive. the other was zero. that was where the negative was coming from as I had watts_cutoff_threshold=0 for both. Just set them both to 3 and now they read 0 I'll have to see what happens tomorrow during daylight.
Here is starting with ctrl-v:
DEBUG : Verbose logs output enabled.
DEBUG : Attempting to loading config from /home/pi/rpi_power_monitor/rpi_power_monitor/config.toml
DEBUG : Sampling enabled for 4 channels.
DEBUG : Identified mains channels: [1, 2]
DEBUG : Identified 2 production channels: ([3, 4])
DEBUG : Identified 0 consumption channels: ([])
DEBUG : Trying to connect to the Influx database at localhost:8086...
DEBUG : Successfully connected to Influx at localhost:8086
2023-02-13 18:38:27 : ... Starting Raspberry Pi Power Monitor
INFO : ... Starting Raspberry Pi Power Monitor
2023-02-13 18:38:27 : Press Ctrl-c to quit...
INFO : Press Ctrl-c to quit..._

and terminal mode before I made the change0:

_2023-02-13 18:42:08 :
+-------------+----------+---------+--------+-----+-----+-----+
|             |   ct1    |   ct2   |  ct3   | ct4 | ct5 | ct6 |
+-------------+----------+---------+--------+-----+-----+-----+
|    Watts    | 1431.899 | 764.991 | -1.72  |  0  |  0  |  0  |
|   Current   |  12.152  |  6.746  | -0.211 |  0  |  0  |  0  |
|     P.F.    |  0.991   |  0.953  | -0.069 |  0  |  0  |  0  |
|   Voltage   | 118.956  |         |        |     |     |     |
| Sample Rate |  42.88   |   kSPS  |        |     |     |     |
+-------------+----------+---------+--------+-----+-----+-----+
INFO :
+-------------+----------+---------+--------+-----+-----+-----+
|             |   ct1    |   ct2   |  ct3   | ct4 | ct5 | ct6 |
+-------------+----------+---------+--------+-----+-----+-----+
|    Watts    | 1431.899 | 764.991 | -1.72  |  0  |  0  |  0  |
|   Current   |  12.152  |  6.746  | -0.211 |  0  |  0  |  0  |
|     P.F.    |  0.991   |  0.953  | -0.069 |  0  |  0  |  0  |
|   Voltage   | 118.956  |         |        |     |     |     |
| Sample Rate |  42.88   |   kSPS  |        |     |     |     |
+-------------+----------+---------+--------+-----+-----+-----+_

and after the change:

_2023-02-13 18:44:38 :
+-------------+----------+---------+-----+-----+-----+-----+
|             |   ct1    |   ct2   | ct3 | ct4 | ct5 | ct6 |
+-------------+----------+---------+-----+-----+-----+-----+
|    Watts    | 1497.541 | 767.105 |  0  |  0  |  0  |  0  |
|   Current   |  12.675  |  6.775  |  0  |  0  |  0  |  0  |
|     P.F.    |   0.99   |  0.949  |  0  |  0  |  0  |  0  |
|   Voltage   | 119.312  |         |     |     |     |     |
| Sample Rate |  42.61   |   kSPS  |     |     |     |     |
+-------------+----------+---------+-----+-----+-----+-----+
INFO :
+-------------+----------+---------+-----+-----+-----+-----+
|             |   ct1    |   ct2   | ct3 | ct4 | ct5 | ct6 |
+-------------+----------+---------+-----+-----+-----+-----+
|    Watts    | 1497.541 | 767.105 |  0  |  0  |  0  |  0  |
|   Current   |  12.675  |  6.775  |  0  |  0  |  0  |  0  |
|     P.F.    |   0.99   |  0.949  |  0  |  0  |  0  |  0  |
|   Voltage   | 119.312  |         |     |     |     |     |
| Sample Rate |  42.61   |   kSPS  |     |     |     |     |
+-------------+----------+---------+-----+-----+-----+-----+_

[David00]

Thanks for the info! It looks like the watts_cutoff_threshold did what you needed, but let's see tomorrow when you're producing power to see how the dashboard looks. The solar production Watts value must be positive when your system is producing power in order for the "Home Power" value to be calculated correctly.

On another note, what setup are you running this project on? It's showing that you're getting a sample rate of 42.61 kSPS, which is almost double what I and most other people get! Can you share the output of the following so I can get an idea of the environment you have?

• sudo cat /etc/os-release
• cat /proc/cpuinfo | grep -E "Hardware|Revision|Model|model name"
• python3 -V

That's pretty awesome you're getting 42 kSPS! I wonder if a step in the upgrade process brought a significant update to the environment.

[5ft24dave]

yep its a Pi4 running the bullseye with the latest 6.1.11 kernel from rpi-update

pi@FiberPi:~ $ sudo cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 11 (bullseye)"
NAME="Raspbian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

pi@FiberPi:~ $ cat /proc/cpuinfo | grep -E "Hardware|Revision|Model|model name"
model name : ARMv7 Processor rev 3 (v7l)
model name : ARMv7 Processor rev 3 (v7l)
model name : ARMv7 Processor rev 3 (v7l)
model name : ARMv7 Processor rev 3 (v7l)
Hardware : BCM2711
Revision : c03114
Model : Raspberry Pi 4 Model B Rev 1.4

pi@FiberPi:~ $ python3 -V
Python 3.9.2

[5ft24dave]

and:
pi@FiberPi:~ $ uname -a
Linux FiberPi 6.1.11-v7l+ #1630 SMP Fri Feb 10 12:07:50 GMT 2023 armv7l GNU/Linux

[David00]

Awesome! It seems to be the v6 kernel that's giving you the speed boost! Thanks for throwing in uname -a, too. :)

[5ft24dave]

The other thing its doing is every couple dashboard refreshes, everything drops to 0 and status goes to "No Data"

[5ft24dave]

Any idea why 0.3.0 is inverting my solar data?

[David00]

I will be able to take a look in the morning.

[David00]

Ok, so looking into this, I discovered a small problem with the Home Power consumption calculation, which I've fixed. But, this was not related to why the mains are now showing negative current. It could have made the home load graph go into the negatives, though.

That is because in v0.3.0, I made a change to make the amperage negative if the power is negative - this is to track net current. Previously, only net power was tracked, and current was always displayed as positive on the mains regardless of the direction it was flowing. Now, if the current is flowing out of the panel and back to the grid, it will be indicated by the negative sign, just like power:

rpi-power-monitor/rpi_power_monitor/power_monitor.py

Lines 750 to 760 in 3d7eaa1

	# Determine if the system is net producing or net consuming right now by looking at the panel mains.
	# Since the current measured is always positive,
	# we need to add a negative sign to the amperage value if we're exporting power.
	for chan_num in self.mains_channels:
	if results[chan_num]['power'] < 0:
	results[chan_num]['current'] = results[chan_num]['current'] * -1
	# Set the current for any production sources negative if the power is negative, and find the total power and current from all production sources.
	for chan_num in self.production_channels:
	if results[chan_num]['power'] < 0:
	results[chan_num]['current'] = results[chan_num]['current'] * -1

[5ft24dave]

makes sense... Now should Solar amperage show as negative while producing? terminal mode shows positive output, but amperage graph on dashboard shows negative

[David00]

The amperage from the sensor that's directly measuring your solar should show positive. The general logic is if it's flowing into the panel, it should be positive, and if it's flowing out of the panel, it should be negative.

Can grab the latest commit from the develop-v0.3.0 branch, and try testing again in terminal mode, and share the output when your solar is producing?

[5ft24dave]

Also:
pi@FiberPi:~/rpi_power_monitor $ git checkout origin/develop-v0.3.0
error: pathspec 'origin/develop-v0.3.0' did not match any file(s) known to git

so I used wget to pull the tar.gz of 0.3.0, expanded it and copied the files into the rpi_power_monitor directories

[David00]

That was likely due to your local git config having something telling it to ignore other tags. If you didn't nuke the existing rpi_power_monitor directory before pulling the new one down manually, can you see what's in ~/rpi_power_monitor/.git/config with:

cat ~/rpi_power_monitor/.git/config | grep -A 3 "remote \"origin\""

The fetch = line should look like this:

fetch = +refs/heads/*:refs/remotes/origin/*

If your fetch line doesn't match that, can you share what it is set to before changing it? You'll want to update this line so that you can pull down updates as I'm actively working on the develop-v0.3.0 branch, and there have been several small updates already since the v0.3.0 beta release last week.

After you update the fetch line, you can try the following:

git fetch              # This should show a bunch of new stuff being tracked, and then you can do:
git checkout origin/develop-v0.3.0

[5ft24dave]

here's my fetch:
fetch = +refs/heads/master:refs/remotes/origin/master

[David00]

Ok - I think you may need to do a git checkout master, then a git fetch, followed by a git checkout develop-v0.3.0.

[5ft24dave]

Definitely shows positive in terminal mode. I'll get a shot when I get home this afternoon and also grab the latest Thanks Get BlueMail for Android

…

On Feb 16, 2023, 18:19, at 18:19, David ***@***.***> wrote: The amperage from the sensor that's directly measuring your solar should show positive. The general logic is if it's flowing into the panel, it should be positive, and if it's flowing out of the panel, it should be negative. Can grab the latest commit from the `develop-v0.3.0` branch, and try testing again in terminal mode, and share the output when your solar is producing? -- Reply to this email directly or view it on GitHub: #88 (reply in thread) You are receiving this because you commented. Message ID: ***@***.***>

[David00]

Got it - it's happening in the dashboard itself. The Amperage plot on the Home Power Dashboard has a * -1 applied to the solar power data:

So, if you remove this value, it will display as positive.

[5ft24dave]

Cool. Thank you Get BlueMail for Android

…

On Feb 17, 2023, 09:25, at 09:25, David ***@***.***> wrote: Got it - it's happening in the dashboard itself. The Amperage plot on the Home Power Dashboard has a `* -1` applied to the solar power data:  So, if you remove this value, it will display as positive. -- Reply to this email directly or view it on GitHub: #88 (reply in thread) You are receiving this because you commented. Message ID: ***@***.***>

[5ft24dave]

Have an error running backups...

_Traceback (most recent call last):
File "/home/pi/rpi_power_monitor/rpi_power_monitor/backup.py", line 11, in
import tomli
ModuleNotFoundError: No module named 'tomli'
pi@FiberPi:~/rpi_power_monitor/rpi_power_monitor $
_

[5ft24dave]

got around the tomli error by installing tomli with pip3 in the system python3. for some reason as root it won't look at the /home/.local path for python packages... and it says there is no config.toml as well. I have to use --config and the whole path in the commandline. once there, I get:

__02-18-2023 15:44:54 - INFO:
------------- Starting new backup -------------
02-18-2023 15:44:55 - INFO: Mounted /dev/sdb1 to /media/backups
02-18-2023 15:44:55 - DEBUG: Created directory /media/backups/power_monitor_backups/backup_2023-02-18_1544.
02-18-2023 15:44:55 - INFO: Stopped power monitor service... Starting InfluxDB Backup.
02-18-2023 15:44:55 - INFO: Please wait. This can take several minutes if you have a lot of data, and you won't see any output until it's done.
2023/02/18 15:44:55 Invalid metadata blob, ensure the metadata service is running (default port 8088)
backup: invalid metadata received
02-18-2023 15:44:55 - INFO: Done backing up InfluxDB. Creating an archive...
02-18-2023 15:44:55 - DEBUG: Done creating the archive. Cleaning up...
02-18-2023 15:44:55 - DEBUG: USB Drive unmounted.
02-18-2023 15:44:56 - INFO: Backup completed successfully in 1.251225616000056 seconds. Backup filesize: 0.001555 MB

[5ft24dave]

Here is my backup log file. only thing in the backup, due to the error, is the config.toml file
backups.log

[David00]

I've fixed the backup issue, so you should now be able to get the fix by pulling the latest changes down with git pull.

[5ft24dave]

How do we make 0.3.0 start as a service? I used the same startup script for systemctl as the previous versions used, and it fails unless you start it after the pi is completely up manually with sudo systemctl start power-monitor

[David00]

You'll need to update the service file at /etc/systemd/system/power-monitor.service. I just pushed the sample service file to the docs so that it can be grabbed easily from the command line. (I still have to build the actual documentation section out for running as a service, but I'll get to that soon).

You can run the following commands (one by one) to replace the old service file with the new one for v0.3.0:

sudo systemctl stop power-monitor.service
sudo wget https://david00.github.io/rpi-power-monitor/docs/v0.3.0-beta/power-monitor.service -O /etc/systemd/system/power-monitor.service
sudo systemctl daemon-reload
sudo systemctl start power-monitor
sudo systemctl status power-monitor

[5ft24dave]

Crap... Spoke too soon.. _Feb 24 18:03:58 FiberPi systemd[1]: power-monitor.service: Consumed 1.275s CPU time. Feb 24 18:03:59 FiberPi systemd[1]: power-monitor.service: Scheduled restart job, restart counter is at 5. Feb 24 18:03:59 FiberPi systemd[1]: Stopped Raspberry Pi Power Monitor. Feb 24 18:03:59 FiberPi systemd[1]: power-monitor.service: Consumed 1.275s CPU time. Feb 24 18:03:59 FiberPi systemd[1]: power-monitor.service: Start request repeated too quickly. Feb 24 18:03:59 FiberPi systemd[1]: power-monitor.service: Failed with result 'exit-code'. Feb 24 18:03:59 FiberPi systemd[1]: Failed to start Raspberry Pi Power Monitor. _

…

On Fri, Feb 24, 2023 at 4:59 PM David ***@***.***> wrote: You'll need to update the service file at /etc/systemd/system/power-monitor.service. I just pushed the sample service file to the docs so that it can be grabbed easily from the command line. (I still have to build the actual documentation section out for running as a service, but I'll get to that soon). You can run the following commands (one by one) to replace the old service file with the new one for v0.3.0: sudo systemctl stop power-monitor.service sudo wget https://david00.github.io/rpi-power-monitor/docs/v0.3.0-beta/power-monitor.service -O /etc/systemd/system/power-monitor.service sudo systemctl daemon-reload sudo systemctl start power-monitor sudo systemctl status power-monitor — Reply to this email directly, view it on GitHub <#88 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AI77WUBH4JMLSDX4YSAOOH3WZFKPTANCNFSM6AAAAAAUSI76TQ> . You are receiving this because you commented.Message ID: ***@***.*** com>

[5ft24dave]

changed start burst to 10 and now it runs

[buffedelic]

Seems like the script is running quit resource intensive, 100% utilisation. Note that I did not compare before going with 0.3.0, it might just be the nature of what it is doing...

[David00]

Thanks! So, the problem is the 3-phase grid. There's a little bit more to the setup of a 3-phase implementation, and the v0.3.0 release isn't quite ready for 3-phase... yet. I do have an older 3-phase version, which I am working on updating to make it easier to use and bring it closer to the v0.3.0 version, but it's not ready yet.

It looks like your CT3 is the one that's on the same phase as your AC voltage input, so I would expect this CT to maintain a linear current value as the amperage changes. Your CT1 and CT2 will not, though, with the current state of v0.3.0. I hope to have something to share for testing next week!

[buffedelic]

sound good! I can offer you some debug data when live 👍

The nginx start page should be updated to conform to the information given when running the debug plot.

INFO : ... Or, simply visit http://192.168.1.64 to view all the charts created using '--plot' mode.

[David00]

Awesome, thanks!

Regarding Nginx, that's odd - did you install my v0.2.0 OS image, or setup everything manually in a stock image?

To resolve, you can check the contents of /etc/nginx/sites-enabled/default and make sure that the location / section has the autoindex on; line, like this:

        location / {
                # First attempt to serve request as file, then
                # as directory, then fall back to displaying a 404.
                try_files $uri $uri/ =404;
                autoindex on;

Also check to make sure that there aren't any index.* files in /var/www/html (remove them if so). Then, you'll be able to see the directory listing, like this:

[buffedelic]

I used the OS image, and followed you walk-trough(0.3.0) on the releases page.
there was an index file there, problem resolved!

[buffedelic]

Trying your three-phase branch, seems to give me somewhat better result. But with that said, I have not taken any actual comparative readings yet...
debug_plot.html.txt

[Cube3SGM]

Hi David,
Could you give me a rough indication of how long, say a 16Gb, SD card will last before the database uses the available room. As I am now collecting data I want to have a think about backups and SD card sizes. Thanks, Regards Simon

[David00]

With the new continuous queries and retention policies (aka, automatic downsampling and removal of old data), you can expect to use about 1 GB per year, so you'd get many years out of a 16 GB card, in theory.

There have been instances of different logs growing at rates faster than the actual data grows, though, which I am fixing for a future release as they pop up. I'd recommend at least a 32GB high endurance card for this project. It's always good to have some extra space to allow for software upgrades and provide some overhead above what's needed - it's never fun to have a disk fill up all the way.

I want to have a think about backups and SD card sizes

There is a backup utility in the v0.3.0 beta that will automatically generate a backup of the power monitor data and store it on a USB flash drive connected to the Pi:

https://david00.github.io/rpi-power-monitor/docs/v0.3.0-beta/configuration.html#enabling-automatic-backups

[5ft24dave]

Backup doesn't seem to be working. Throws an error about not being able to connect. Once it finishes, it's only backed up the config.toml. See errors I posted in previous posts

[David00]

Thanks for the reminder @5ft24dave, I'll look at it this week.

[5ft24dave]

still can't connect to the database after a git fetch and pip3 install . ***@***.***:~/rpi-power-monitor/rpi_power_monitor $ sudo python3 backup.py 03-09-2023 17:14:50 - INFO: ------------- Starting new backup ------------- 03-09-2023 17:14:51 - INFO: Mounted /dev/sdb1 to /media/backups 03-09-2023 17:14:51 - DEBUG: Created directory /media/backups/power_monitor_backups/backup_2023-03-09_1714. 03-09-2023 17:14:51 - INFO: Stopped power monitor service... Starting InfluxDB Backup. 03-09-2023 17:14:51 - INFO: Please wait. This can take several minutes if you have a lot of data, and you won't see any output until it's done. *2023/03/09 17:14:51 Invalid metadata blob, ensure the metadata service is running (default port 8088)backup: invalid metadata received* 03-09-2023 17:14:51 - INFO: Done backing up InfluxDB. Creating an archive... 03-09-2023 17:14:51 - DEBUG: Done creating the archive. Cleaning up... 03-09-2023 17:14:52 - INFO: There are currently 5 backups. Removing 1 old backups. 03-09-2023 17:14:52 - DEBUG: USB Drive unmounted. 03-09-2023 17:14:52 - INFO: Backup completed successfully in 1.3444718449609354 seconds. Backup filesize: 0.001562 MB

…

On Wed, Mar 8, 2023 at 7:18 PM David ***@***.***> wrote: I've fixed the backup issue, so you should now be able to get the fix by pulling the latest changes down with git pull. — Reply to this email directly, view it on GitHub <#88 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AI77WUGZ2HSP47CUKK2VJU3W3FDXZANCNFSM6AAAAAAUSI76TQ> . You are receiving this because you were mentioned.Message ID: ***@***.*** com>

[David00]

It look like the git pull must not have worked for you - I can tell because in the update to backup.py, I added the round() function to the time that gets printed to the screen.

Backup completed successfully in 1.3444718449609354 seconds

Are you familiar with git to troubleshoot?

[5ft24dave]

unfortunately not good with git at all

…

On Thu, Mar 9, 2023 at 6:30 PM David ***@***.***> wrote: It look like the git pull must not have worked for you - I can tell because in the update to backup.py, I added <ce2b32e#diff-e9efe26a1b36ef611871ba071a40acbd1239d32f9e39d2da1d3108bdad5f6558R132> the round() function to the time that gets printed to the screen. Backup completed successfully in 1.3444718449609354 seconds Are you familiar with git to troubleshoot? — Reply to this email directly, view it on GitHub <#88 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AI77WUFTOXLLE75VKGKYOV3W3KG4DANCNFSM6AAAAAAUSI76TQ> . You are receiving this because you were mentioned.Message ID: ***@***.*** com>

[David00]

Ok, let's connect over email to keep the back and forth down on this discussion thread and I'll help you get it straightened out. My email is [email protected]. I'll want to start with the outputs of git status and git log from inside your project directory.

[Paulus4711]

Hello David,

thank you very much for your good work!

Is it possible for you to enter the ID of SPI in the config.toml ?

Unfortunately I can't do that......

config.tom

username = "root"
password = "password"
database_name = "power_monitor"

#[spi_open]
#spi_open(1, 2)					# ID of SPI

[grid_voltage]

power_monitor.py

        self.load_config(config)
        
        if spi:
            self.spi = spi
        else:
            self.spi = spidev.SpiDev()
            self.spi.open(1, 2)
	#self.spi.open() = self.spi_open
            self.spi.max_speed_hz = 1750000
......
        self.config = config
        #self.spi_open = config.get('spi_open').get('spi_open')		
        self.grid_voltage = config.get('grid_voltage').get('grid_voltage')

I am currently using several MCPs, for example to monitor internal voltages......

Sorry for my google english

[David00]

Hi Paulus,

I'm currently focusing on wrapping up this v0.3.0 release, but I do like the idea of this. For now, it is possible to set the SPI number by importing the RPiPowerMonitor() class into your own Python code.

In the class initialization, you can provide your own Python SpiDev object. Such an example might look like:

from rpi_power_monitor import power_monitor
import spidev

my_spi = spidev.SpiDev()
my_spi.open(0, 0) # Or whatever SPI device number you want to use)

rpm = power_monitor.RPiPowerMonitor('default', 'path/to/config.toml', spi=my_spi)
rpm.run_main()

Or, you can edit power_monitor.py and manually set the SPI number here:

rpi-power-monitor/rpi_power_monitor/power_monitor.py

Line 85 in 11b8b64

self.spi.open(0, 0)

I will explore setting the SPI number via config.toml and via a CLI flag after I release v0.3.0.