Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ukma!xanth!lll-winken!uunet!snjsn1!bilbo!greg From: greg@bilbo (Greg Wageman) Newsgroups: sci.electronics Subject: Re: X-10 schematics wanted Message-ID: <758@snjsn1.SJ.ATE.SLB.COM> Date: 20 Mar 89 18:51:30 GMT References: <1657@trantor.harris-atd.com> <6449@dayton.UUCP> <1684@trantor.harris-atd.com> <1132@pilchuck.Data-IO.COM> Sender: news@SJ.ATE.SLB.COM Reply-To: greg@sj.ate.slb.com (Greg Wageman) Distribution: na Organization: Schlumberger ATE, San Jose, CA Lines: 42 In article <1132@pilchuck.Data-IO.COM> del@pilchuck.Data-IO.COM (Erik Lindberg) writes: > >One feature I have always wanted, and none of the X10 devices I have found >supports, is the ability for the computer interface to determine the >status of the remote modules. Example: my porch light, which I absolutely >do not want turned off during certain hours, but don't mind if it is >turned on manually during other hours. Currently I have to program the >unit to force the light on every half hour during 'critical' time. Not >only is this inefficient in terms of timed events, but the porch light >could be off for up to 29 minutes. You are talking about closed-loop control. Obviously this is highly desirable. The problem I have with computer-controlling X10 is, what do you do about local-on/off events? Even if you know what state every module "should" be in at a given time of day, a local-on/off event doesn't generate any codes to tell the controller that the state of that module has changed, and should be remembered. Consequently, the controller does the wrong thing when it updates all the modules. There is good news! A recent article in "Circuit Cellar Ink" indicates that the X10 control language has been extended to include a "unit query" code and a "unit status" code. This would allow for the master controller to poll each module periodically to get its current state, which still doesn't solve the local-event problem, but is better than what exists now. The bad news is that, as yet, very few (possible no) modules reply to/generate these new codes. Longish .signature follows. Skip now, or don't complain! Greg Wageman ARPA: greg@sj.ate.slb.com Schlumberger Technologies BIX: gwage 1601 Technology Drive CIS: 74016,352 San Jose, CA 95110-1397 UUCP: ...!uunet!sjsca4!greg (408) 437-5198 ------------------ There's nothing I hate more than a Usenet posting which took three seconds to compose and three minutes to type, glibly dismissing three years (or three decades) of an author's work in three lines. ------------------ Opinions expressed herein are solely the responsibility of the author. (And the author wouldn't have it any other way.)