Energy EAGLE Discussion

Hi Mike.

Question: The docs say that the call takes an interval parameter:

<LocalCommand>
<Name>get_summation_values</Name>
<MacId>0xFFFFFFFFFFFFFFFF</MacId>
<Interval>{enumeration}</Interval>
<SummationType>{enumeration}</SummationType>
</LocalCommand>

I don't see that being sent; Doesn't it matter ?

Nope. It doesn't matter actually. It appears to assume a "day" Interval and a "delivered" SummationType. As you can see from the XML output you posted, the EAGLE is reporting readings for every hour (you have to convert the Timestamp values from hex to integer (which is seconds from UNIX epoch)). If you calculate the difference between consecutive Timestamps, you'll notice each interval is 3600 seconds (60 minutes) apart. So it looks like the plugin and EAGLE are talking okay.

Good thinking, adding that debug code. However, if you look at the XML output you posted, the last 2 readings (the only 2 readings for today) both show a Value of "0.0", so when they're added up by the plugin, the accumEnergyToday shows up as "0.0". The EAGLE appears to take a couple hours to actually generate the summation data for the first hour or two of new days. So, if you look at the EAGLE's summation data within an hour or two after midnight, you'll just see zeros for midnight and 1:00 AM. They eventually populate, but in this case, they don't help debug the problem. If you were to show debug logging now, I'll bet the accumEnergyToday value would increase with each hourly reading that falls on today.

Try enabling debug logging again, now that it's been a few hours after midnight, and see if the accumEnergyToday value increases as is expected. I'm betting that it does. One of the reasons the trigger may not be firing very quickly is because it seems it takes the EAGLE at least 15 minutes to update the hourly consumption value for the current hour. What's your trigger definition look like? Any conditions set?

It's working now !

Thanks !!

It's working now !

Thanks !!

Excellent! Glad to hear it.

I don't know whether this affects the results you are seeing, but Rainforest Automation has updated their Eagle firmware several times in the last couple of months - sometimes with fairly significant changes. I know that they have updated my Eagle firmware three times over the last couple of months, which corrected a few relatively minor problems I was having. The good news is that they can update the Eagle firmware remotely from Vancouver without any action required by you as long as they have your Eagle's address information. My latest update to Eagle firmware occurred a couple of weeks ago. This updated my firmware to version 1.4.21 (5017). They did indicate to me at that time that more firmware updates were expected in the future. The Eagle is clearly a work in progress - but mine has worked well since the updates were made.

Interesting. I knew that they could remotely update the firmware but didn't know that they were doing that already. I've only had mine a few weeks, so I don't know if they've done any firmware updates or not. Did you receive an email indicating that this had been done, or did you just discover it by comparing firmware versions from the past?

Just for the sake of sharing, my EAGLE shows:

Hardware: 3.2.3
Firmware: 1.4.27 (5278)
Date Code: 20121201EC051052

It's working now !

Thanks !!

Excellent! Glad to hear it.

One behavior that I can't explain; I'm not sure if it is intended, or a bug in the HW or the plug in.

In order to test out my setup, I have Indigo emailing me every time the Daily Usage # changes (It is being written to a variable, and a trigger is set to email every time the variable changes...). That has been working great for 24 hours.

Here is the weird part.

As the time approached midnight, I was getting:

Energy_Used_Today value changed to: 94.775 @ 11:33PM
Energy_Used_Today value changed to: 95.926 @ 11:49 PM

All was good.... but then at midnight, I got 2 messages:



First, the number went backwards:

Energy_Used_Today value changed to: 88.285 @ midnight

then it correctly reset itself a second later:

Energy_Used_Today value changed to: 0.0 @ midnight



