Controlling two lights with one switch

[greazer]

I'm trying to setup a program with two lights (on separate Insteon switches) to be controlled by one switch. The idea is:

 

Assume:

    switch1 is directly connected to light1

    light2 is on a separate switch but that switch isn't used here. 

 

1) If both lights are off and switch1 is turned on, then turn on the light that is controlled by the switch. (i.e. normal behavior)

2) If light1 is on and light2 is off and switch1 is turned on, then turn off light1 and turn on light2.

3) If light1 is off and light 2 is on, and switch1 is turned on, then turn on both lights.

4) If both lights are on and switch1 is turned on, then turn off both lights.

5) If either or both lights are on and switch1 is turned off, turn off both lights.

 

Basically I want switch1 to step through 4 states as it continually is turned on.

 

I have tried lots of things to try and make this work and it ALMOST does, but inevitably, daily I'll have the situation where both lights are off, switch1 is turned on and then light1 comes on, then goes off and light2 comes on. Basically, it's like the switch was pressed twice. However, I know for SURE that this isn't happening by being careful about just pressing the switch once, very deliberately.

 

Has anybody tried this and got it consistently working?   

[G W]

Post the program you are using so we can see what you are doing.

 

I'm Gary Funk. Pay no attention to this message.

[elvisimprsntr]

2 and 4 are not possible if light 1 is hardwired to switch 1. What you want is a 6/8 button keypad link and use scenes instead of programs.

[G W]

2 and 4 are not possible if light 1 is hardwired to switch 1. What you want is a 6/8 button keypad link and use scenes instead of programs.

It's possible, it's just not efficient and will take a few programs. And light one is going to come on and have be turned off by a program.

 

I'm Gary Funk and I approved this message.

[larryllix]

It would be much easier to us the double tap up and down to control the other light.

To achieve #2 you would double tap up and then down.

To achieve #4 ...you wouldn't. Tapping up to turn lights off would break the normal habits and confuse people, lowering the WAF.

 

But, as a logic problem....

Create four scenes...one for each scenario...on/on...on/off...off/on...off/off

Create four programs, one to operate each scenario..each with a trigger for a state variable = 0, 1, 2, 3.

You may require a Wait 1 second for the On turns it  Off programs.

 

Then use a program like this to rotate the state variable through all possible values.

 

If

....SwitchLinc is switched On

...AND

...$sVariable < 3

Then

...$sVariable += 1

Else

...$sVariable = 0

[stusviews]

It is simply not possible to turn off a load wired to an Insteon device by turning the device on. You can turn the load on at first and, subsequently after a brief pause, turn the load off. If that's what you want, then that is possible.

 

But it that is not what you want, then you'll need to add another device such as a Micro Module and wire the load to that instead.

[greazer]

Thanks for all the advice so far. I'm not that concerned about the immediacy of the behavior, just the correctness. As I originally tried to indicate, this actually works -- but not *all* the time. The trouble is that sometimes if both lights are off and I turn on switch1 then light1 comes on, then goes off and light2 goes on. Basically it skips a state. It's as if there is just a delay that is occurring in the hub or the Insteon network that is causing the hub to get confused as to what state it's in as lights are being turned on and off.

 

Here's my program (also note that at one point I was doing this with a state variable instead of having 'condition' and 'do' programs, but because of the issue I was having (SAME PROBLEM), I found some link that noted that the format I have below is the best way to achieve a proper state machine in the ISY. If I can't safely get away with using a variable to control state, I'd MUCH rather do that)

 

Master Bedroom/MB Fireplace Lights 1 = Switch1 which directly controls Light1 (as noted in my original post)

Master Bedroom / MB Upright Lamp = Light2

Note: Master Bedroom/MB Fireplace Lights 2 is not connected to a load/light. I simply use this as another switch to control Switch 1, just ignore it for now.

 

===================================================================================
MBFL.0 Manual Off Condition - [iD 002E][Parent 0025]

If
        Control 'Lights - Master Bedroom / MB Fireplace Lights 1' is switched Off
     Or Control 'Lights - Master Bedroom / MB Fireplace Lights 2' is switched Off
 
Then
        Run Program 'MBFL.0 Manual Off Do' (Then Path)
 
