| ECS-L Home Automation and Security Archives |
| Subject: From: Date: | Re: [ECS] Re: PLC-TX Overflow Problem Mark Gilmore Sat, 23 Oct 1999 08:27:20 -0700 |
I just uploaded a new beta which should correct most (if not all) of the "PLC-TX OVERFLOW" problems. Logic such as this: If Light Is OFF Then Light Set ON will now result in LIGHT becoming ON the next event-pass (eliminating redundant X10 transmissions) UNLESS other x10 commands have already been queued up (but this was always the case). -- Mark Gilmore Omnipotence (ECS home automation software) http://www.usit.com/omnip 423-745-0026 Michael David wrote: > > Hi Mark! > > Your suggestion below will work for some situations, but not all. However, > for those events, the problem can easily be solved by adding a simple flag > to the logic. > > Just out of curiosity, why did you change it so that the state of PLC items > update when he command is transmitted, rather than at the end of each pass. > Oh, did I just answer my question? :) > > Cheers! > > Michael David > michael@michaeldavid.com > > -----Original Message----- > From: Mark Gilmore [mailto:omnip@usit.net] > Sent: Friday, October 22, 1999 6:29 AM > To: ecs-list@netbloc.com > Subject: [ECS] Re: PLC-TX Overflow Problem > > Regarding the "PLC OVERFLOW" problem: > I think the latest beta upload will help with this problem > (but it will still exist to a degree). > I still don't have an acceptable solution (if one exists). > > But in the mean time, please try to avoid logic such as this: > If Dark Is True > And Light Is OFF > Then Set Light ON > This will cause the X10 unit/function commands to be sent > EVERY event-pass until the original unit/function commands > are actually transmitted (some 2 seconds later). The result > is that some 16 commands will be queued for output (assuming > 4 event-passes/sec). > > Use something like this instead: > If Dark Is NOW True > And Light Is OFF > Then Light Set ON > -- > Mark Gilmore > Omnipotence (ECS home automation software) > http://www.usit.com/omnip > 423-745-0026 > > Michael David wrote: > > > > Hi Mark! > > > > >How are we sending out these commands ? > > >Via normal SETs to LIGHT Items ? > > > > Yup. Here's an example: > > If Dark Is True > > And Front Yard Flood Is Not On > > Then Front Yard Flood Set On > > > > >If so, why the need to send them again ? > > > > I absolutely don't want them sent again. That is the problem. > > > > Let's look line two of example above: > > And Front Yard Flood Is Not On > > > > At startup, when ECS processes this event line, it will test true, and ECS > > will send the PLC command to turn the Front Yard Flood on. However, > since > > the state of PLC items aren't updating for several minutes, the state of > > the Front Yard Flood will still show as Off, and this line will continue > to > > test true. So, ECS will send the PLC command to turn on the Front Yard > > Flood again on the next event pass - and every pass thereafter for a > while. > > > > Make sense? > > Cheers! > > > > Michael David > > michael@michaeldavid.com > > > > -- > > Mark Gilmore > > Omnipotence (ECS home automation software) > > http://www.usit.com/omnip > > 423-745-0026 > > > > Michael David wrote: > > > > > > Hi Mark! > > > > > > Oh yeah - I should have thought of that. :) > > > > > > OK, since you can't try the .cfg I sent you, let me take another crack > at > > > explaining the problem. Here's the real issue with this version: > > > > > > When ECS starts, my config has it sending out about 50 PLC commands. > > > Unfortunately, it takes a REALLY LONG time (several minutes) for the > > states > > > of all those items to be updated to reflect the new state. This creates > a > > > BIG problem, because I often use logic that turns things on if they are > > not > > > on, or turns things off if they are not off. > > > > > > Here's the point-> Since most of the states on those 50 PLC items have > NOT > > > been updated by the next event pass, many of those PLC commands get sent > > > again. And again, and again, and again, and again, and again every > event > > > pass thereafter, until everything catches up. At some point, I just end > > up > > > with a few thousand PLC-TX overflow error messages. (yup - a few > THOUSAND > > > errors) > > > > > > So, the real difference between this new version, and previous versions, > > is > > > this: It never used to take more than a pass or two for the state of all > > > these PLC items to get updated. Now it takes several minutes. In fact, > > in > > > previous versions, while ECS was spitting out these 50 or so PLC > commands, > > I > > > could go to the group page, and change the state on a PLC item, and it's > > > state would immediately change. In this version, that is not the case. > > > Now, if I manually change the state of a PLC item while ECS is spitting > > out > > > those same 50 or so PLC commands, it's state doesn't change - for > several > > > minutes. > > > > > > Mark, I know I can be a bit wordy at times. I apologize for that. > > Clearly, > > > I am having trouble explaining this problem! > > > > > > How about this: > > > > > > It's now taking ECS several minutes to update the state of a PLC item to > > > reflect a state-change that actually happened several minutes earlier. > I > > > think that's bad. :) > > > > > > Cheers! > > > > > > Michael David > > > michael@michaeldavid.com > > > > > > -----Original Message----- > > > From: Mark Gilmore [mailto:omnip@usit.net] > > > Sent: Tuesday, October 19, 1999 11:17 AM > > > To: Michael David > > > Subject: Re: PLC-TX Overflow Problem > > > > > > Sorry guy, but I was really looking for a SMALL cfg > > > that would re-create the problem (I don't have one > > > REDAC, let alone 3). > > > As I stated before, the State of Light/Appliance Items > > > are not updated until the queued commands are transmitted. > > > This has always been the case, but it may be "more so" > > > in this update. > > > Forgetting cfgs, what is it we are trying to do ?? > > > -- > > > Mark Gilmore > > > Omnipotence (ECS home automation software) > > > http://www.usit.com/omnip > > > 423-745-0026 > > > > Michael David wrote: > > > > > > Hi Mark! > > > > > > Oh yeah - I should have thought of that. :) > > > > > > OK, since you can't try the .cfg I sent you, let me take another crack > at > > > explaining the problem. Here's the real issue with this version: > > > > > > When ECS starts, my config has it sending out about 50 PLC commands. > > > Unfortunately, it takes a REALLY LONG time (several minutes) for the > > states > > > of all those items to be updated to reflect the new state. This creates > a > > > BIG problem, because I often use logic that turns things on if they are > > not > > > on, or turns things off if they are not off. > > > > > > Here's the point-> Since most of the states on those 50 PLC items have > NOT > > > been updated by the next event pass, many of those PLC commands get sent > > > again. And again, and again, and again, and again, and again every > event > > > pass thereafter, until everything catches up. At some point, I just end > > up > > > with a few thousand PLC-TX overflow error messages. (yup - a few > THOUSAND > > > errors) > > > > > > So, the real difference between this new version, and previous versions, > > is > > > this: It never used to take more than a pass or two for the state of all > > > these PLC items to get updated. Now it takes several minutes. In fact, > > in > > > previous versions, while ECS was spitting out these 50 or so PLC > commands, > > I > > > could go to the group page, and change the state on a PLC item, and it's > > > state would immediately change. In this version, that is not the case. > > > Now, if I manually change the state of a PLC item while ECS is spitting > > out > > > those same 50 or so PLC commands, it's state doesn't change - for > several > > > minutes. > > > > > > Mark, I know I can be a bit wordy at times. I apologize for that. > > Clearly, > > > I am having trouble explaining this problem! > > > > > > How about this: > > > > > > It's now taking ECS several minutes to update the state of a PLC item to > > > reflect a state-change that actually happened several minutes earlier. > I > > > think that's bad. :) > > > > > > Cheers! > > > > > > Michael David > > > michael@michaeldavid.com > > > > > > -----Original Message----- > > > From: Mark Gilmore [mailto:omnip@usit.net] > > > Sent: Tuesday, October 19, 1999 11:17 AM > > > To: Michael David > > > Subject: Re: PLC-TX Overflow Problem > > > > > > Sorry guy, but I was really looking for a SMALL cfg > > > that would re-create the problem (I don't have one > > > REDAC, let alone 3). > > > As I stated before, the State of Light/Appliance Items > > > are not updated until the queued commands are transmitted. > > > This has always been the case, but it may be "more so" > > > in this update. > > > Forgetting cfgs, what is it we are trying to do ?? > > > -- > > > Mark Gilmore > > > Omnipotence (ECS home automation software) > > > http://www.usit.com/omnip > > > 423-745-0026