alternate CT type?

[SteveMarquess2]

Here's a question about a monitoring use case where I don't want the readings considered as any of type "mains", "production", or "consumption". IMHO the Rpi Power Monitor has a lot of potential applications beyond the single residence with only load side PV interconnect case.

I have two 200A service entrances (for a 320/400 service), with CTs on all four phase conductors. I'm very interested in the service neutral current (imbalance of the ungrounded conductors) as I'll soon be replacing the 400A service conductors. Per the NEC I have wide latitude in selecting the ampacity of the neutral conductor, but because I have two separate grounding electrode systems I want to minimize stray current ("ground loops"). I may have to use active isolation for RS485 for instance, which has both up-front and operational costs. A bigger neutral helps but bigger gets expensive so the optimal solution is highly dependent on the neutral currents I see in practice.

In theory I can determine the neutral current as the difference between the two hot phases at any point in time (and then add that to the difference for the two phases for the other service entrance). But it occurs to me that I have two spare CT connections on the Rpi Power Monitor board and the CTs in the smaller size I'll want are cheap.

So I want to add two CTs to monitor and report the neutral current directly (almost directly, as the two CTs need to be added), but do not want that included in any of the existing reporting of "mains", "production", or "consumption".

What's the most elegant way to accomplish that? My first thought was to just create a new type, but there's an error check for that in power_monitor.py. I'd prefer to hack that as little as possible.

[David00]

Hi Steve, that's an interesting use case.

There are three ways you can solve for this now without making any adjustments to the code:

1. Create a new panel in Grafana that simply sums the metric you need and graphs it. This is the quickest and easiest option if visualizing the data in Grafana is all you need (as opposed to creating the data in the database).

Here's what a panel would look like - one query for each of the CT fields, and then an expression to combine the queries by name:

The resulting graph will show all three by default, so you can just hide the two queries and only plot the expression.

2. If you need the summed data to exist in InfluxDB to further perform operations on, you can create a continuous query (CQ) directly in your InfluxDB instance to automatically combine the readings in a way that you'd like, for specific channels that you're interested in, and store them in a new measurement. The CQ would need a subquery - here are the docs for both: Continous Queries and Subqueries

3. Write a Plugin that does the math operations on the two channel readings, and write them to the database. I don't think I have any examples of writing data back to the database from a plugin, so I would have to expand the docs on that and update my example GPIO plugin.

I like the idea of creating a new type in the config, or perhaps employing a new channel configuration option like sensor_group_name, where all channels having the same sensor_group_name would have power and amperage summed, and PF averaged. (I've actually already implemented this functionality in my other power monitor project, a 14 channel board with completely rewritten software, including a web interface, currently in closed-beta)

[SteveMarquess2]

Hi Steve, that's an interesting use case.

There are three ways you can solve for this now without making any adjustments to the code:

Ummm, but if I don't do any hacks (and thus use a type of "mains", "production", or "consumption"), won't the canned dashboards then be skewed by the amount of the neutral CT? The canned dashboards are working for me now, except for amperage.

If I can keep from disturbing those existing panels then I would do a new custom panel like you suggest. For now at least just the panel display will work for me and I won't worry about a continuous query.

[David00]

It depends on whether or not you have any channels currently configured with a type = mains in your config file. Having (or not having) a mains channel determines the way that the Home Power figures are calculated:

If you have at least 1 channel as a mains channel, then the consumption channels will not impact the home power at all. This is because as long as there's one mains channel, the home power is based on the sum of all mains channels and all production channels. The consumption channels don't really do anything, in this case.

If you do not have any mains channels, then the home power figures are based on consumption channels, I understand that this is a limitation in your case, so let's see what your current configuration looks like and we'll figure out how to move forward.

[SteveMarquess2]

I have four mains channels and no production or consumption channels at present. I will be adding six channels for production later this fall (just now I'm taking a break from working on the trench that will bring Ethernet to that location). For the forseeable future I don't plan to have any consumption channels (for my use case the total net premises consumption at the (first of two) bidirectional KWh meters is the only "load" that matters, and that is what the four mains CTs report).

So it sounds like I can just call these neutral CTs consumption, as misleadingly weird as that sounds. Good, I don't have to hack anything yet and can concentrate on digging :-)

[David00]

Awesome. You will be just fine to monitor the neutrals as consumption channels without impacting the panels on the Home Power Dashboard, then! If we need to allow not setting a type for a channel in the future, I'm definitely willing to explore that to make it more flexible. But, with your next board and its 6 production channels, you may be better off using the Individual CT Data dashboard and adding additional panels as necessary.

Good luck on the rest of the trench digging! :)