Else
   - No Actions - (To add one, press 'Action')
 

 

-----------------------------------------------------------------------------------
MBFL.0 Manual Off Do - [iD 0078][Parent 0025][Run At Startup]

If
   - No Conditions - (To add one, press 'Schedule' or 'Condition')
 
Then
        Run Program 'MBFL Auto Off' (Else Path)
        Run Program 'MBFL.1 FireplaceOnly Do' (Else Path)
        Run Program 'MBFL.2 LampOnly Do' (Else Path)
        Run Program 'MBFL.3 Both Do' (Else Path)
        Run Program 'MBFL.4 BothOff Do' (Else Path)
        Set 'Lights - Master Bedroom / MB Upright Lamp' Off
        Set 'Lights - Master Bedroom / MB Fireplace Lights 1' Off
        Set 'Lights - Master Bedroom / MB Fireplace Lights 2' Off
        Wait  2 seconds
 
Else
   - No Actions - (To add one, press 'Action')
 

 

-----------------------------------------------------------------------------------
MBFL.1 FireplaceOnly Condition - [iD 0026][Parent 0025]

If
        Program 'MBFL.0 Manual Off Do' is True
    And (
             Control 'Lights - Master Bedroom / MB Fireplace Lights 1' is switched On
        )
 
Then
        Run Program 'MBFL.1 FireplaceOnly Do' (Then Path)
 
Else
   - No Actions - (To add one, press 'Action')
 

 

-----------------------------------------------------------------------------------
MBFL.1 FireplaceOnly Do - [iD 0079][Parent 0025]

If
   - No Conditions - (To add one, press 'Schedule' or 'Condition')
 
Then
        Run Program 'MBFL.0 Manual Off Do' (Else Path)
        Run Program 'MBFL.2 LampOnly Do' (Else Path)
        Run Program 'MBFL.3 Both Do' (Else Path)
        Run Program 'MBFL.4 BothOff Do' (Else Path)
        Run Program 'MBFL Auto Off' (Else Path)
        Wait  2 seconds
 
Else
   - No Actions - (To add one, press 'Action')
 

 

-----------------------------------------------------------------------------------
MBFL.2 LampOnly Condition - [iD 0018][Parent 0025]

If
        Program 'MBFL.1 FireplaceOnly Do' is True
    And (
             Control 'Lights - Master Bedroom / MB Fireplace Lights 1' is switched On
        )
 
Then
        Run Program 'MBFL.2 LampOnly Do' (Then Path)
 
Else
   - No Actions - (To add one, press 'Action')
 

 

-----------------------------------------------------------------------------------
MBFL.2 LampOnly Do - [iD 007A][Parent 0025]

If
   - No Conditions - (To add one, press 'Schedule' or 'Condition')
 
Then
        Run Program 'MBFL.0 Manual Off Do' (Else Path)
        Run Program 'MBFL.1 FireplaceOnly Do' (Else Path)
        Run Program 'MBFL.3 Both Do' (Else Path)
        Run Program 'MBFL.4 BothOff Do' (Else Path)
        Run Program 'MBFL Auto Off' (Else Path)
        Set 'Lights - Master Bedroom / MB Upright Lamp' On
        Set 'Lights - Master Bedroom / MB Fireplace Lights 1' Off
        Wait  2 seconds
 
Else
   - No Actions - (To add one, press 'Action')
 

 

-----------------------------------------------------------------------------------
MBFL.3 Both Condition - [iD 002C][Parent 0025]

If
        Program 'MBFL.2 LampOnly Do' is True
    And (
             Control 'Lights - Master Bedroom / MB Fireplace Lights 1' is switched On
        )
 
Then
        Run Program 'MBFL.3 Both Do' (Then Path)
 
Else
   - No Actions - (To add one, press 'Action')
 

 

-----------------------------------------------------------------------------------
MBFL.3 Both Do - [iD 007B][Parent 0025]

If
   - No Conditions - (To add one, press 'Schedule' or 'Condition')
 
