| ECS-L Home Automation and Security Archives |
| Subject: From: Date: | RE: [ECS] Re: PLC-TX Overflow Problem Michael David Sat, 23 Oct 1999 00:08:53 -0400 |
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