damage
Senior Member
oops. you're right
Brultech ECM-1240 Software Development
- Thread starter 3tones
- Start date
oops. you're right
So, it's important that you look at the seconds field. Rather than relying/assuming your unit is sending data every 1 second, you just read the delta of the watt-seconds, and then divide by the delta of the seconds counter reading.
For those interested, the reason it's watt-seconds and not watts/sec is because watts by themselves are not a quantitative/cumulative unit of measurement (like liters or miles), they are instantaneous, like a pressure. One watt-second is 1 watt of continuous power over the course of one second, one KWH is the same measurement essentially, but it's 1000 watts continuous over the course of one hour. One watt-second is also sometimes, probably more frequently, called a Joule.
To split hairs even further, the watt-second from the ECM is not a continuous watt for a second, but an average of 1 watt for a period of one second.
tenholde
Right, which means that technically, it could have been 2 watts over half a second, and then 0 watts for another half second. Not that it really matters, but it would be interesting to know if the unit was taking multiple readings over 1 second increments and then adding them together, or taking multiple readings, fitting a curve to it, and then taking the integral of the curve to get an exact number rather than an approximation.
In the grand scheme of things, this might not make much of a difference. But, if you were using these to calculate power consumption/cost and you needed it to be accurate, then very small inaccuracies every second, added up over the course of an entire month, could result in a fairly wide gap.
As others mentioned the watt measurment is at an instant in time. Comparing it to a car, it would be the measurement of the speed not the measument of the miles traveled. For billing purposes you care about the miles traveled or the KWH usage.
Lights have fairly consistant watt demands but I have some circuits with motors on them that have the watt value change by more then 25% every second. There is no way you could use watt data, even at one read per second to figure out KWH/usage.
The ECM passes instananous watt data & KWH data for each channel with each update. I am assuming that the ECM is calculating the KWH usage correctly over the course of that second even if the watts values jump around within that second.
Has anyone who has had their unit running for multiple months compared the power measured with the usage as reported via the utility company?
Does anyone know what point the KWH usage wraps? I am writing some sqlite queries to calculate usage similar to what the dashboard does but I am wondering if I need to take into account the total KWH usage wrapping.
Lights have fairly consistant watt demands but I have some circuits with motors on them that have the watt value change by more then 25% every second. There is no way you could use watt data, even at one read per second to figure out KWH/usage.
The ECM passes instananous watt data & KWH data for each channel with each update. I am assuming that the ECM is calculating the KWH usage correctly over the course of that second even if the watts values jump around within that second.
Has anyone who has had their unit running for multiple months compared the power measured with the usage as reported via the utility company?
Does anyone know what point the KWH usage wraps? I am writing some sqlite queries to calculate usage similar to what the dashboard does but I am wondering if I need to take into account the total KWH usage wrapping.
The ch1,2 counters are 5-byte counters and wrap at 1,099,511,627,775
The Auxn counters are 4-byte counters and wrap at 4,294,967,295
The second counter is a 3-byte counter and wraps at 16,777,215
tenholde
1 KWH has 3,600,000 Watt-seconds (joules) in it. The AUX counters will wrap at 1193.04647 KWH. The CH1/2 counters will wrap at 305419.897 KWH. To put this in the context of money, at 6.5 cents/KWH, I would have to spend $19,865 on CH1/2 to wrap it. But, on an AUX channel, that's only $77 worth of electricity. My AUX channels DO wrap on a regular basis due to my server rack and several freezers.
For residential use, I don't see the CH1/2 being much of a problem for wrapping, but if you were using this in a datacenter or industrial environment, it would most certainly wrap at some point. Any software needs to take this into account for the AUX channels for sure, and at that point, you just add the similar code for the CH1/2 channels.
Thanks.. that was very helpful. 1193 KWH per channel is not that much. My AC channel will blow through that in a month if hot enough , my server cabinet in 2 or 3.
That leads me to my next question, what does Paul do with the ECM Engine and the database when it wraps? My initial plan is to hit his sqlite database for my usage calculations rather then try to relog all the data from the live stream into my own db.
He must account for this wrap somehow otherwise his dashboard would be messed up when the aux channels wrap. He either needs to account for this when he writes to the DB or when he reads from it. I didnt recall a table that kept track of the number of wraps for each channel. Logging the number of wraps ina table and then adjusting the value on writes would seem to be the best way. If he had a table to store wrap counts, on a write he could store the KWH as (KWH of ECM) + 1193.04647*(Number of wraps per channel). If done this way the whole history in the usage table will be on the same wrap. Problem is I dont recall a place in the DB to store the number of wraps on a channel.
If he doesnt do that it would be tough to track how many wraps took place when comparing the KWH on one date to a previous. If the current KWH is less then KWH for a channel 30 days ago you can assume a wrap took place but you have no way to know how many wraps took place, it could certainly be more then one.
That leads me to my next question, what does Paul do with the ECM Engine and the database when it wraps? My initial plan is to hit his sqlite database for my usage calculations rather then try to relog all the data from the live stream into my own db.
He must account for this wrap somehow otherwise his dashboard would be messed up when the aux channels wrap. He either needs to account for this when he writes to the DB or when he reads from it. I didnt recall a table that kept track of the number of wraps for each channel. Logging the number of wraps ina table and then adjusting the value on writes would seem to be the best way. If he had a table to store wrap counts, on a write he could store the KWH as (KWH of ECM) + 1193.04647*(Number of wraps per channel). If done this way the whole history in the usage table will be on the same wrap. Problem is I dont recall a place in the DB to store the number of wraps on a channel.
If he doesnt do that it would be tough to track how many wraps took place when comparing the KWH on one date to a previous. If the current KWH is less then KWH for a channel 30 days ago you can assume a wrap took place but you have no way to know how many wraps took place, it could certainly be more then one.
You don't need to store how many times it's wrapped. When you are storing data in the DB, you are storing the delta from the last reading.
For example:
In the case of wrapping:
But in reality, you would want something like this:
Note that this is for the AUX channels which have the 4-byte counters.
For example:
Code:
Current reading - Last reading = delta
4,294,967,100 - 4,294,967,000 = 100 Watt-secondsIn the case of wrapping:
Code:
If the current reading < last reading then
(4,294,967,295 - last reading) + current reading
So if the current reading was 230, then you would have:
(4,294,967,295 - 4,294,967,100) + 230 = 425 watt-secondsBut in reality, you would want something like this:
Code:
secondsdelta = delta of the seconds counter with wrapping taken into account
If current >= last then
reading = (current - last)/seconds
If current < last then
reading = (4294967295 - last + current)/secondsdeltaNote that this is for the AUX channels which have the 4-byte counters.
I am not writing to a database from the live data stream.. The logic you are using seems to to be something for if you are listening to the live stream. I am reading Pauls sqlite db, the ecm1.db3 file. I have a feeling paul takes care of that wrapping stuff as I dont see any of those wraps in the sqlite db.
Anyone know what the awsc or pwsc in the brultech db is? the awsc for each channel divided by the second counter it approx the same as kwh -10%. Example for channel 1 4199840565/3958088=1061 1061 is close to 1167.
For anyone that is interested, the db has two tables with usage data
table 1 - monitor_data_hourly
That table has a new entry for KWH for each channel on each device every for every hour. It appears the KWH usage here is the KWH usage over that hour. The KWH entries for each channel goes to 3 decimal places to the right (.001 being the smallest value). Based on that I assume I can just sum these values over the last day, 7 days or 30 days to get total usage over that period. I have a feeling this is what brultech dashboard queries to do its calcs.
There is a second table
In the monitordata_minute the data is as follows.. Everything here makes sense as far as real time data except the awsc and pwsc fields.
aux1awsc aux1kwh aux1watt aux2awsc aux2kwh aux2watt aux3awsc aux3kwh aux3watt aux4awsc aux4kwh aux4watt
695644655 193.235 186 839842680 233.29 191 172534547 47.926 114 322552798 89.598 320
aux5awsc aux5kwh ch1amps ch1awsc ch1kwh ch1pwsc ch1watt ch2amps ch2awsc ch2kwh ch2pwsc ch2watt
265833483 73.843 63 7.4 420242188 1167.339 4199840565 978 0.6 10436914 2.899 4448742 2
date deviceaddress id online secondscounter volt
2010-02-03 20:13:37 142265 743255 1 3958088 122.6
Anyone know what the awsc or pwsc in the brultech db is? the awsc for each channel divided by the second counter it approx the same as kwh -10%. Example for channel 1 4199840565/3958088=1061 1061 is close to 1167.
For anyone that is interested, the db has two tables with usage data
table 1 - monitor_data_hourly
That table has a new entry for KWH for each channel on each device every for every hour. It appears the KWH usage here is the KWH usage over that hour. The KWH entries for each channel goes to 3 decimal places to the right (.001 being the smallest value). Based on that I assume I can just sum these values over the last day, 7 days or 30 days to get total usage over that period. I have a feeling this is what brultech dashboard queries to do its calcs.
There is a second table
In the monitordata_minute the data is as follows.. Everything here makes sense as far as real time data except the awsc and pwsc fields.
aux1awsc aux1kwh aux1watt aux2awsc aux2kwh aux2watt aux3awsc aux3kwh aux3watt aux4awsc aux4kwh aux4watt
695644655 193.235 186 839842680 233.29 191 172534547 47.926 114 322552798 89.598 320
aux5awsc aux5kwh ch1amps ch1awsc ch1kwh ch1pwsc ch1watt ch2amps ch2awsc ch2kwh ch2pwsc ch2watt
265833483 73.843 63 7.4 420242188 1167.339 4199840565 978 0.6 10436914 2.899 4448742 2
date deviceaddress id online secondscounter volt
2010-02-03 20:13:37 142265 743255 1 3958088 122.6
bpwwer
Member
I believe those are the watt-second counter values. Each of the primary channels has two counters. 1 that counts watt-seconds regardless of energy flow direction (the awsc values) and the other counts watt-seconds for one direction only (the pwsc values). The direction is configuration on the device.
The directional (or polarized) values get used in net-metering situations where you may be feeding power back to the grid.
Hmm, this is an interesting point. You DO want to store counter values then, and not just the delta. Now that I think about it, if I'm reading a counter on a router via SNMP and storing it in RRD, it's storing the counter value. And RRD can automatically account for counter wrap if you create the DB appropriately with the rrdcreate tool.
The other reason to store counter (accumulators) values is to provide for missed packets.
If your database contains not only computed watts for the reporting period (usually each hour), you can write a query to show energy use for a day by easily totally the hours in that day. However, if your server was down for some period of time, you will have hours missing in the database. This will screw up your query that computes total energy for the month, etc.
If you also have the accumulators stored, you can write a simple utility to go through the database, find missing hours (or partial hours), compute the total energy use from before and after the gap, and fill in the missing hours with average values for the gap period. This way, your queries that total and average hour records will be accurate.
tenholde
If your database contains not only computed watts for the reporting period (usually each hour), you can write a query to show energy use for a day by easily totally the hours in that day. However, if your server was down for some period of time, you will have hours missing in the database. This will screw up your query that computes total energy for the month, etc.
If you also have the accumulators stored, you can write a simple utility to go through the database, find missing hours (or partial hours), compute the total energy use from before and after the gap, and fill in the missing hours with average values for the gap period. This way, your queries that total and average hour records will be accurate.
tenholde
I am not connecting to the real time stream and logging my own data. I am connecting to Brultech's sqlite DB. He already sums the KWH usage each hour for me. This is what he uses to graph all the usage summeries in the dashboard.
His process writes the KWH from the meter every few seconds(I showed the table in my lsat post). At the end of the hour he stores KWH usage for each channel over that hour into a seperate table.
If you pull serial connection on one of the ECMS the next record in his real time log stores the new higher KWH. At the end of the hour that shows up in the hourly table of power usage. Of course by pulling the serial connection usage gets time shifted foward to the first hour after you get the connection back but you dont loose any KWH.
Assuming Brultech is logging its own data correctly I get the easiest results by hitting his DB.
His process writes the KWH from the meter every few seconds(I showed the table in my lsat post). At the end of the hour he stores KWH usage for each channel over that hour into a seperate table.
If you pull serial connection on one of the ECMS the next record in his real time log stores the new higher KWH. At the end of the hour that shows up in the hourly table of power usage. Of course by pulling the serial connection usage gets time shifted foward to the first hour after you get the connection back but you dont loose any KWH.
Assuming Brultech is logging its own data correctly I get the easiest results by hitting his DB.