Then
        Run Program 'MBFL.0 Manual Off Do' (Else Path)
        Run Program 'MBFL.1 FireplaceOnly Do' (Else Path)
        Run Program 'MBFL.2 LampOnly Do' (Else Path)
        Run Program 'MBFL.4 BothOff Do' (Else Path)
        Run Program 'MBFL Auto Off' (Else Path)
        Set 'Lights - Master Bedroom / MB Fireplace Lights 1' On
        Set 'Lights - Master Bedroom / MB Upright Lamp' On
        Wait  2 seconds
 
Else
   - No Actions - (To add one, press 'Action')
 

 

-----------------------------------------------------------------------------------
MBFL.4 BothOff Condition - [iD 002D][Parent 0025]

If
        Program 'MBFL.3 Both Do' is True
    And (
             Control 'Lights - Master Bedroom / MB Fireplace Lights 1' is switched On
        )
 
Then
        Run Program 'MBFL.4 BothOff Do' (Then Path)
 
Else
   - No Actions - (To add one, press 'Action')
 

 

-----------------------------------------------------------------------------------
MBFL.4 BothOff Do - [iD 007C][Parent 0025]

If
   - No Conditions - (To add one, press 'Schedule' or 'Condition')
 
Then
        Run Program 'MBFL.0 Manual Off Do' (Then Path)
        Wait  2 seconds
 
Else
   - No Actions - (To add one, press 'Action')
 

[stusviews]

Your programs only address if a device is "switched off," but all your premises indicate what you want to occur if the device is "switched on." You are inconsistent. So, which is it?

[greazer]

Thanks, but I'm not sure what you mean. There are definitely checks to see whether the switch has been turned on. Note that the "switched on" event fires even if the switch was on before you physically clicked it on again. Essentially this set of programs implements a state machine that is controlled by the True/False state of each "Do" subroutine. See http://forum.universal-devices.com/topic/5410-triggers-and-conditions-and-ifs-oh-my for what I'm talking about.  

[larryllix]

I haven't followed all your logic through. It is too twisted and spaghetti bowl for me (I wouldn't use program true/false logic) but...

 

You are trying to operate devices On and off at the same time without any delays. This can, and usually, results in a race netting random results. The processing logic order, inside ISY, is not clearly defined to the programmer, and no guarantee of order will happen.

 

You have separated your If sections and your Then sections into different programs. I see no reason for that.

You have Wait on the last line of programs. Then there is no following line. You are waiting for nothing to follow.

[Teken]

I've read this entire thread and I just have to shake my head . . .

[greazer]

