Algorithm

Rod, I am doing this using ISY with X-10 PalmPad controllers (and Maxi-/Mini-Controllers). It works great. I haven't actually done it with a ControLinc/RemoteLinc, but believe it should work. I think the (decoding) programming would be identical regardless of the device. I did think about trying to use a ControLinc that way, but decided that with only five button-pairs, it just didn't offer enough control. That's because I didn't want to ever press more than two buttons. The two-button-press maximum was not just laziness, but a requirement in order to not overtax the memory [meaning the little grey cells, not the ISY's memory !]. With an eight button-pair PalmPad with the slide switch in the 1-8 position, I can can discretely control every device in the house (up to 64) with only two button presses. With the slide switch in the 9-16 position I have control of 48 scenes with only one or two button presses. The way I set up the device control is that the first button press (1-8 ) determines the area (usually a room), and the second button press determines the device within that area. The first button press can be either the On or the Off button, the programming equates them. The second button press, of course, determines On or Off for the specified device. Having to remember 64 device codes may seem daunting at first, but I've found it to be relatively easy. I first chose the area codes beginning at the front entrance and basically using a clockwise rotation through the house, eg. Living Room, Dining Room/Kitchen, Master Bedroom, etc. Then within each area, I started at the (primary) entrance to the area, and numbered the devices in clockwise rotation. So the button sequence 2-2 would be area two (Dining Room/Kitchen) device two (Counter Light). After a little bit of use, most codes are easily remembered. In particular, the area codes (first button press) become automatic. If you forget the number of a device within a room (for those infrequently used devices), it is very easily remembered by simply counting devices clockwise from the entrance. For the scene controls (slide switch in 9-16 position), I chose to have the sixteen buttons (9-16, On and Off) represent sixteen scenes. If the Bright button is first pushed, this shifts the palette to an additional set of sixteen scenes; if the Dim button is first pushed, one more sixteen-scene palette is chosen. I placed the most common/frequently-used scenes on the 'Normal' palette, requiring only a single button press (no Bright or Dim). Then I placed related scenes on the same button using the Bright palette for 'More' of a given scene and the Dim palette for 'Less' of a given scene. One could also use the Bright as 'Up' for second floor scenes, and Dim as 'Down' for basement scenes. Or any other variation that makes it easy for the user to remember. I haven't yet used anywhere near 48 scenes, though. This same scheme could be used with a ControLinc, but it would yield only five areas, with five devices each. With the X-10 controllers, I've used seven areas (one still available), with eight devices in each, so for me the ControLinc just doesn't provide enough control in this approach. But with the X-10 controllers this system works very well for me. Of course, I have a host of other controllers set up in very simple mode for my wife's use, as she has no interest in remembering button combinations . Hope this provides some food for thought. Please let us know how you do set up your controls. I'm always interested in a better way of doing things.

Hi Rod, Sorry, but I don't see anything in the programs you posted relating to the original question of 11:45PM? Perhaps you meant to post a different program? However, I don't think the folder/programs you did post will work as you expect because: 1. The programs within the folder will run only at 6:50AM because of the folder condition (perhaps that is what you want?), 2. If Program A were to run, it would make the folder condition False, so no further programs within the folder would run, and 3. None of the programs shown will run on their own, because none of them have any conditions. The last point (3) is perhaps the toughest one to grasp--I originally struggled with this as well. Conditions on a folder only determine when programs within a folder are allowed to run, but do not in any way initiate the running of any programs. For any program to run (other than being explicitly called by another program), it must have conditions. And, those conditions will be evaluated only when one of them changes, not when the enclosing folder's conditions changes. Hope this helps.

Yes, you are correct. The If is (re-)evaluated each time one of the conditions changes. There is some discussion in this thread about adding some programming capabilities in a future version of the firmware. Yep, I've seen ya, fellow Canuck ! Aw, shucks! So it didn't originate in going IBM one better with the original PC keyboard (which had only F1 - F10 keys).

Hi Rod [f11--cool handle ], welcome to the forum! The problem isn't the Wait, but rather that your MBRM device is part of the If condition, and is also changed within your program. When it is changed, the If becomes False, and the program immediately stops. To achieve your goal, you can use two programs, similar to: Program 'Part I' If On Mon, Tue, Wed, Thu Time is 6:50:00AM And Status 'MBRM - 00.65.BE.1' is Off Then Run program 'Part II' Else - No Actions - (To add one, press 'Action') Program 'Part II' If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Set 'MBRM - 00.65.BE.1' On Wait 5 minutes Set 'Fireplace - 00.47.B5.1' On Wait 5 minutes Set 'Stairs - 00.65.8F.1' On Else - No Actions - (To add one, press 'Action') Hope this helps!

Indy, that's a great write-up of the classic difference between 'IS' and 'BECOMES' conditions. In ISY terms, the examples you provided show Status acting as an IS condition (TRUE as long as the condition is true), and Control acting as a BECOMES condition (TRUE only once). I would love for the UDI guys to provide a little more insight into how ISY handles these situations.

Great example, Indy. I really like your idea of dimming the light shortly before it is turned off, to warn of the impending off! In your conditions, you test twice for the devices being switched on (and for the lockout), because of different times during the week versus the weekend: Could the device (and lockout) tests be done only a single time by combining the two time checks with an 'Or'? If ( On Sun, Mon, Tue, Wed, Thu From 11:00:00PM To 3:35:00AM (next day) Or On Sat, Fri From 12:00:00PM To 5:00:00AM (next day) ) And ( Control 'Bar Lamp KPL2-Primary' is switched On Or Control 'Bar Lamp' is switched On Or Control 'Bar Cans' is switched On Or Control 'Bar Cans KPL2-C' is switched On Or Control 'Fam Lamps KPL1-C' is switched On . . . ) And Status '1st Fl Timer Lockout 08.4C.8' is Off I haven't tested this, but if it works it would help shorten the code.

No, you're not missing something-you're right! A thousand pardons! Any logic can, as Jeff suggested, be reversed. But when you add in the traffic/program requirements, I believe that to accomplish your same end result would in this case require two programs--which rather negates the benefit of reversing the logic for easier reading. Thanks so much for taking the time to write out the examples. That may be of help to other readers as well!

But that test could also be included in the revamped code, as I mentioned. If that were done, the program would be 'evaluated' when conditions changed, but not 'run', just as your original code.

Perhaps my understanding is failing me. I believe your statement is true, but does not the ISY also process your original program any time a light contained in the scene is adjusted?

How about taking Jeff's code, and simply removing the lines from the Then, so that the Then is empty? So when the If becomes Not True, the Else is triggered. And if you like you could add the 'KitchenControls1G is not Off' clause. That way, you've completely inverted the logic of your original code, so that the end result is the same.

Thanks for the clarification, Chris!

Thank you, Chris! So with the nesting example I'm trying to achieve, I don't want to have a folder with conditions, but extra conditions on each related program (and perhaps all the related programs in a folder for organization)? So it might look something like this: Program: Condition1 If Condition 1 is True Then Condition 1 Actions Run Program 'Condition1' (Else Path) Else - No Actions - (To add one, press 'Action') Program: Condition2 If Program 'Condition1' is True And Condition 2 is True Then Condition 2 Actions Else - No Actions - (To add one, press 'Action') Program: Condition3 If Program 'Condition1' is True And Condition 3 is True Then Condition 3 Actions Else - No Actions - (To add one, press 'Action') and so forth for as many conditions as required? And after program Condition1 is complete, it runs its own Else path to make itself false until the next trigger. I tried one group like this, and it seemed to operate as desired. So, if this is the correct method, then I'll get busy with doing more of them.

You're more than welcome, and welcome back Chris. You guys deserved a holiday--hope it was a good one! Sorry I hadn't given extended commands much though, but I like your idea, especially this part, "I guess they could even be scoped to specific addresses you don't see a huge list everytime for everything." Unfortunately, since most X-10 devices are not two-way, ISY can not automatically determine a device's capabilities. It therefore falls to the user to provide the requisite information. Perhaps each X-10 device defined by the user could have a Properties page (reached from the context menu and/or by a Properties button) which, besides Controller/Responder, would have a checkbox for each extended command, for the user to indicate which apply to the device. The names for the checkboxes could be the custom names the user provided in your sub-tab. Perhaps the user could also define custom named (shown in the Type column) classes of devices with preset capabilities. And, the context menu would list only the commands defined for the selected device.

If you can tolerate the delay of X-10 (which may be acceptable on a night table), and if the X-10 signal from there will reach your ISY, the X-10 mini-controllers might be a good option. Four button pairs may well be enough for a bedroom. I really like the Stanley mini-controllers; they have white buttons for On and Off, grey buttons for Bright and Dim, a Black button for All Off and a red button for All Lights On. The red button is lit, making it easy to find if one's bedroom is very dark, so it can be used to trigger a bathroom light or a good-morning scene, etc. Now as to light levels after dark, I really like to have bedroom lamps and ensuite lights come on to lower levels, just as you requested. But I like to have them ramp up slowly, which is much easier on the eyes when it is dark. I use incandescent bulbs in the ensuite bath for this low-level fade-up effect. But I really like Rand's suggestion of having a bit of a ramp rate for the bright level. I use fluorescent lights in the main bath to save energy, and since they take a short amount of time to reach full brightness anyway, I might not notice a great deal of difference between those, and setting a short ramp rate for the bright level in the ensuite bath. If the ISY can react quickly enough to halt the ramp at your desired level after dark, that might be a great solution. If you do try this, let us know how it works.

To put it another way, folder conditions do not initiate any activity within the folder, they simply deny/allow such activity when some external event occurs. So in my example where the conditions for all of the programs within folder are based on other 'flag' programs, rather than on external events such as Status, Control or X-10, how can one of the programs be made to run when the folder conditions become true? It seems (from what I've observed) that such 'flag' conditions of programs within the folder are not continuously evaluated the same way other conditions are. This could be accomplished with the 'Run If...' capability should it become available, but is there any way to do it right now?

Not much response... No, though perhaps this particular question has become redundant with the introduction of your unified scene theory . With that in place, the user can have both indications even if ISY maintains only a single scene state. Now the question is, how much of this theory will be implemented, and when is it coming... ?

Thanks to Dave for digging out the link to the other thread and to Mark for quoting the relevant post. Michel, this feature would be very useful in conjunction with nested conditions/programs/folders. I think it would help with the question I have posted in this thread titled Nested Conditions in the ISY Programming forum--I wish someone could help me with that question.

Forgive me for being dense, but I haven't yet quite got what I need here. Let's say the programs in Folder are all mutually exclusive (but encompass all possible conditions of the set), so that exactly one program should run. [NOTE] So, a trigger runs a certain program, let's call it Program 1. Program 1 takes some actions, then requires one group of additional actions, selected from a number of such groups, to be taken. So we place each group of additional actions in a program, and place the collection of such programs in Folder. Now, how can I have the one program whose conditions are true, automatically run when Folder's conditions become true? What conditions should Folder have to allow Program 1 to run the one program within it whose conditions are true?

Yes, that's certainly understood. However it is implemented, we can be confident that your solution will be top notch, in keeping with the rest of ISY!

Thanks!

This is great; I think you have some understanding of GUI creation etiquette! Thanks for the kind words, Mark. I thought I had really taken a liberty in referring to myself as an 'artist'--it likely took me more time to diddle that one image, than it will take the guys to implement the entire code base! You know, I never thought of the buttons! Yes, I like the context menu too, but if others wanted buttons, then both could be implemented. Yes, colour is important. [Reminder to self: open new topic to discuss user-selectable colour scheme (skin?) when User Interface forum is implemented.] Great idea! Also suggested by Joe. So we could have a context menu in both panes; the one on the left would also include display options.

Thanks for the kind comments, one and all! I really hope Michel and/or Chris will chime in and let us know how much they would like to implement!

I had thought of this, and decided against trying to push for too much at one time . Since most X-10 devices, unlike Insteon devices, are not two-way and therefore don't support status requests, the On percentage would have to be predictive only, i.e. based on X-10 commands seen. If the UDI guys are up to it, I'm all for it! That's a great idea. It should be selectable, as you need to show the undefined ones in order to define them. Another good idea. There is no reason that the context menu couldn't be available in both panes. This is something I really would like as well, though I hadn't considered a specific X-10 only log; I had been thinking of a general log which would be in standard text format, and not require Excel.

Hello All, I though I would provide an 'Artists Concept' of what an X-10 tab might be like. The image below is a thumbnail, click on it for a full-size image. A description follows the image. First, the X-10 tab is more of any 'every day' item (like a program), rather than a 'set it once and forget it' configuration-type item, so I placed the X-10 tab on the top level, between the Program Details tab and the Configuration tab. The tab is divided into two panes; a scrollable configuration list on the left, and a status/update table on the right. Each displays all 256 X-10 codes. I created the image using the same colour scheme as used in the rest of the ISY Administrative Console. There are a number of features depicted, which I will describe below. These are all open for discussion, of course. Colour is very important, and I've coloured the list items (left panel) and the first two columns (only) of the table (right panel) for illustration; the remaining table columns are not coloured. Red represents a Controller (or Controller/Responder) X-10 code and blue represents a Responder only code. A Controller code is a code which one wishes to use in ISY as a trigger (think of it as an incoming code); a Responder code is a code which is used to activate an X-10 device (think of it as an outgoing code). Controller codes may be codes sent to ISY from max-controllers, mini-controllers, palmpads, motion sensors and so forth. Responder codes may control X-10 switches, modules, cameras, etc. Each code may be defined in the configuration list, giving it a name and type. The type determines the display colour; the name may be used in programs in place of the actual code. The status table on the right shows ISY's predicted status of each X-10 code. 'On' is displayed for codes which are on, and a small dash is displayed for each code which is off. This keeps the table from becoming too cluttered, allowing On codes to be quickly identified. A code whose state (On or Off) is unknown, is left blank in the table and in the list [see A1, A2, A3, A4, A9, B6, B8, B13, B15, B16]. Codes which are not defined may still be sent and received, and their status tracked by ISY; such codes are displayed in black in both the table and the list [see B7, B14]. Right-clicking on any code within the table opens a context menu with the items On, Off, Bright and Dim. Left-clicking On or Off immediately sends the appropriate On or Off command for that X-10 house/unit code. Left-clicking Bright or Dim brings up a small dialog (not pictured) which allows setting a repeat count; when the dialog box is accepted, the appropriate X-10 Bright or Dim command will be sent the specified number of times. The dialog box title should show the X-10 code and the action (Bright or Dim). Though not pictured, the table cell which was right-clicked should be highlighted, to indicate which X-10 code the context menu applies to. I hope this will provide a good base on which to discuss and build an X-10 tab. I, for one, am anxiously awaiting the updated X-10 capabilities of the next firmware revision.

I would argue that this is not desireable. It is counterintuitive to have a status light ON to indicate that devices are OFF. Well, I felt that way also when I moved from X-10 switches (light on when load on/light off when load off) to Insteon (Icon) switches (light on when load off/light off when load on). Can't argue with that. I guess what I was trying to say is that the user would have the option, simply by the logic used in his program, of having the LED indicate either way, including being mutually exclusive with the other scene LEDs.