Google's Energy Monitor... Not? Why?

(From Adafruit): Google PowerMeter is still closed.

Hey! Up there! I want it. And you want me to want it. Open it.

PS: Official letter of request for participation sent to Google PowerMeter team was ignored. Not even so much as an automated email confirmation. Regrettable.

Echoes: AC2

Found AC2 project while performing site cleanup.

Looks like course assignment, may or may not contain anything useful (will have to analyze in depth later).

Has non-zero entertainment value, quote: "I'm going to try to write something. Even if I have to make up shit."

Good thing about this project is that since it is hosted on Google Code, it will not slide into oblivion like ECVS did.

DZ3 Seeded

Program complexity grows until it exceeds the capacity of the programmer who must maintain it.

-- Seventh Law of Computer Programming

DZ2: FAIL

Let's face it, DZ2 was a fizzle. It never lived up to expectations, and was a half-pregnant, never finished abomination, raising little more than contempt.

I did hear the criticism, it's just that the complexity of the project exceeded either available time, or motivation, or attention span.

Since the last material change to the project (and I'm afraid I'll have to admit that it was 0.1p7dev3, almost exactly five years ago) I've met quite a few smart people and learned quite a few harsh lessons. Hopefully, became smarter, and definitely became more concise (hope you'll see a welcome change in the size of the code that implements the same functionality now).

WHAT BROUGHT DZ2 DOWN

• DZ was never thoroughly tested. Tests were never formal, it was a hit and miss process. Bugs existed in the code for years with no definite fix;
• Hardware integration was always a pain. There was a necessity to maintain the OWAPI, and bend over to RxTx;
• Initial installation and configuration was always a pain;
• There were too many "wow" features in the project;
• It eventually crumbled under its own complexity.

WHAT I AM DOING ABOUT IT

• All the code in the project will be continually verified with unit tests;
• Code base will be strictly divided into hardware and platform independent components, and those that are hardware or platform dependent;
  
• Each component will have its own, proper for its nature, deployment model (in particular, Maven is used for Java code);
• Implication is, there'll be less Java, hence, less integration pain. I sincerely hope to retire OWAPI and RxTx this time;
• One good thing stays, project subsystems will keep talking to each other over IP;
• Third party integration becomes ever more important, beginning with xAP/xPL and going further to whatever is the protocol du jour;
• Visualization becomes a separate subsystem. Current idea is to use jukebox-datastream architecture (which grew up from original DZ code) and deploy the server side on Google App Engine (and use their visualization API to look at the data);
• Scheduling becomes a separate subsystem, quite possibly based on Google Calendar API;
• Mobile integration is critical. Smart phones have become a reality, and they are much more [swmbo] acceptable as UI devices than your workstation. I'll take care of Android implementation, but the API will be open.

HOW YOU CAN HELP

• Please remember all your incidents and report them, no matter in how vague a way. I would probably be able to put my finger on it, and come up with a test case - and you'll be able to confirm the test case and the fix (case in point: A/C keeps running even though all registers are already closed);
• If you're up to some code review, this may be a good time to start, while it is still fresh and small. SourceForge project page now has an RSS Feed for Subversion updates much better than mailing lists that were (still are) massively spammed;
• If you have any suggestions regarding implementing hardware dependent components, you're more than welcome to voice them here. Implementations using compatible protocols are even more welcome.

CONCLUSION

Is this a total rewrite? Hell no. I've realized early on that the project has to be very modular, and what is happening now is more like hardening of individual components, though based on a different framework. It remains to be seen how different it will be - hopefully not much. (UPDATE: It seems that the new code base is significantly (three to five times) lighter than the old one)

WHERE IS THE NEW CODE BASE?

dz3-master is the root of the new code base, give it a try. jukebox-master is the only prerequisite that is not available from a public Maven repository, so getting the code base to build should be a breeze (compared to old, autoconf/automake based way.

Oh, by the way, on any platform now.

---

[The above is a refactoring of the original message that is available at the diy-zoning-general mailing list archive]

Measure, So You Can Improve - Now With Hardware

(take one)
(take two)

Google just announced that the first Power Meter compatible device that you can buy is available. Pricey (starts at about $200), but I bet things will improve with time.

Obvious DZ callback points:

• For those on load controllers, optimize switch on/switch off time, with a cost of zone hysteresis being a bit higher;
• Long term trend monitoring will allow to spot malfunctioning equipment much faster than it would otherwise be possible (often increased power consumption is the only symptom of impending failure, for equipment is usually out of earshot).

Measure, So You Can Improve - Take Two

Remember this?



Well, Google hasn't been sleeping on the job, and they now have the first batch of partners. See if your energy company is one of them.