Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[steven r]

Sorry about all the duplicate messages. The
forum kept giving me an error message when
I tried to submit. I guess it kept trying
also and finally posted them all.

[steven r]

Sorry about all the duplicate messages. The
forum kept giving me an error message when
I tried to submit. I guess it kept trying
also and finally posted them all.

This is the error message I keep getting:

Internal Server Error
The server encountered an internal error or
misconfiguration and was unable to complete
your request.
Please contact the server administrator,
webmaster@x10.com and inform them of the
time the error occurred, and anything you
might have done that may have caused the
error.

More information about this error may be
available in the server error log.

Please feel free to delete extra posts.

[steven r]

I just noticed that flag 16 has been set.
That means I now have flags 1, 15, & 16 now
set.

[X10 Pro]

We are using flags 15 and 16 (setting and
clearing them with timers) to track dusk/dawn
changes for conditions that use dusk/dawn.

[mike]

X10 Pro,

Please explain your last post more fully.
Are you saying that the cm15a is internally
using flags 15 & 16 and these should not be
used for other operations? If not, then are
you just giveing an example of how flags
can be used to allow dusk/dawn conditions
can be checked efficiently or ?

Mike

[X10 Pro]

If you are using Dusk/Dawn based conditions,
you shouldn't use flags 15 & 16. We're using
them internally. We didn't want to only give
you 14 flags to work with since we only use
them if you have Dusk/Dawn conditions, but we
should probably label them that we in the
software when they're in use.

[steven r]

"We are using flags 15 and 16 (setting and
clearing them with timers) to track
dusk/dawn changes for conditions that use
dusk/dawn."

In what conditions are they set? It might
be useful flag to test for in a conditional.

[mike]

Sorry Michael, still not nearly good enough.

1) Does this also apply to the use of
timers that trigger on dusk or dawn. I have
a timer attached to a module that
triggers "25 min before" dusk, yet I just
checked and flags 15 & 16 both remained
clear both before and after dusk here. We
need and deserve a better explanation of
what causes these flags to be used. I'm
curently using both!

2) "Daytime & Nighttime" show "require 2
entries" and actually do when used as
conditions in a Macro. Why, if you're
already setting flags for dawn/dusk
with "hidden" timers?

3) Why would you need TWO flags??? Why not
use one and set it for daytime and clear it
for nighttime???

4) I hope "we  should probably label them"
was careless writing and doesn't reflect
your attitude regarding the importance to
users of information like this.
Undocumented behavior like this can cause
your users MAJOR grief when mixed in with
chasing bugs like Burdy reported here or
the issue with macro behavior with a delay
at the start of an else macro that I
previously reported and was evidently fixed
without a mention in the release notes.

Mike

[steven r]

Ok that explains 15 & 16.
Any idea what I or AHP needs to do so I can
build a macro to set and clear flags 1-14?

[X10 Pro]

Mike: It was not my intention to be cavalier
about the documentation of this flag usage.
It's not currently documented and it needs to
be. My main point, however, was that we
should provide a label inside the program UI,
not just a write up in the Help file or
somewhere else. I'll see to it that we do that.

To answer your questions:

1) This does not apply to timers that use
Dusk/Dawn, only conditional macros.

2) Because of the way the logic to test for
night time and day time works, it requires
two of the condition slots in the macro.

3) There isn't a single test that you can do
inside the interface to determine day or
night. Two flags are required for this to work.

Steven R:

You can build the macro as you are doing now,
but instead of clicking on the "Run Macro"
button in the interface to get it to take
effect, just use a remote control to trigger
the macro.

[steven r]

"You can build the macro as you are doing
now, but instead of clicking on the "Run
Macro" button in the interface to get it to
take effect, just use a remote control to
trigger the macro."

I think you missed my post that I was
having problems *even with* a remote
trigger.

Since that earlier post I did get flag 1 to
clear with another macro. On the other
hand, for the two macros that are just to
set or clear flags, nothing is happening
even from a remote trigger.

e.g. I have two macros: "F2 ON" to set
flags 1-14 and macro "F2 OFF" to clear
flags 1-14. No other instructions are in
the macros except the one for the flag set
or clear. No flags are changed in either
case.

[Tuicemen]

Steven R  12/6/2004 04:15 PM
Ok that explains 15 & 16.  Any idea what I
or AHP needs to do so I can  build a macro
to set and clear flags 1-14?

This is what I've done :
creat a phantom module that off trigers a
macro in the macro place clear flag 1-14
then just click the phantom module and all
flags are cleared
if you want to set your flags for testing
use the phantom module on to trigger another
macro with the set 1-14 flags.

[Burdy]

Steven R, just a thought.. you are viewing
a 'new' status report to view the  modified
flags, correct?  Even though it looks like a
web page, it doesn't get updated dynamically
(or  by choosing 'refresh') if the flag bits
change. It has to be closed, then
regenerated from the file.. reports.. status
menu each time.  Other than that, I'd be
stumped as to why the flags aren't updating
with an RF trigger with a trivial single
step macro-- that operation has been pretty
predictable on my CM15A (for bits 1-14,
anyway).

[steven r]

"...you are viewing a 'new' status report
to view the modified flags, correct?"

Yes!

[mike]

X10 Pro,

Sorry for seeming testy about this but
finding out that flags I'm already using in
macros can be overwritten is disturbing.
I've spent a lot of time working through
bugs/undocumented behavior already and I
wanted to make sure "we should probably
label them" was just an unfortunate choice
of language. I'm glad it was just that. If
it wasn't, I'd be running for the exit here
since I've finally identified a good
standalone alternative with conditionals.

1) Can you confirm that ONLY the "Daytime"
and "Nighttime" "Conditions" cause flags
15/16 to be used?

2) I'd suggest posting this info
prominently in the General forum ASAP to
save users grief.

3) The implementation requiring 2 flags and
2 conditions to check seems brain dead.
Can't I just set up a timer that triggers
flag 16 on at dawn & off at dusk, then
check flag status appropriately to achieve
the same result with one flag bit and one
condition? With this approach, the check
doesn't even require an additional
conditions when I'm checking other flag
bits for the same state and only requires
one condition worst case. Am I missing
something?

I did a quick chack and when a daytime or
nighttime condition is used, flag 16 seems
off in daytime and on in nighttime. Flag 15
appeared to be always set. For the life of
me, I don't understand why flag 15 is being
used or why 2 conditions are still required
to check for daytime or nightime unless
flag 15 is being used in a misguided
attempt to ensure flag 16 is "valid".

Mike