Coming Up: Calendar Integration

You could see some pretty definite hints here, now it's coming to life. So, what exactly is it?

Generic Schedule Updater

ScheduleUpdater interface in dz3-scheduler module provides the interface, and AbstractScheduleUpdater provides the most generic baseline for implementing any back end integration. Want to store your schedule in a flat file? Be my guest. Want to read it off IRC? Anytime.

The updater is injected into the scheduler, so you're pretty much free in what and how you do it. That is, in case if you're not happy with the concrete implementation that will be a part of the release.

Google Calendar Integration

Just like it was planned, DZ will read the schedule from the the calendar of the account of your choice. Both Google and Google Apps accounts are supported, as well as pulling schedule details off any public calendars that you've subscribed to. Basic connectivity has already been implemented, details will be ironed out between now and next release.

DZ 3.4.1 "Scheduler-Console" Release Is Out

• Download from SourceForge
• Download from Google Code
• Get source code from Subversion

Changes since 3.4

• Current period is now displayed at the console;
• If the settings for a zone were altered against those specified for the period, a visible mark appears;
• Pressing 'S' will make the system follow the schedule again.

Configuration Changes Necessary

Scheduler bean needs to be injected into the console bean, just like other elements - see configuration guide for details.

A telltale sign that you forgot to do that would be absence of period information displayed despite scheduler working normally (can be verified by logs and charts generated).

Early Access: Period Display and "Back to Schedule"

Subversion contains code that allows to display the currently running period on the console. Also, pressing 'S' will now revert thermostat settings back to current period settings if they were altered (and there's a visible indicator for that, too).

DZ 3.4 "Scheduler-Barebones" Release Is Out

• Download from SourceForge
• Download from Google Code
• Get source code from Subversion

Changes since 3.3.2

Ability to change thermostat settings based on a schedule. Following settings can be changed:

• Setpoint;
• Voting status;
• Off status;
• Dump priority^*

No user interface is provided, the schedule can be set via configuration file only and cannot be changed during runtime - the focus of this release is to provide a stable and usable feature. Correctness of scheduler operation can for now be verified with data loggers - see configuration guide for details.

And this is how to configure the schedule for now:



The next major release will provide scheduling functionality with Google Calendar being the user interface. Details are described in FAQ: How Schedule Periods Work. Functionality provided by this release will be used as a bootstrap, default or fallback implementation.

---

^* This feature is configurable, but not yet activated

"Cold Start" Bug

(Bug report courtesy of TK)

Symptoms

On DZ startup, all zones immediately go to yellow, but the HVAC never starts.

Workaround

Bring all calling (yellow) zones to "green" state by changing setpoints, then put setpoints back at the desired value. Even simpler, flip all calling zones off, then on again. The HVAC will start as expected.

Bugfix

Since the bug pops up rarely (there's no need to reboot DZ every now and then, it appears to be rock stable now) , symptoms are immediately obvious, and there is a very simple workaround, the priority is now being set to low.

However, note that a newcomer will be a probable victim of this but: an hour of fiddling with thermostat wires to connect the DZ actuator will easily put the house into a state that will make this bug fire.

But then again, whoever gets to that stage is probably stable enough to be unaffected by such a simple issue :)

FAQ: How Schedule Periods Work

(IMPORTANT: Google calendar has a bug which makes all "forever" recurring events to last for just two years. If the calendar looks empty, scroll the example back to November 2017 to see the actual complex schedule breakdown).

Period scheduling already looks very similar to what is displayed below, and it will look even more like so as wrinkles are ironed out:



Clicking on the calendar button will request to add this calendar to your list of calendars (if you already have a Google account and are logged in) , or present you with Google authentication page. Adding a calendar is a reversible action - you can always remove it later (go to Settings/Calendars and click on Unsubscribe).

The only benefit of adding the calendar to your list is a nice full screen view of the schedule.

In any case, don't forget to click on individual event descriptions to find out how things work (this doesn't require being logged in). Note that the embedded view is scrollable.

Keep in mind that the link is live, and the content will change as details are sorted out.

At this point it is expected that each zone will have its own calendar, to reduce clutter. Moreover, it is currently expected that cooling and heating schedules will be represented by two sets of calendars, with the same purpose - you can easily select and deselect individual calendars, but it'll be a mess if you have more than one set of settings in the same calendar.

SheevaPlug Update

Here's the timeline of events, for those that are thinking of getting the device:

• December 17th - ordered the device;
• January 14th - sent a polite request for status;
• January 15th - they said they shipped it;
• January 19th - they shipped it;
• Jan 21th - it arrived.

Granted, there was a Christmas rush in between, but I guess this is what you realistically have to plan for, give or take.

Early Access: Scheduler

Subversion contains code that allows to change zone settings based on schedule. If you can read source code (dz3-scheduler is the module to look at) and configure a Spring IoC container, you will have no trouble utilizing it.

Test cases will give you a good idea how to put a schedule together.

jukebox-jmx presentation

External forces made me put together a short introduction to jukebox-jmx - below. Please remember that this is not a tutorial, but an introduction. If you do need a tutorial, The "Comments" link is right there, below this post.



UPDATE: Permissions fixed.

FAQ: "Off" Zones

Q: What does it mean when the zone is "off"?

A: It means that the system will not care about the temperature in thos zone at all, other than recording it if it is configured to do so.

Q: How do the dampers behave in the zone that is off?