So I was wondering if the first value could be some kind of a timestamp/math error, or if the Eagle is sending something funky ?
(I haven't had a chance to look at the code yet....)


Mike

So I was wondering if the first value could be some kind of a timestamp/math error, or if the Eagle is sending something funky ?
(I haven't had a chance to look at the code yet....)

The most likely explanation is that it's a result of the way the plugin adds up the accumEnergyToday value, the way the EAGLE represents timestamps for hourly energy usage values, and the fact that it's doing it right around midnight. The plugin relies on the timestamp values associated with each hourly energy usage summary value. If the time on the EAGLE (or the energy company, not sure which is setting that timestamp) is not exactly in sync with your computer's time, you may see this brief error in calculation. This is what causes it...

1. Computer's date and time is 2013-08-11 23:59:57.
2. EAGLE date and time is 2013-08-12 00:00:02
3. Energy EAGLE plugin reads data from the EAGLE.
4. EAGLE reports last 24 hours of energy usage. 23 of the readings are from 2013-08-11. 1 reading is from 2013-08-12.
5. Energy EAGLE (using your computer's time as a basis for comparison) adds up all the readings for the current day, which it still believes is 2013-08-11. So, only 23 of the values are added, as opposed to the 24 values added from the last time it added them all up.
6. The accumEnergyToday value decreases because 1 value from the EAGLE is not on the same day as the computer.
7. 5 seconds later (when Energy EAGLE reads data from the EAGLE again), the computer date and EALGE date are both 2013-08-12, so the accumEnergyToday values is updated to 0.0 (because 0.0 is the only reading that was reported for the new day).

As far as I know Rainforest Automation does not notify you when new firmware is available for the Eagle, and they will not update the firmware unless you authorize them to. My three firmware updates were the result of problem reports I submitted to their technical support personnel.

It looks like you have slightly newer Eagle hardware and firmware than I have, but I believe that I have one of the first Eagle units shipped.

Good to know. Thanks George.

Are you using the Energy EAGLE plugin? Is it working for you okay so far?

I am using the Energy EAGLE plugin 0.9.3 (haven't updated to 0.9.4 yet). It is working fine - no problems at all. Thanks for a great plugin. I also have the Eagle interfaced to Bidgely.com. Once I get a full billing cycle I will see how the two compare, and how the actual SCE bill compares with both. SCE has a rather complicated rate structure with summer and winter tiers as well as separate delivery and generation tiers, as well as separate bond charges and county and state taxes. They also have a basic charge and a DWR energy credit. I have tried to set up the cost parameters in the plugin to approximate these charges. We will see how well it works out.

I also have a TED 500 installed with an Indigo TED 5000 plugin. TED seem to report slightly higher instantaneous and daily energy consumption than the Eagle, but the Eagle should be very close to what SCE is seeing.

Cool. Thanks for the info. Yea, the EAGLE should actually show exactly the same amount of energy demand that SCE does, since it's reading the information directly from the same meter SCE is reading rather than measuring usage separately like a TED. Pricing: now that's a different story. And I thought PG&E's seasonal tiering structure was complex!

So I was wondering if the first value could be some kind of a timestamp/math error, or if the Eagle is sending something funky ?
(I haven't had a chance to look at the code yet....)

The most likely explanation is that it's a result of the way the plugin adds up the accumEnergyToday value, the way the EAGLE represents timestamps for hourly energy usage values, and the fact that it's doing it right around midnight. The plugin relies on the timestamp values associated with each hourly energy usage summary value. If the time on the EAGLE (or the energy company, not sure which is setting that timestamp) is not exactly in sync with your computer's time, you may see this brief error in calculation. This is what causes it...

1. Computer's date and time is 2013-08-11 23:59:57.
2. EAGLE date and time is 2013-08-12 00:00:02
3. Energy EAGLE plugin reads data from the EAGLE.
4. EAGLE reports last 24 hours of energy usage. 23 of the readings are from 2013-08-11. 1 reading is from 2013-08-12.
5. Energy EAGLE (using your computer's time as a basis for comparison) adds up all the readings for the current day, which it still believes is 2013-08-11. So, only 23 of the values are added, as opposed to the 24 values added from the last time it added them all up.
6. The accumEnergyToday value decreases because 1 value from the EAGLE is not on the same day as the computer.
7. 5 seconds later (when Energy EAGLE reads data from the EAGLE again), the computer date and EALGE date are both 2013-08-12, so the accumEnergyToday values is updated to 0.0 (because 0.0 is the only reading that was reported for the new day).

I am seeing anomalies during the day as well, possibly for the same reason:


Energy_Used_Today value changed to: 20.832 @ 6:42 AM
Energy_Used_Today value changed to: 21.667 @ 6:59 AM
Energy_Used_Today value changed to: 19.304 @ 7 AM
Energy_Used_Today value changed to: 22.326 @ 7:14 AM
Energy_Used_Today value changed to: 23.233 @ 7:30 AM
Energy_Used_Today value changed to: 22.326 @ 8 AM

Perhaps. However, I think in those cases it's more due to the way the EAGLE reports summary data each hour. It's been my observation that with each new hour, the EAGLE temporarily reports the previous hour summary value as 0.0 rather than the value it was at up to the current hour. About 15 minutes later it'll update both the previous hour and the current hour values, but for about 15 minutes after each hour, both the current hour and the previous hour show delivered energy values of 0.0. There might be a way to programmatically work around this anomaly, but because it's not documented anywhere, I'd be concerned that future EAGLE firmware updates would change this behavior, requiring a plugin update. Something I'll keep in mind though.

I have an Indigo scheduled action to retrieve and store the accumEnergyToday setting a few minutes before midnight every day so that I can review my daily usage. On most days this works correctly. However, on two separate occassions the value retrieved was incorrect. On both of these days the value shown in accumEnergyToday was identical to the accumEnergyTotal1 (ie; the total meter treading). Needless to say this fouled up other data such as daily cost. The accumEnergyThisCycle data appeared to be correct even though the daily data was way off.

I have an Indigo scheduled action to retrieve and store the accumEnergyToday setting a few minutes before midnight every day so that I can review my daily usage. On most days this works correctly. However, on two separate occassions the value retrieved was incorrect. On both of these days the value shown in accumEnergyToday was identical to the accumEnergyTotal1 (ie; the total meter treading). Needless to say this fouled up other data such as daily cost. The accumEnergyThisCycle data appeared to be correct even though the daily data was way off.

Yep. I've seen that too at least once. The reason the accumEnergyToday value was so high is because the EAGLE, for some unknown reason, calculated the energy usage for one of the hours in the energy demand summary for the day to be the total meter reading. The accumEnergyToday value is calculated by adding up all the hourly energy usage readings for the current day that the EAGLE reports. Since the EAGLE reported that obviously wrong value, the accumEnergyToday value was off as well. The accumEnergyThisCycle is calculated by subtracting the total meter reading when you first created the EAGLE device in Indigo (or when you last reset the billing cycle for the device) from the current total meter reading, so that's why that value appears correctly. Unfortunately, there's not much I can do to work around this occasional EAGLE reporting error. It might be a bug that we should report to Rainforest Automation though.

I have an Indigo scheduled action to retrieve and store the accumEnergyToday setting a few minutes before midnight every day so that I can review my daily usage. On most days this works correctly. However, on two separate occassions the value retrieved was incorrect. On both of these days the value shown in accumEnergyToday was identical to the accumEnergyTotal1 (ie; the total meter treading). Needless to say this fouled up other data such as daily cost. The accumEnergyThisCycle data appeared to be correct even though the daily data was way off.

Yep. I've seen that too at least once. The reason the accumEnergyToday value was so high is because the EAGLE, for some unknown reason, calculated the energy usage for one of the hours in the energy demand summary for the day to be the total meter reading. The accumEnergyToday value is calculated by adding up all the hourly energy usage readings for the current day that the EAGLE reports. Since the EAGLE reported that obviously wrong value, the accumEnergyToday value was off as well. The accumEnergyThisCycle is calculated by subtracting the total meter reading when you first created the EAGLE device in Indigo (or when you last reset the billing cycle for the device) from the current total meter reading, so that's why that value appears correctly. Unfortunately, there's not much I can do to work around this occasional EAGLE reporting error. It might be a bug that we should report to Rainforest Automation though.

I had this happen yesterday myself; The Eagle was reporting 28000 kWh for the daily total.

I confirmed that the web interface was showing the same bogus value.

It fixed itself @ midnight.

I reported it to Rainforest, but haven't heard anything.