Improving Curtain Automation

| No Comments | No TrackBacks

I automated my curtains quite some time ago, but over time I discovered a few issues that were not quite right. Some recent additions to Cortex have removed these problems.

It was quite a while before I noticed that curtain opening and closing could create false presence. It's only when the spare room curtains were enabled and the door kept closed that it became obvious that a phantom person was trapped in the room. It seems to be more likely to happen when the heating was on, I presume because greater air currents were stirred up by the motion.

Now, the phantom person is removed by the presence time-out, but this period is quite long, since these curtains are in bedrooms and have less motion in the night. Although the phantom presence could trigger a heating cycle I wasn't too bothered about this.

However, the downside of the false triggering became more apparent when I started to use the security functions and was also looking for fallback heating to automatically engage when I forgot to set it before we went away. The phantom gets created every day when the curtains move, and so this prevents the 24hr empty period for automatic fallback and also inhibits automatic arming of the alarm.

As I mentioned, v24 introduced some new features, and after a little debugging, recent updates have got this problem licked. The motor object used for curtain control now has an output trigger connection (Busy) that can be connected to a room's motion detector object ("Block the output") trigger input.

motion-connections.png

The busy output will be active for the duration of the motor activity, inhibiting the motion during this period. This does assume that any residual "shaking" of the curtains is not sufficient to cause triggering after the motor has stopped.

There is one other wrinkle that caught me out. I am using Motor Type 4, which was added to interface to SilentGliss type controls where button presses are emulated rather than direct control of current to a motor winding:

curtain-behavior-type.png

With this motor type, a short pulse of the relays causes the SilentGliss units to run to fully closed or fully opened, the actual duration of the pulse is not that critical. The open and close times can be set up in the motor control pane to allow for a degree of proportional opening based on time elapsed.

curtain-behavior-control.png

As you can see, here I have set up around 4 to 5 seconds, which is the time measured by my stopwatch for the curtains to open and close.

However, on the spare bedroom curtains I managed to confuse my units and configure the open and close times to 0.4 and 0.5 seconds. The curtains still open and close correctly, since this is a sufficient pulse for the SilentGliss units to initiate opening or closing. But this time period is also used to determine the duration of the Motor object "Busy" output. With such a short Busy signal, the motion detector in the spare room was not blocked for long enough and was still triggering the phantom presence. With other motor types this would have been obvious, since the timing would have been too short to move the curtains very far.

I was a little mystified why the main bedroom inhibit was working and the spare bedroom was not. Fortunately the Idratek guys were able to spot the mis-configuration very quickly and set me straight.

That's one of the issues I have had. The other issue I will save for another day.


No TrackBacks

TrackBack URL: http://www.gumbrell.com/cgi-bin/mt4/mt-tb.cgi/62

Leave a comment

About this Entry

This page contains a single entry by David published on February 24, 2009 12:12 AM.

BootCamp and Digicams collide was the previous entry in this blog.

Inspiration is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.