btmon.py remainder power metric

[nellswor]

Hello. In an attempt to monitor my 42 breaker house with just a single 7-channel ECM1240, I made some modifications to btmon.py to effectively get an "extra" channel. I figured that if I subtract Ch 2 and Aux 1 through Aux 5 from Ch 1 (main), that remainder could effectively be an eighth channel.

For example, my kitchen alone takes 10 circuits. If I put CTs on everything else in the house but the kitchen, the delta from my calculation should be my kitchen power.

See https://github.com/42Network/mtools/com ... b7088a0f47 for code details.

Do you see any flaws with this idea?

One thing I notice in my Grafana graphs is that the delta calculation sometimes has a large spike in it when one of the measured channels has a large step increase, such as when the AC turns on. The math in my calc_delta function is very simple. Is there some sort of hysteresis in the ECM1240 such that a large increase on an AUX channel would not be reflected in the main Ch 1 channel during the same sample period?

Note that I am using a 1 sec sample period. I send the 1-sec samples via MQTT to Telegraf & InfluxDB.
InfluxDB keeps the 1-second metrics for only two hours and a downsampling rule rolls them up into longer-interval metrics in another retention policy.

Thanks

[ben]

No issues with the idea. We do the same with our older Engine software.

One thing I notice in my Grafana graphs is that the delta calculation sometimes has a large spike in it when one of the measured channels has a large step increase, such as when the AC turns on. The math in my calc_delta function is very simple. Is there some sort of hysteresis in the ECM1240 such that a large increase on an AUX channel would not be reflected in the main Ch 1 channel during the same sample period?

Note that I am using a 1 sec sample period. I send the 1-sec samples via MQTT to Telegraf & InfluxDB.
InfluxDB keeps the 1-second metrics for only two hours and a downsampling rule rolls them up into longer-interval metrics in another retention policy.

Can you make sure your Packet Trigger Power is set to a large number (we usually set it to 8000)? I wonder if that's triggering and causing issues with the 1-sec intervals.

[Peter_V]

I do exactly what you're describing, I call it a "Virtual channel"

Just something to be aware of. Occasionally the virtual channel will show a phantom spike.
The 7 real channels are measured in sequence (one after the other) so occasionally you will have something turn on between these measurements. I.e. the power draw will maybe show up on Aux3 just after you measured Ch2. If you're taking samples every 10 seconds (like I do) this means you will see the power for ~10 second on Aux 3 before you see it on Ch2.

This is my 'Virtual' channel, the narrow spikes are caused by the above issue:


Something else to be aware of. The CTs are not precision instruments. They can vary by perhaps 2-3% from the "true" reading. So you may need to add some 'fudge factor' (FF) into your calculations to account for differences in measurement.
So in my case I do the following:
Ch1 is my main breaker
Virtual channel = (Ch1 * 1.028) - ( Aux1* 1.02) - (Aux2 *1.07) - (Aux3 * 0.945) - (Aux4 * 1.02) - (Aux5 * 0.99)

I figured these out by looking at the displayed graph and adjust each channel to try to smooth out the display. In the above graph you can see around 1800 there graph has a lot of noise. This is when the dryer was running and I need to readjust it's FF. As the temperature changes (summer, winter, etc.) this can effect the CTs measurements so the FF needs to be corrected every few months.