Print

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

[Eric Edberg]

In my continuing saga to debug this software
I just noticed another critical logic fault.
This issue could be the root cause of
numerous faulty & un-reliable timers.

I once again decided to rebuild may DUSK
macro that was faulty (turning on lights it
was not programmed to).


Here goes:
----------------

deleted bad/faulty dusk macro & timers
recreated new dusk macro with only 3 events
in it.
all 3 were on's with dim to 46% with sleep 0
seconds in between each event
downloaded and tested macro
only 1 light came on
the two lights that did not come on have
worked reliably in previous faulty macros.
Edit'ed the macro and added two more events
to the end of the macro at the end

So, in this macro I now have:

O2 ON DIM TO 46%
sleep 0
O3 ON DIM TO 46%
sleep 0
E2 ON DIM TO 50%    <- this one works...
sleep 0
O2 ON DIM TO 50%
sleep 0
O3 ON DIM TO 50%


Reading this sequence literally, there are
two duplicate ON commands for 2 lights, both
DIMing to a different level.

What I expected to happen is that a redundant
ON command is programmed in case the first
one failed (which happen today).

What really happened was that the program
remembered the "supposed" state of the light
and only sent a single DIM 4% out the line.

Observations:
------------------
The macro remembered that it had previously
sent an ON command and ASSUMED the module was
on and neglected to send the second ON for
second/duplicated commands.

The macro remember the "supposed" dim level
and only sent a "relative" dim compared to
what it thought the status was.

There are multiple issues/problems:
---------------------------------------

I had selected ABSOLUTE when creating the macros.

*** Problem:  macro designer not remembering
absolute selection?

The modules are defined as 1-way lamp
modules.  ahp should never assume or remember
state information about 1-way devices unless
it can confirm it's status by a 2-way query.

When a macro is programmed to send 2 distinct
ON & DIM commands (as I programmed it to do)
then it should do just that.

I expect simple operation in the order I
program events.

This problem is similar to my other bug about
house-code parser errors.

I am not sure what other of our collective
faulty lights are related to ahp incorrectly
applying fault state machines to macros or
timers.

Is a state machine enabled between distinct
macros or is it only local to each macro?

This is another design/procedural issue that
needs review.

Eric Edberg

[X10 Pro]

Was this macro run from the computer? That
is, did you click the "Run Macro" button in
ActiveHome Pro? If not, was this macro
designated to be stored in the interface?

The behavior of macros run from the interface
and run from the PC can be slightly
different. The interface runs commands
exactly as they are stored. It doesn't take
module state, previous commands, or upcoming
commands into account -- it just runs the
command set exactly as stored.

Because the PC has the resources for it,
events run from AHP try to be smarter and to
use powerline transmission resources more
efficiently. If you turn a module on and then
dim it to 50% in AHP, running a macro to set
the module to 40% (set to 40% absolutely)
will send a 10% dim instead of brightening to
100% and then dimming down 50%.

We try to minimize powerline transmission to
prevent overlap of commands from other
devices (remotes, motion sensors) and
generally keep powerline performance strong.
X10 is a slow protocol and it has been our
goal not to send 1 seconds worth of dim
commands when only .25 seconds is needed. It
was also our goal to use the resources
available from the PC to make ActiveHome Pro
smarter than the interface on its own can be.

I understand wanting to things to execute
exactly as you expect and as defined. I'm not
sure how we can address that completely
without losing some of the benefits you get
from using the PC. I do think if you store
macros in the interface and use a remote
control or plug-in controller to trigger them
(that ensures that will run from the
interfaces memory) that you'll get what
you're looking for.

[Eric Edberg]

To verify the configuration, I just ran down
to the PC and verified that that macro was
STORE IN INTEFACE.  As a practice, I have
never knowingly created a macro that runs
from the PC.

So, in my case, I create all macros & timers
that run from the interface & then download
them to run.  With the CM15, I have left the
AHP sw up and running to capture activity logs.

Similar to other complaints recently, timers
and macros are un-reliable.  This was another
case in my saga when a macro did not run
correctly.

So I tried to execute it manually from the PC
and noticed the un-expected and un-natural
X10 sequence because of the state.

The macro was designed & programmed to run a
specific way in the inteface; the PC did not
run it the way I programmed it to, hence, the
DIM/memory inconsistency you point out.


The concept of using the PC as a smart
controller is great if it does not affect how
the users pervieve it to operate.  Now I am
not an X10 slouch or newby.  My history goes
from CP290, CM11 and now the CM15.

There are clear expectations your user
community has about how macro will operate
(both on the interface and PC).  Parsing
Macros and having ahp re-designin them to
operate in the order ahp decides (previous
bug) and/or remembering  state and altering
the commands being sent is really scary.

Consider the case of a complicated light
controller sequence.  If an ON THEN DIM 50%
is sent, how dare you decide for me to alter
what I wanted?  If is beyond comprehension
that after writing a program sequence I can't
be certian what commands are being sent.

The bottom line for this one is that a macro
that is stored in the interface should behave
and operate identicale when it operates on
the PC.  Consistency is crucial.

Having an option to "force" a command and
ignore previous state should be on by
default.  Any "intellegent-redesign" that ahp
performs on a macro should be optional.

You seem to forget that most of us have
worked with CP290s, CM11s in the past and
have a long history of programming
fault-tolerance into macros which now do not
work consistently between the interface and PC.


WYSIWYG:
Remember that principle; it's what we expect.

What I see in a macro is not what I get out!


Eric Edberg

PS:
last night was still on v3.2, I updated a
macro yesterday and re-downloaded it.  None
of my timers fired off. Lamps were on all
night and nothing was logged into the
activity log.

This update was to debug anohther macro
inconsistency I reported about a light that
was turning on in my dusk macro that was not
in the macro.