2.4.15: dependencies between programs

[evarsanyi]

I'm trying to build a simple state machine that cycles on an X10 received event. I thought I would have 2 programs that each use their status bit to contribute to the current state and push the 2 programs between states via X10 events and timeouts.

 

The problem I'm having is it seems like receiving an X10 event is being treated as a level trigger (the device/control state) rather than an event (X10 L9/On received) and so both programs are seeing the same L9/On event and cycling through quickly.

 

Is there some time window in which receipt of an X10 event is 'pinned' so every program can see it? How are cross dependencies between programs status handled (if you build a D flip flop with 2 programs status bits and actions that refer to each other what is the clock, or does every change in any state just make a single pass through every condition? If so how do you determine the order in which conditions are evaluated?)

 

The code is simple and probably clearer than my explanation/questions above:

 

RF1:

If
       X10 'L9/On (3)' is Received
Then
       Wait  5 seconds
       Run program 'RF1' (Else Path)
Else
  - No Actions - (To add one, press 'Action')

 

RF2:

If
       Program 'RF1' is True
   And X10 'L9/On (3)' is Received
Then
       Wait  5 seconds
       Run program 'RF2' (Else Path)
Else
  - No Actions - (To add one, press 'Action')

 

The idea is the first L9/On sets RF1 to state 'true' for 5 seconds, if we get to the end of the wait the 'run else' on itself sets it status to false. RF2 is 'armed' by RF1 being true and the 2nd L9/On similarly triggers it for 5 seconds after which it resets. My first attempt also had RF2 run the else in RF1 to clear it so only one of them would be 'true'.

 

If I can get this to work other programs will then trigger on the combined states of RF1/RF2 and do real work. My previous (hand built) Insteon system allowed state machines to be built and I used it for timers: turn on a fan with 1 click and it runs for 20 minutes, click again ON within a few seconds and it stays on until you turn it off, click yet again on and it goes back to 20 minutes.

[upstatemike]

The problem I'm having is it seems like receiving an X10 event is being treated as a level trigger (the device/control state) rather than an event (X10 L9/On received) and so both programs are seeing the same L9/On event and cycling through quickly.

 

 

I don't know how the logic in the ISY works but in most sytems I have used a "trigger" remains true through one complete pass of the program loop. In other words anything thing that triggers from L9-ON would be true unless you explicitly reset it to false befor the next affected program.

[evarsanyi]

I thought it might be like that, so I reversed the order of the AND in the 2nd program hoping it wouldn't see RF1 being true on the first 'pass' -- however it still triggers.

 

Maybe I can fool it with a short wait somehow... I'll try that. Thanks for the idea!

[IndyMike]

evarsanyi,

 

I've gotten around this in the past with another application (ActiveHomePro CM15a) by using user settable "flags" or X10 "dummy modules". This allows your second program to test the flag or dummy module state prior to executing.

 

I'm a newbie with the ISY-26 (2 days), but from what I can see neither of these options exist. Possibly a suggestion for future releases?

 

As upstatemike indicated, I believe you need a separate qualifier for your RF2 trigger.