Yeah, I totally agree its not fun to read through. I hate it too. However, my original set of programs that controlled this state machine that used a state variable (or a variable that kept a state value) had the same problem. As I was pursuing trying to fix THAT problem I ran across the link that basically argued splitting your state machine logic into "condition" and "do" programs. I figured, ok, maybe this is the blessed way of doing this. I'm not expecting any of you to read that and what I'm gathering, I should just ignore it (perhaps it's old information before ISY provided the ability to save state in a variable, I have no idea).

 

Look, I've been a professional programmer at Microsoft for 20+ years and I now manage developers in the Visual C++ organization at Microsoft. So I know what I'm doing when it comes to programming. However, the way the ISY is programmed and the interaction with Insteon devices is just wrought with weird behavior. I'm trying to wrap my head around what's going on. I've considered going down the path of actually using C++ or C# and a PC to do this stuff, but I was hoping to help another friend of mine who doesn't have a programming background, so I figured I should get good at using this admin console thing.

 

So, larryllix -- So you're saying that when I make a state change in the ISY of a device I should have a wait of a second or two or whatever time it typically takes for a change to occur. Fine I can do that. Of course it would be nice if the ISY had some sort of defined behavior OR if there were synchronization mechanisms built in to provide a consistent solution. Creating wait's is the equivalent of adding sleeps in a regular program to try and fix multithreading problems. That's ridiculous. But if that's all there is, then that's all there is. Also the wait's on the last line of the programs was just part of a desperate move to try and make different behavior happen. They didn't fix anything so I will remove them.

 

Teken -- thanks

 

What I'll do is redo this whole thing using a variable to track state instead.

[greazer]

Oh, I just found this in that link I posted too (added after I originally found it and started using this spaghetti technique... sigh...)

 

"EDIT: Version 3 of ISY firmware allows the use of integer-valued variables in our programs. The variables come in two flavors: state variables and non-state variables. Both state and non-state variables can be used to great advantage, simplifying the structure of the state-machine programs that are described below.

Ergodic has described how the state variables can be used. You can see that post here: http://forum.univers...riables-part-1/."

 

[larryllix]

Yeah, I totally agree its not fun to read through. I hate it too. However, my original set of programs that controlled this state machine that used a state variable (or a variable that kept a state value) had the same problem. As I was pursuing trying to fix THAT problem I ran across the link that basically argued splitting your state machine logic into "condition" and "do" programs. I figured, ok, maybe this is the blessed way of doing this. I'm not expecting any of you to read that and what I'm gathering, I should just ignore it (perhaps it's old information before ISY provided the ability to save state in a variable, I have no idea).

 

Look, I've been a professional programmer at Microsoft for 20+ years and I now manage developers in the Visual C++ organization at Microsoft. So I know what I'm doing when it comes to programming. However, the way the ISY is programmed and the interaction with Insteon devices is just wrought with weird behavior. I'm trying to wrap my head around what's going on. I've considered going down the path of actually using C++ or C# and a PC to do this stuff, but I was hoping to help another friend of mine who doesn't have a programming background, so I figured I should get good at using this admin console thing.

 

So, larryllix -- So you're saying that when I make a state change in the ISY of a device I should have a wait of a second or two or whatever time it typically takes for a change to occur. Fine I can do that. Of course it would be nice if the ISY had some sort of defined behavior OR if there were synchronization mechanisms built in to provide a consistent solution. Creating wait's is the equivalent of adding sleeps in a regular program to try and fix multithreading problems. That's ridiculous. But if that's all there is, then that's all there is. Also the wait's on the last line of the programs was just part of a desperate move to try and make different behavior happen. They didn't fix anything so I will remove them.

 

Teken -- thanks

 

What I'll do is redo this whole thing using a variable to track state instead.

Yeah, many seasoned programmers have trouble with event driven software systems, over inline code systems. I sent a lot of time with VB and a real-time OS system doing electrcal grid protection with it. I loved it but definitely some screwy techniques needed.

 

Yes, the wait is like an old Windows psuedo multi-tasking OS when you voluntarily give up your time slice to the OS so that other programs may run.

 

Waits only need to be used, in this case, when a device may be operated simultaneously from two different programs or devices. It has unpredictable results.

 

Your programs do a lot of overhead/homework to work off other program statuses. This complicates understanding. Calling other programs from Trigger only programs adds a lot of program complexity too.

 

Must run at the moment.

[greazer]

Thanks larryllix! Really appreciate the advice. Eventually, I hope to grock this stuff.

 

In any event, this is my new state machine. Much simpler, and it does work. At least the few times I've just tried it. However I suspect when my wife comes home tonight and turns on switch1, it'll turn on the expected lights, then turn them off and turn on the upright lamp (lamp2). I.e. it'll move through two states with one on toggle. If there's something obvious I should do, I'm all ears.

 

(Again, remember that Fireplace Switch 2 isn't actually physically controlling a light. It's just an extra switch that I setup as a virtual 3-way with Fireplace Switch 1.)

 

 

===================================================================================
MBFL.0 Manual Off  - [iD 0093][Parent 0099]

If
        Control 'Lights - Master Bedroom / MB Fireplace Lights 1' is switched Off
     Or Control 'Lights - Master Bedroom / MB Fireplace Lights 2' is switched Off
 
Then
        $MBFireplaceSwitchState  = 0
        Set 'Lights - Master Bedroom / MB Upright Lamp' Off
        Set 'Lights - Master Bedroom / MB Fireplace Lights 1' Off
        Set 'Lights - Master Bedroom / MB Fireplace Lights 2' Off

-----------------------------------------------------------------------------------
MBFL.1 FireplaceOnly  - [iD 0094][Parent 0099]

If
        $MBFireplaceSwitchState is 0
    And (
             Control 'Lights - Master Bedroom / MB Fireplace Lights 1' is switched On
          Or Control 'Lights - Master Bedroom / MB Fireplace Lights 2' is switched On
        )
 
Then
        $MBFireplaceSwitchState  = 1
        Set 'Lights - Master Bedroom / MB Upright Lamp' Off
        Set 'Lights - Master Bedroom / MB Fireplace Lights 1' On
        Set 'Lights - Master Bedroom / MB Fireplace Lights 2' On
 
-----------------------------------------------------------------------------------
MBFL.2 LampOnly  - [iD 0095][Parent 0099]

If
        $MBFireplaceSwitchState is 1
    And (
             Control 'Lights - Master Bedroom / MB Fireplace Lights 1' is switched On
          Or Control 'Lights - Master Bedroom / MB Fireplace Lights 2' is switched On
        )
 
Then
        $MBFireplaceSwitchState  = 2
        Set 'Lights - Master Bedroom / MB Fireplace Lights 1' Off
        Set 'Lights - Master Bedroom / MB Fireplace Lights 2' Off
        Set 'Lights - Master Bedroom / MB Upright Lamp' On
 
-----------------------------------------------------------------------------------
MBFL.3 Both  - [iD 0096][Parent 0099]

If
        $MBFireplaceSwitchState is 2
    And (
             Control 'Lights - Master Bedroom / MB Fireplace Lights 1' is switched On
          Or Control 'Lights - Master Bedroom / MB Fireplace Lights 2' is switched On
        )
 
Then
        $MBFireplaceSwitchState  = 3
        Set 'Lights - Master Bedroom / MB Fireplace Lights 1' On
        Set 'Lights - Master Bedroom / MB Fireplace Lights 2' On
        Set 'Lights - Master Bedroom / MB Upright Lamp' On
 
-----------------------------------------------------------------------------------
MBFL.4 BothOff  - [iD 0097][Parent 0099]

If
        $MBFireplaceSwitchState is 3
    And (
             Control 'Lights - Master Bedroom / MB Fireplace Lights 1' is switched On
          Or Control 'Lights - Master Bedroom / MB Fireplace Lights 2' is switched On
        )
 
Then
        Run Program 'MBFL.0 Manual Off ' (Then Path)

[jtara92101]

However, the way the ISY is programmed and the interaction with Insteon devices is just wrought with weird behavior. 

 

 

I don't find it weird.

 

You are fighting with the basic functionality of the switch. You tap the top, the load turns on. You tap the bottom, the load turns off. Consider it "hardwired".

 

In hindsight, it would have been a slicker design if the switchlinc could be configured to divorce the paddle from the load. Perhaps it could be a controller/responder pair, where it is pre-configured to link the controller to the responder, but you might be able to reconfigure to break that link. (And I've LONG wondered why they've never produced paddles and keypads that don't have the circuitry for controlling the load...)

 

But the Insteon design is the Insteon design, and you can't blame UDI.

 

You might be able to play some games with ramp rate to make the light turning on briefly when you don't want it to less noticeable. You could re-configure the ramp rate in a program. But be warned that repeatedly re-configuring will eventually wear the flash memory. I do have some older devices where the flash memory is now kaput. (But it ought to be much better with newer devices, just because of advances in flash memory.)

 

The sort of thing you are doing would more typically be done with a keypadlinc, preferably with one of the little buttons, not the on/off that control the load.

 

If the flash bothers you, follow previous advice and use a micro dimmer. They are a great product! I use one in a closet that had a pull-cord lamp which I replaced with a flat LED panel. A micro dimmer in the ceiling box and a mini remote switch stuck to the wall got rid of the hazardous (and illegal, at least by current code) glass globe and stupid pull-cord without tearing into walls. I will be using more micro dimmers!

[elvisimprsntr]

I go back to my previous post. Buy a 6 or 8 button keypadlinc in dimmer or relay form.

 

Here endeth the lesson.

[G W]

I go back to my previous post. Buy a 6 or 8 button keypadlinc in dimmer or relay form.

 

Here endeth the lesson.

I agree. In this instance a keypad and four scenes are the better solution.

 

I'm Gary Funk and I approved this message.

[greazer]

Sure. I could and have considered splurging for yet another device or two. But given the program I have almost works, I'm trying to figure out the logic as to why it DOESN'T work when it doesn't.

 

Also can anybody categorically tell me that switching a lightswitch from within an ISY Then clause will or will not cause an event to fire and thus cause another program to run? If it CAN, then this could explain the behavior I'm seeing. However, from what I've been seeing that doesn't seem to be the case.

[larryllix]

I have the other view. I hate the look of the KPL. Although it has it's uses and may look OK in those applications. eg. fan speed control where there are multi-levels of speeds, maybe light levels. Think about a stranger, guest in your house that you would have to explain to them how to turn on a basic light switch! The WAF is not there either. They don't like to be "trained".

 

I think a light switch doing light based jobs is what we expect and can be laied out to work as similar to a mechanical switch as possible.

 

I have a large Gathering Room with one main switchlinc dimmer.

That same switch performs 8 different functions that take very little training.

That same switchlinc controls, 7 Insteon overhead flood lights, 5 Hue bulbs, 4 MiLight bulbs, and 5 RGBWW LED strips, including colour schemes.

 

• tap down = everything off
• double tap down = turns off all white ceiling potlights, and turns perimeter Hues, Milight bulbs and strip coloured to a seasonal theme determined by the date/season for festive lighting only.
• long tap down = Movie mode with very low whites and coloured perimeters similar to above
• long tap up = all white lights semi bright
• double tap up = all white full briliiance (like an operating room with about 300W of LED)
• tap up = toggles between TV mode and reading mode (a little brighter over the chairs)

This is done by switch control programs that set a state variable to values between 0 and 20 and nothing else. Constant variables help clarify usage there (see below)

 

I use a bank of programs in a separate folder that only recognise those state variable values and set the whole room to the desired effect.

I use scenes for the Insteon bulbs and call them but there are many more non-Insteon bulbs that take NR, and Nodelink on a RPi, as well as my own NRbridge.py on the same RPi. Scenes are not necessary but make it quicker and more simultaneous than just programs.

 

When you borrow a light for some alarm etc.. you only have to replace the value in the control state variable and everything is forgiven and back to the way it started again.

 

WAF is high due to just tapping the top of the switch to turn lights on and tapping down to get lights off. If you want more light tap up again. Double tap up for even more light. We use that for dull days and the depression is much less on so many grey days we get.  I could mesaure the difference, I am sure. And yet, the same lights are used for movie watching late at night with multi-coloured themic lighting to set the mood.

 

Greazer, the variables are a good start toward the way I would do it again. You have simplified your package a fair bit. Looks good.

I do find the tap down to turn things On counterintuitive though. Make sure you use a wait on that one.

 

BTW: Most of us prefix variables with $s.xxxxx or $i.xxxxx. I only prefix state variables with $sXxxxxxxxx and not integer variables, so I/we don't get caught with the huge difference in function later. I also prefix constant variables (integer) with prefix $cXXXXXXX to keep all these values easy and not confused.

[oberkc]

Also can anybody categorically tell me that switching a lightswitch from within an ISY Then clause will or will not cause an event to fire and thus cause another program to run?

Quite contrary.  I can tell you categorically that triggering a switch via program THEN clause CAN cause another program to trigger (and run).  For example...a program such as:

 

if time is sunset

then turn on light

 

will cause this program to trigger (if light was previously off):

 

if status of light is on

then do something

 

But given the program I have almost works, I'm trying to figure out the logic as to why it DOESN'T work when it doesn't.

I am like many of the others...my gut reaction is that you have a lot of unneeded complications and I am having trouble mustering the ambition to try to follow the threads.

 

Still, from an intellectual (and potentially practical) excercise, assuming you don't mind lights making several transitions to their end state, I see no reason why your objective cannot be accomplished.  I am ignoring the complications and possible error handling associated with insteon communication errors and treating this purely as an ISY programming excercise. I am also ignoring any timing issues or wait conditions.  (I have never had much need for these, personally, but would address only if needed for a specific application.)  To start, I would summarize your goal:

 

Upon each manually-triggered ON command from switch1, you want it to progress through the following states (switch1/switch2):

 

off/off (I will call this state 0)

on/off (I will call this state 1)

off/on (I will call this state 2)

on/on (I will call this state 3, but no program is needed to track.  State will be assumed condition if states 0,1, and 2 are all false)

back to off/off (back to state 0)

 

Additionally, if switch1 is manually-triggered OFF, you want switch1 and switch2 to turn off, regardless of original state.

 

My initial inclination is to use a version of your state machine to track which state (0, 1, 2, or 3) your two lights are in.  One could use variables here if it helps visualize things easier, but I tend to avoid variables except where I can think of no practical alternative.  Make three programs, one each for states 0, 1, and 2.  No program is needed for state 3, since it can be tracked based upon the other three states being all false.  An exampl program for state 0:

 

if

status switch1 is off

and status switch2 is off

then

nothing

else

nothing

 

I would create three such programs, one for each of the first three states, planning to use program=true/false as a later program condition. One advantage to this method is that this will accurately keep track of status regardless of how arrived (for example, what happens when someone presses switch 2, even if accidentally?)

 

I know that I want to trigger a lighting state change only upon ON commands from switch1.  I also know that I want both lights to go off when switch1 sends an OFF command.  I would deal with this as follows:

 

if

control switch1 is turned ON

and control switch1 is not turned OFF

then

run next program (if path)

else

turn both lights off

 

For the next program(s) I would create a series of programs checking the current state and taking the appropriate reaction.  All of these programs should be disabled, so that they do not self trigger. 

 

Next program (disabled)

if

state0 program is true

then

turn on switch1 (switch2 is already off, by definition)

else

run nextA program (if path)

 

nextA program

if

state1 program is true

then

turn off switch1

turn on switch2

else

run nextB program (if path)

 

nextB program:

if state2 program is true

then

turn on switch1 (switch 2 is already on)

else

turn off switch1 (if I have gotten this far and states 0, 1, and 2 have all been false, then it must have been in state three, thus next step is turn off both lights)

turn off switch2

 

Hopefully, this gives you some ideas to consider and possible things to look for in your own programs to get them to work.  Given your line of questions thus far, it may only be necessary to disable some of your programs to get everything to work.

 

As is often the case, I make no attempt to be efficient at programming or minimizing numbers of programs or lines of code.  With a little extra thought this could be reduced significantly, I suspect.

[Teken]

 

I have the other view. I hate the look of the KPL. Although it has it's uses and may look OK in those applications. eg. fan speed control where there are multi-levels of speeds, maybe light levels. Think about a stranger, guest in your house that you would have to explain to them how to turn on a basic light switch! The WAF is not there either. They don't like to be "trained".

 

I think a light switch doing light based jobs is what we expect and can be laied out to work as similar to a mechanical switch as possible.

 

I have a large Gathering Room with one main switchlinc dimmer.

That same switch performs 8 different functions that take very little training.

That same switchlinc controls, 7 Insteon overhead flood lights, 5 Hue bulbs, 4 MiLight bulbs, and 5 RGBWW LED strips, including colour schemes.

 

• tap down = everything off
• double tap down = turns off all white ceiling potlights, and turns perimeter Hues, Milight bulbs and strip coloured to a seasonal theme determined by the date/season for festive lighting only.
• long tap down = Movie mode with very low whites and coloured perimeters similar to above
• long tap up = all white lights semi bright
• double tap up = all white full briliiance (like an operating room with about 300W of LED)
• tap up = toggles between TV mode and reading mode (a little brighter over the chairs)

This is done by switch control programs that set a state variable to values between 0 and 20 and nothing else. Constant variables help clarify usage there (see below)

 

I use a bank of programs in a separate folder that only recognise those state variable values and set the whole room to the desired effect.

I use scenes for the Insteon bulbs and call them but there are many more non-Insteon bulbs that take NR, and Nodelink on a RPi, as well as my own NRbridge.py on the same RPi. Scenes are not necessary but make it quicker and more simultaneous than just programs.

 

When you borrow a light for some alarm etc.. you only have to replace the value in the control state variable and everything is forgiven and back to the way it started again.

 

WAF is high due to just tapping the top of the switch to turn lights on and tapping down to get lights off. If you want more light tap up again. Double tap up for even more light. We use that for dull days and the depression is much less on so many grey days we get.  I could mesaure the difference, I am sure. And yet, the same lights are used for movie watching late at night with multi-coloured themic lighting to set the mood.

 

Greazer, the variables are a good start toward the way I would do it again. You have simplified your package a fair bit. Looks good.

I do find the tap down to turn things On counterintuitive though. Make sure you use a wait on that one.

 

BTW: Most of us prefix variables with $s.xxxxx or $i.xxxxx. I only prefix state variables with $sXxxxxxxxx and not integer variables, so I/we don't get caught with the huge difference in function later. I also prefix constant variables (integer) with prefix $cXXXXXXX to keep all these values easy and not confused.

 

 

Larry,

 

I'm going to steal that one from you!

[oberkc]

In addition to my earlier post, make sure these switches are in no scene relationships.

[Teken]

Quite contrary.  I can tell you categorically that triggering a switch via program THEN clause CAN cause another program to trigger (and run).  For example...a program such as:

 

if time is sunset

then turn on light

 

will cause this program to trigger (if light was previously off):

 

if status of light is on

then do something

 

I am like many of the others...my gut reaction is that you have a lot of unneeded complications and I am having trouble mustering the ambition to try to follow the threads.

 

Still, from an intellectual (and potentially practical) excercise, assuming you don't mind lights making several transitions to their end state, I see no reason why your objective cannot be accomplished.  I am ignoring the complications and possible error handling associated with insteon communication errors and treating this purely as an ISY programming excercise. I am also ignoring any timing issues or wait conditions.  (I have never had much need for these, personally, but would address only if needed for a specific application.)  To start, I would summarize your goal:

 

Upon each manually-triggered ON command from switch1, you want it to progress through the following states (switch1/switch2):

 

off/off (I will call this state 0)

on/off (I will call this state 1)

off/on (I will call this state 2)

on/on (I will call this state 3, but no program is needed to track.  State will be assumed condition if states 0,1, and 2 are all false)

back to off/off (back to state 0)

 

Additionally, if switch1 is manually-triggered OFF, you want switch1 and switch2 to turn off, regardless of original state.

 

My initial inclination is to use a version of your state machine to track which state (0, 1, 2, or 3) your two lights are in.  One could use variables here if it helps visualize things easier, but I tend to avoid variables except where I can think of no practical alternative.  Make three programs, one each for states 0, 1, and 2.  No program is needed for state 3, since it can be tracked based upon the other three states being all false.  An exampl program for state 0:

 

if

status switch1 is off

and status switch2 is off

then

nothing

else

nothing

 

I would create three such programs, one for each of the first three states, planning to use program=true/false as a later program condition. One advantage to this method is that this will accurately keep track of status regardless of how arrived (for example, what happens when someone presses switch 2, even if accidentally?)

 

I know that I want to trigger a lighting state change only upon ON commands from switch1.  I also know that I want both lights to go off when switch1 sends an OFF command.  I would deal with this as follows:

 

if

control switch1 is turned ON

and control switch1 is not turned OFF

then

run next program (if path)

else

turn both lights off

 

For the next program(s) I would create a series of programs checking the current state and taking the appropriate reaction.  All of these programs should be disabled, so that they do not self trigger. 

 

Next program (disabled)

if

state0 program is true

then

turn on switch1 (switch2 is already off, by definition)

else

run nextA program (if path)

 

nextA program

if

state1 program is true

then

turn off switch1

turn on switch2

else

run nextB program (if path)

 

nextB program:

if state2 program is true

then

turn on switch1 (switch 2 is already on)

else

turn off switch1 (if I have gotten this far and states 0, 1, and 2 have all been false, then it must have been in state three, thus next step is turn off both lights)

turn off switch2

 

Hopefully, this gives you some ideas to consider and possible things to look for in your own programs to get them to work.  Given your line of questions thus far, it may only be necessary to disable some of your programs to get everything to work.

 

As is often the case, I make no attempt to be efficient at programming or minimizing numbers of programs or lines of code.  With a little extra thought this could be reduced significantly, I suspect.

 

OBerkc,

 

Your like a freaking poet in dumbing things down to the masses . . .

[elvisimprsntr]

And when the ISY locks up, all the programs are useless, which occurs more often than I like. A KPL and scenes are faster and more reliable.