Power Math

[Tirnanah]

So I'm looking for a little help in the form of a document, book, or website that I can read to help me understand some of this. I have switched over to using BTMon (thanks so much for all the help Matt!) in order to push information to both a mysql database (which I then move the information to my SQL server) and SEG. What I'm trying to understand is what "PWS" and "AWS" stand for/mean, and how to convert these numbers into a useable format (watts, watt hours, etc). I'm more then happy to do the research for myself to figure this out, but googling has not been particularly helpful, so I wanted to ask on the forums to see if someone could recommend some reading material. I'd prefer not to have to go back to school to get my electrical engineering degree, IT is enough for me!

The end goal is to setup an alert store procedured that will send me alerts when things have been on longer then they should have been (IE: my well has run for over 5 minutes, or my boiler has been on for an hour with no break, the lights in the library got left on, etc) and also to setup my own reports that can email to me daily or weekly to see what power went where, etc.

Thanks for anything someone might be able to recommend!
Doug

[mwall]

doug,

here is an outline of the math and definitions in btmon - perhaps lower-level than you are looking for, but at least it gets some of the definitions out of the way. it is from an email sent to tom keffer to help with the development of a power monitor to be integrated with weewx.

as for monitoring and notification, i find nagios to be very good at this. once you are collecting data, you can have nagios monitor everything then perform actions when things go high or low, or when they go high for n times, etc.

nagios is not the only monitoring tool out there, for example: munin, cacti, opennms, reconnoiter.

here are some of my thoughts about this stuff from a couple of years ago:

http://lancet.mit.edu/mwall/projects/na ... bling.html

imho you should avoid using stored procedures for monitoring and notification.

m

mind the p - in some cases p stands for polarized, in others it stands for positive.

these are 'hard data', i.e. things we get from the device:

secs - seconds counter from the gem. monotonically increasing counter. wraparound at 256^3. increments once per second.

aws - absolute watt-seconds. monotonically increasing counter. wraparound at 256^5.

pws - polarized watt-seconds. monotonically increasing counter. wraparound at 256^5. pws is always less than or equal to aws.

volts - voltage

t - temperature in degrees C

there is no notion of None. we can infer it for t if we get a value of 255.5. for other channels there is no way to know whether a CT or pulse counter is attached.


these are all derived quantities:

w - net watts. calculated from packets n and n-1.

wh - cumulative net watt-hours. calculated from packet n.

dwh - delta watt-hours. difference between reading n and n-1.

nw - negative watts. power generated. calculated from packets n and n-1.

pw - positive watts. power consumed. calculated form packets n and n-1.

nwh - negative watt-hours. energy generated.

pwh - positive watt-hours. energy consumed.

note that the meaning of positive/negative depend on:
- orientation of the ct
- per-channel polarity setting on the gem
- white/black wire positions in the gem wiring connectors

these are the calculations:

Code: Select all

seconds = sec_counter1 - sec_counter0                                       
w1 = (abs_ws1 - abs_ws0) / seconds    # if pos_ws1 == 0 multiply by -1         
pos_w1 = (pol_ws1 - pol_ws0) / seconds                                     
neg_w1 = ((abs_ws1 - abs_ws0) - (pol_ws1 - pol_ws0)) / seconds                              
pos_wh1 = pol_ws1 / 3600                                                   
neg_wh1 = (abs_ws1 - pol_ws1) / 3600                                       
wh1 = pos_wh1 - neg_wh1               # same as (2*pws1 - aws1) / 3600    
delta_wh1 = wh1 - wh0

when polarity is reversed, use the following:

Code: Select all

neg_wh1 = pol_ws1 / 3600                                                   
pos_wh1 = (abs_ws1 - pol_ws1) / 3600                                       
wh1 = (aws1 - 2*pws1) / 3600

brultech software appears to use the convention of "polarized watt seconds means negative (generated) power". btmon (and ecmread before it) used the opposite convention - polarized watt seconds means positive (consumed) power. btmon has a 'reverse-polarity' option that make btmon use the brultech conventions.

[ben]

I emailed over our latest packet format manual, it has some descriptions on what each field means.

brultech software appears to use the convention of "polarized watt seconds means negative (generated) power". btmon (and ecmread before it) used the opposite convention - polarized watt seconds means positive (consumed) power. btmon has a 'reverse-polarity' option that make btmon use the brultech conventions.

Small note here, the polarity can also be swapped by reversing CT leads or by toggling the channel with a command (^^^CXXTOG) where XX is any channel from 01 to 32.