A: The dampers will stay open when the HVAC unit is off, to give other systems (forced ventilation, humidifiers, dehumidifiers) chance to work without obstruction. The dampers will stay closed when the HVAC unit is running, unless there is a need to dump excess static pressure, in which case they will open barely enough to provide that.

Use Cases

• You don't need your bedroom at day, you may safely shut it off.
• You don't need anything other than the bedroom at night, you may safely shut it off.

Warning: Currently, "off" means "off", and there is no minimum temperature override for heating mode to prevent your pipes from bursting. If there is such a chance, lowering the setpoint to minimum allowable is the way to go. In the future, this override will be introduced.

FAQ: Non-Voting Zones

Q: What does it mean when the zone is made "non-voting"?

A: It means that the zone will not cause the HVAC unit to turn on, if it is the first zone to be calling for heating or cooling. Otherwise, it will behave exactly like it normally does - once the HVAC unit is running, this zone will be satisfied, even if it is the last one to be satisfied.

Keep in mind that zone's voting status is subject to schedule - a zone can be voting in one period and non-voting in another.

Use Cases

Good Case

This feature was originally intended to be used with small spaces like closets and bathrooms, which can overheat or cool down very quickly and cause HVAC unit to turn on and off unnecessarily often ("short cycling") - this is bad on the HVAC unit life, efficiency (it is "warming up" for 5 to 20 minutes, depending on the nature (A/C, heat pump, furnace, electric) and implementation), and electric or gas bill.

If the zone you set to non-voting status is satisfied before other zones are, it is a right thing to do.

Bad Case

This feature is not intended to take care of big rooms for the period when they are not occupied. This can be taken care by either setting those zones to "off" status, or lowering the setpoint (for heating) or raising it (for cooling).

If the zone you set to non-voting status still demands cool or heat after other zones are already satisfied, you're misusing the feature.

DZ 3.3.2 "Leakplug" Release Is Out

• Download from SourceForge
• Download from Google Code
• Get source code from Subversion

Changes since 3.3.1

• (cosmetic, UI) Pressing +/- on the keyboard will now cycle through all available Android screen sizes (in pixels);
• (fault tolerance) Hardware will now go into "power off" state upon DZ process termination;
• (JMX) Individual dampers can now be monitored via JMX;
• (hardware driver) One logical damper can now control multiple physical dampers (more than one register/damper per zone);
• (optimization) 1-Wire and servo controller drivers now use less heap memory in favor of local variables = less garbage collection chatter;
• (bugfix) On/off zone switch wors as designed now;
• (bugfix) Voting zone switch works as designed now;
• (bugfix) All zones must now be satisfied before the HVAC run ends, not just the one that initiated th run and the ones that happened to enter "calling" state before the first zone was satisfied;
• (critical bugfix) Removed a memory leak in 1-Wire driver code;
• (critical bugfix) Removed a memory leak in Servomaster code.

Servomaster 0.8.2.3 released

• Download from SourceForge
• Download from Google Code
• Get source from Subversion

CHANGES

• Minor: Parallax family driver code was optimized to reduce garbage collection chatter;
• Major: Plugged a memory leak causing Servomaster to blow DZ out of memory. This leak was occurring every time the transition controller was being engaged. Root cause of the leak was the missing NDC.remove() at the end of the thread life.

Memory Leak Hunt: Aftermath

Q: How much memory does DZ need to run?

A: Within JVM, less than 6MB of heap memory and about 19MB of non-heap, total 25MB - that is with all the features turned on, including JMX and console. Take a look at the picture below.



At the same time, JVM takes 177MB virtual memory, 57MB resident, and 10MB shared.

Q: How are you planning to prevent memory leaks in the future?

A: Starting with the next release (3.3.2), DZ JVM will be artificially constrained (-Xms4m -Xmx4m) to make sure that if it blows out of memory, it does it very fast and the leak can be identified and reported immediately.

Q: Will it affect system performance?

A: A little bit, you probably shouldn't care. Garbage collection will be happening once every few minutes instead of once every few hours. After you've ran DZ for a few hours (a day for most paranoid) in minimal configuration, you can safely remove the restriction - instructions will be provided within dz-runner script. Keep in mind, though, that amount of memory that JVM is taking out of the system may be higher if you do that, now, that may affect the system performance.

Q: How did you find the leak?

A: It was a trivial sequence of jmap and jhat runs (details at Monitoring and Managing Java SE 6 Platform Applications). In addition, some small and frequent memory allocations in OWAPI were replaced with local variables, to reduce garbage collection chatter.

Q: You're saying the leak is gone, but I keep getting OutOfMemoryException!

A: Possible. Leak free status was verified for DZ core, 1-Wire sensor driver, and Parallax servo controller driver running on Sun's JDK 1.6.0_17 under Ubuntu 9.10. First thing you need to do is to submit a detailed report including your hardware and platform details. jmap file (see the above link) right after the start and some time before the OutOfMemoryException will be much appreciated.

Early Access: Memory Leaks Plugged

Two major memory leaks were plugged this week:

• One in dz3-owapi module (related to the fact that OWAPI code was instantiating device containers on every browse() (that'll be about once a minute);
• One in Servomaster transition controller code (NDC.remove() wasn't called at the end of the thread life).

Code is available in Subversion (make sure you get both DZ and Servomaster updates.

Release will follow shortly.