Algorithm

I guess I did not rescan the top of the page after logging in. The search feature isn't present until you log in. That's true! So don't feel too bad George . But that reminded me of something I thought of a while back, that I didn't post at the time because I though the UDI guys might (as someone suggested) create some new forums, such as one for comments about the site. In there I was going to post that all of the links across the top (FAQ, Search, Memberlist, etc.) only link from the actual text. It would be good if they also linked from the associated icon above the text. Just a tiny point, and not worthy of the current forum, but the kind of thing one might find in a 'Comments About Site' forum.

Upstate, I agree that trying with ISY off for a period of time is a good next step. But also, Indy's suggestions were very good ones. And yes, it does still sound like your switches are linked, either via Insteon or X-10. While I doubt that Insteon switches respond to X-10 'All Units On', they should certainly respond to 'All Lights On' as well as 'All Units Off' for the particular housecode. Also, I agree with you that only being able to read the switch's memory can guarantee 100% that there is no code there. But, one thing you could do is pick some codes that will never be used in your house, such as housecode P units 1 - 10 (or however many switches you have which misbehave), install a different one of those X-10 codes in each switch, and test it. If it tests okay, then you know you have overwritten any other X-10 code that might have been there, and you know that all switches have a different X-10 code so there should be no X-10 linking. After 24 hours (adjust to suit) you can go back and clear those codes or even do another factory reset. Yes, it is a huge amount of work, but if all else fails, give it a thought.

Hi Kevin, Both good ideas. This points out that one can also use a combination of hard-linked scenes (for instant response even if the central controller is out of service) plus programs based on the same button presses which add something extra to the scene using the central controller.

Hi Jeff! Good tutorial write-up; well done. Here's an idea: You could place the All On and All Off buttons in the scene as controllers, setting the All Off button to non-toggle off mode and the All On button to normal toggle mode. Then, place the same buttons as responders in a status scene, and use a simple program to ensure that the buttons' LEDs get turned back off (after a short delay) any time they get turned on: If Status 'DeckKP-All On' is On or Status 'MBRKP-All On' is On Then Wait 2 seconds Set Scene 'Rear Lights Status LEDs' Off Else - No Actions - (To add one, press 'Action') When the All On button is pressed, being in toggle mode, it will send an On command, turning the scene on (and incidentally also turning on the All Off button's LED), and then the status program will turn the LEDs back off. The non-toggle off mode All Off button will, of course, turn the scene off. While the LEDs will be out of sync for a couple of seconds (perhaps comparable to your present system where 'the button flashes a couple times'), the scene itself will respond immediately to the On and Off button presses. If for any reason the central controller (ISY) should be out of service, you will still have control of the 'All' scene, but in a slightly different manner since there will be no status updates. The button labeled 'All On' will effectively become an 'All' scene On/Off toggle, while the button labeled 'All Off' will follow the scene state but will serve no useful function, being in non-toggle mode. Still, this is a much better scenario than loosing the 'All' scene control if the central controller goes out of service when the entire setup is based on programs.

Yes, that's it, thanks. For anyone interested in the point about the order of execution, it begins in the very last post of the first page of that thread, and continues onto the second page. And while I was re-reading it, Chris had already posted the answer here! Thanks for those great tips, Chris!

Isn't that the quickest response in this case? Since you are continuously monitoring the statuses of the devices in the scene changing any one should change the status no matter what the status of any other device in the scene. If no device changes status the program never runs. If the program runs it means a status must have changed. Yes, that is correct. Any time any light (in the monitored group) is turned on or off, the status of that device will change, which of course changes the status of the If condition as a whole, causing the condition to be re-evaluated and the program to be run. That is the point. If your group has 20 lights around the house, and as people move about turning lights on and off, the LED group ON command would get sent every time any light was changed, even though chances are that after the first time, the LED will remain on until the All Off is actuated. So these constant LED commands are unnecessary power-line traffic. There is a discussion about that somewhere. I made the suggestion that the status light Status be checked following a Control command before the Statuses of any more devices were checked. If the status lights were already on/off when an On/Off was received that no other status checks would be necessary. I do remember that! I hope you can find that thread and place a link to it here, because I think it is a very good question that begs an answer. If I recall correctly, your point was that if, in the If condition, the test for the button(s) status was placed before the test for the load(s) status, it would save some processing because there are likely to be many more load tests than button tests. The question was whether or not ISY abandons the test as soon as the result is known, or whether it processes the entire condition regardless. I hope Chris or Michel can provide the answer. 'Tis the season! I'm truly sorry to hear that Rand, and Mark also! Wishing both you and yours a speedy recovery.

Thanks, Mike! Please let us know how it works out for you.

Thanks, Mark! Please let us know how it works out for you. From the Latin fubar, meaning Fowled Up Beyond All Recognition.

Thanks, Rand! Does not the ISY follow the group command with clean-ups for each group member? If it does not, or if it does and we count the group+cleanups as one command, then yes. But, it will send that command every time any of the group members is turned on or off, even if the LEDs are already reporting the correct status. So the purpose of the extra status check is to reduce that unneeded power-line activity. However, if the user doesn't mind the additional activity, the status programs could be reduced to a single program using both THEN and ELSE clauses.

Like Rand, the first thing I thought of when reading your original post, was X-10. But it's strange that it's affecting the whole scene, and none of the others, though it could be X-10 scene addresses within the switches. I'm not at all sure that SmartHome Insteon devices respond to X-10 'All Units On' commands, so that test might not be conclusive. When you get to the factory reset stage, as Rand said, it will clear out all X-10 addresses, which should definitely eliminate that!

Most Insteon users with a network of sufficient size to warrant the use of an ISY, will likely have one or more requirements for an 'All Off' button. It could be, for example, to turn off all basement lights after going up the stairs, all theatre lights when leaving the room, or all house lights when going out the door. In addition, the typical user would like that same button's LED to display the status of the particular 'All Off' scene, with the LED being on when any of the associated lights are on, and off only when all the associated lights are off. He may even wish to have more than one button, on different keypads, for the same function, such as Basement Off both at the top of the stairs and in the kitchen, or Whole House Off at both front and rear exits, as well as in the master bedroom. The traditional approach has been to use the button(s) as an ISY trigger for a scene which turns all the related loads off. Additional ISY programs monitor the status of the related loads, and keep the button LED(s) in sync. [Thanks to Mark Sanctuary (ref. All Lights Scene Programs - cool tips and tricks), Yardman 49 (Frank) and MikeB (ref. Monitoring room status), and MikeB and IndyMike (ref. keypad button to indicate status of and control entire floor). This approach may look something like: Scene 'Basement All Off' This Load That Load Another Load . . . Scene 'Basement All Off LED Status' This Button That Button . . . Program 'Basement All Off Trigger' If Control 'This Button' is switched Off Or Control 'That Button' is switched Off Or Control '. . .' is switched Off Then Set Scene 'Basement All Off' Off Else - No Actions - (To add one, press 'Action') Program 'Basement All Off False LED Status' If Status 'This Load' is not Off Or Status 'That Load' is not Off Or Status 'Another Load' is not Off Or Status '. . .' is not Off And ( Status 'This Button' is Off Or Status 'That Button' is Off Or Status '. . .' is Off ) Then Wait 1 second Set Scene 'Basement All Off LED Status' On Else - No Actions - (To add one, press 'Action') Program 'Basement All Off True LED Status' If Status 'This Load' is Off And Status 'That Load' is Off And Status 'Another Load' is Off And Status '. . .' is Off And ( Status 'This Button' is On Or Status 'That Button' is On Or Status '. . .' is On ) Then Wait 1 second Set Scene 'Basement All Off LED Status' Off Else - No Actions - (To add one, press 'Action') The 'All Off' scene must contain, as responders, all of the loads which are to be turned off. For a 'Whole House Off' scene, this number can be quite large [in my case, from 49 to 54 loads]. The 'All Off LED Status' scene must contain, as responders, all of the KeypadLinc buttons which are to control/report the 'All Off' scene. The 'All Off Trigger' program watches for any of the associated buttons being turned off, and then turns the respective scene off. If the button should be pressed while it is already in the Off state (thus turning the LED on), the scene will not be affected, and the status programs will turn the button's LED back off within a second or two. The status programs basically say, 'If any load is not off, and any keypad button LED is off, then turn the keypad button LEDs on,' and 'If all loads are off, and any keypad button LED is on, then turn the keypad button LEDs off.' The reason for testing the state of the button LEDs before changing them, is to reduce power-line traffic by not sending the LED on or off command every time a load is changed, when the LEDs are already displaying the correct status (cf. IndyMike). While this approach works well, it does have some drawbacks, the most important of which are related to the use of a trigger as opposed to hard links. First, it introduces a delay between the button press and the scene activation (lights off). Perhaps as important, if the central controller (ISY) is for any reason out of service, then the 'All Off' buttons are non-operational. An earlier approach did use hard links, by placing the button(s) in non-toggle off mode to avoid having all of the loads turn on (cf. MikeB). The obvious disadvantage of that approach is that the button LED does not indicate the 'All Off' scene status. A less obvious disadvantage is that should the button LED in some manner get errantly turned on, the button (being in non-toggle mode) would from that point send an On rather than an Off command when pressed, thus turning all the loads on. A NEW TWIST Here is another idea, which I have adopted, that attempts to address the previous shortcomings. This approach uses hard links, eliminating the added button-press to lights-out delay, and also keeping the buttons operational in the event of the central controller being out of service. The twist is that the buttons are not placed in non-toggle mode, but rather left in toggle mode, meaning that they can still display the scene status. This is accomplished by placing all of the buttons in the 'All Off' scene as controllers, and all of the loads in the 'All Off' scene as responders in the usual manner, and then setting each loads' On-Level to zero. The result is that should the button be pressed while it is off, thus sending an On command, the entire scene is turned on to level zero, which is another way of saying that it is turned off! This is also accurately reflected as a status of Off in ISY. So no matter what the current state, pressing the button always turns the scene Off. I have tested this with both in-wall dimmers and relays, and plug-in dimmers and relays (all Icons), along with the KPL, and it works perfectly. The approach looks like this: Scene 'Basement All Off' This Load That Load Another Load . . . This Button - controller That Button - controller . . . - controller Scene 'Basement All Off LED Status' This Button - responder That Button - responder . . . - responder Program 'Basement All Off Status' If Status 'This Load' is Off And Status 'That Load' is Off And Status 'Another Load' is Off And Status '. . .' is Off Then - No Actions - (To add one, press 'Action') Else - No Actions - (To add one, press 'Action') Program 'Basement All Off Status False' If Program 'Basement All Off Status' is False And ( Status 'This Button' is Off Or Status 'That Button' is Off Or Status '. . .' is Off ) Then Wait 1 second Set Scene 'Basement All Off LED Status' On Else - No Actions - (To add one, press 'Action') Program 'Basement All Off Status True' If Program 'Basement All Off Status' is True And ( Status 'This Button' is On Or Status 'That Button' is On Or Status '. . .' is On ) Then Wait 1 second Set Scene 'All Off Follow Test' Off Else - No Actions - (To add one, press 'Action') The 'All Off' scene contains, as responders, all of the loads which are to be turned off, as well as all of the associated buttons as controllers. The 'All Off LED Status' scene, as before, contains as responders all of the KeypadLinc buttons which are to control/report the 'All Off' scene. There is no trigger program, but the status programs have increased to three. The first is simply a flag program which indicates the status of the scene, being True when all the loads are Off, and False when any load is On. The other two simply use that status in conjunction with the buttons' status, to set the buttons on or off as appropriate. This results in a modest code space saving within ISY, as the list of loads (which can be quite large) need only be enumerated once, rather than twice. As far as I have been able to tell, the LED response delay is about the same as using two status programs with separate enumerations. One potential disadvantage of this approach as opposed to the trigger approach, is that it requires more physical links within the devices. Provided that the user's devices have the required space, this disadvantage is far outweighed by the advantages mentioned above.

When you send a direct On (as opposed to using a scene), the responder will use it's last ramp rate, which may be the local ramp rate. Is there any possibility that your devices have somehow been given a very long local ramp rate, so that when you send On, the device is actually turning on (slowly), even though it doesn't appear to be?

Until the Insteon version is available, how about just using the X-10 one to trigger ISY via X-10 commands? It would make a great interface to setting your alarm times for your ISY programs. Just checked the x10.com site. It sells for $30, and there are about 67 different packages which include it, going up in price. But the cheapest I could find at this time, is HERE. Buy a Socket Rocket (even if you don't need it) for $20, and get a Mini-Timer included! (Of course, you could likely find it cheaper on eBay.)

Excellent, Zellerman. It occurs to me that this idea may also be useful with other types of controls such as X-10 remotes, or Insteon controllers when the next release with FadeUp/Down/Stop is out!

Congrats, Upstate! Which model did you get? 99i/IR PRO Good for you! With that and the 2000-link PLM, there should be little chance of running out of resources!

Congrats, Upstate! Which model did you get?

The part that makes all this work is Michel sees us more then just another sale. Agree 100%!

Excellent! So the 170-byte block line is the one the user is interested in, to keep an eye on memory usage. Thanks!

Thanks for the replies. Without giving much detail about each one, does this report give a good representation of the percentage of memory used within ISY? Ie. can it be used by the user to judge memory usage? For example, in the report above, it looks like roughly 50% is used.

Michel or Chris, could you provide some information on the reading and interpretation of the results of the SM command in the ISY Shell? My current output is: http:///>SM Only displaying memory locations with at least on block used Cur Cur High Prev Diff Size Tot Free Used Used Used Used 24: 5328 3452 1876 1884 ( 1362) +514 32: 756 497 259 272 ( 259) 38: 65 51 14 14 ( 14) 66: 140 134 6 35 ( 16) -10 136: 300 299 1 189 ( 1) 170: 266 228 38 38 ( 30) +8 202: 4 2 2 2 ( 2) 1024: 26 25 1 9 ( 1) 1112: 13 0 13 13 ( 13) http:///>XS

Thanks for the kind words, guys. Glad it is helpful. Just a note that if someone wanted to implement this scheme completely, the easiest way is to create all of the folders and programs at once, with no devices or macros/scenes assigned--just skeletal programs. After that, it's very easy to go in at any time and add or change devices/macros for specific triggers. Even though there are a large number of programs, they are so short that the whole system does not use an overly large amount of memory! Rod, yes PalmPads would be way cheaper than RemoteLincs even if you were buying them new, never mind if you already have a bunch of them like you and I do . But if you've already got some RemoteLincs, the same scheme could be used. If it were implemented the same way, if would give you six Areas of six Devices each, for a total of 36. That may be enough for many applications, but if not, then by all means put those PalmPads to use. While the scheme as I've implemented it may serve as a guide for others, there are many possible variations. If you or others experiment with some variations, or come up with an entirely new scheme, I hope you'll post them. A scheme for a ControLinc (only five button pairs) would be of great interest, for example!

In Part I we looked at the device portion of the system, and the eight programs and nine folders which comprise it, and live in the master-controller's Housecode folder which in these examples is Housecode A. Here in Part II, we'll look at the scene portion, which is comprised of two programs and three folders that also live in the Housecode A folder. One could also choose to create HCA Device and HCA Scene folders under Housecode A to house these two components for organizational purposes; the operations would remain unchanged. The two programs, titled HCA Shift Down Flag and HCA Shift Up Flag, are simply: Program 'HCA Shift Down Flag' If Program 'HCA Shift Up Flag' is False And X10 'A9/Dim (15)' is Received Then Wait 8 seconds Run program 'HCA Shift Down Flag' (Else Path) Else - No Actions - (To add one, press 'Action') Program 'HCA Shift Up Flag' If Program 'HCA Shift Down Flag' is False And X10 'A9/Bright (7)' is Received Then Wait 8 seconds Run program 'HCA Shift Up Flag' (Else Path) Else - No Actions - (To add one, press 'Action') Pressing the Bright button (interpreted as 'Shift Up') will shift the next Scene button (9 - 16) to the upper palette, while pressing Dim ('Shift Down') will shift the next Scene button to the lower palette. Again, an eight second timeout prevents the program from remaining 'locked in' to either shift state, should the second button press never arrive. An added condition prevents the program from switching to the upper palette while it is currently in the lower palette, and vice versa. This is in preparation for future additions to the logic, but may be omitted if one doesn't mind the switch occurring. The three folders are named HCA No Shift, HCA Shift Down, and HCA Shift Up. Their conditions are: Folder Conditions for 'HCA No Shift' Add conditions to limit when programs in this folder are allowed to run. If Program 'HCA Shift Up Flag' is False And Program 'HCA Shift Down Flag' is False Then Allow the programs in this folder to run. Folder Conditions for 'HCA Shift Down' Add conditions to limit when programs in this folder are allowed to run. If Program 'HCA Shift Down Flag' is True Then Allow the programs in this folder to run. Folder Conditions for 'HCA Shift Up' Add conditions to limit when programs in this folder are allowed to run. If Program 'HCA Shift Up Flag' is True Then Allow the programs in this folder to run. Each of the three folders contains sixteen programs, which in the HCA No Shift folder are named HCA No Shift n On and HCA No Shift n Off, where n represents the Scene number (9 - 16). The programs in the other two folders are similarly named HCA Shift Down n On (or Off) and HCA Shift Up n On (or Off). These programs look like: Program 'HCA No Shift 9 Off' If X10 'A9/Off (11)' is Received Then Run program 'Macro Name' Else - No Actions - (To add one, press 'Action') with the corresponding House/Unit codes and Macro names. The sixteen programs in the HCA Shift Up folder and the sixteen programs in the HCA Shift Down folder each contain the same condition as the corresponding program in the HCA No Shift folder, but each runs a different Macro. Now we come to the Macro folder, which is a top-level folder along side the X-10 Triggers folder. This folder contains all of the Macros (read Scenes) which are triggered by the Scene portion of the X-10 Triggers system. The intent is to isolate the trigger (cause) from its action (effect). This allows the same Macro to have multiple (X-10, Insteon) triggers, while only being coded a single time. If the Macro requires modification, it need be changed in only one place rather each place one of its triggers occurs. The reason I refer to these as Macros rather than Scenes is because Scene is a rather static term, which implies a single condition (may include ramp rates, of course), whereas many of my Macros are an entire sequence of events occurring over time, and changing depending on various conditions. For example, what happens when I press my Movie button depends on the current movie state. If this is the first press of the button, then the system goes to a Movie Prep stage: turn on a kitchen light (make popcorn), turn on the theatre lights and a portion of the entertainment system (choose movie). Another press of the Movie button shifts the system to the Movie Start state: kitchen lights off, theatre lights fade down. In this state another Movie button press causes a shift to the Movie Stop state: theatre lights fade up, bathroom light on (refreshing pause), kitchen light on (fetch more beer). Finally, additional Movie button presses cause the state to alternate between Movie Start and Movie Stop. The final Movie Stop state is also appropriate to getting ready for bed, though I also have a Bedtime macro which does that and adds the bedroom lights as well. So there you have it. Phew! A lot of typing, but worthwhile if it is actually of help to someone.

Finishing up Part I, let me start by first apologizing, for in the above explanation I forgot one very important element due to time constraints. Under the master-controller's Housecode folder Housecode A, in addition to the eight programs and eight folders described above, there is one more folder titled HCA Group Select, whose conditions are: Folder Conditions for 'HCA Group Select' Add conditions to limit when programs in this folder are allowed to run. If Program 'HCA Group 1 Flag' is False And Program 'HCA Group 2 Flag' is False And Program 'HCA Group 3 Flag' is False And Program 'HCA Group 4 Flag' is False And Program 'HCA Group 5 Flag' is False And Program 'HCA Group 6 Flag' is False And Program 'HCA Group 7 Flag' is False And Program 'HCA Group 8 Flag' is False Then Allow the programs in this folder to run. Programs in this folder are allowed to run only when all eight Group Flag programs are False. When this condition is True, a button press will be interpreted as the first (Area) button of a button-pair. This folder contains eight programs named HCA Group n Select where n once again represents the Area (first button) code. Each program is simply: Program 'HCA Group 1 Select' If X10 'A1/On (3)' is Received Or X10 'A1/Off (11)' is Received Then Run program 'HCA Group 1 Flag' Else - No Actions - (To add one, press 'Action') with the corresponding House/Unit codes and Group Flag programs. This shows how the first (Area) button may be either an On or an Off button. When the Area button is pressed, the respective program in this folder runs, and sets the corresponding Group Flag program. When a Group Flag program gets set, it enables the appropriate Group folder, and disables this Group Select folder. In this way, the second (Device) button of the pair will operate a device, rather another area. So it is these eight programs and nine folders (and their contents) which comprise the discrete device control portion of the system. Next, we'll look at the scene portion. Hi Jeff. This scheme in its full-blown form may be overkill for twelve devices with eight buttons. But, something similar (and greatly simplified) would likely work very well! I'm happy if this has been of help. Let us know how it goes.

Jeff and Jim, okay, here goes! This is likely to be a bit lengthy; I'll do my best to make it clear . Under My Programs I have (among others) two folders titled Macros and X-10 Triggers. We'll come back to Macros in a bit. Under X-10 Triggers there is one folder for each Housecode that has X-10 controllers set up. These folders are titled Housecode A for example (I'll use Housecode 'A' in the examples). Most of these are simple controllers which need no explanation. Only one Housecode has the complex programming, and all my master controllers are set to this Housecode. Under this master-controller folder Housecode A, there are eight programs and eight folders. The programs are titled HCA Group n Flag, where n is a single digit (1 through 8 ) which represents the eight Areas (Rooms). The HCA portion stands for Housecode A, and would be modified appropriately in each additional Housecode folder used, in order that all program names be unique. Each of these eight programs is extremely simple, and looks like this: Program 'HCA Group 1 Flag' If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Wait 8 seconds Run program 'HCA Group 1 Flag' (Else Path) Else - No Actions - (To add one, press 'Action') When run, this 'Flag' program will remain True for 8 seconds, and then become False. When True, the corresponding group will be active. These Flag programs get set when the corresponding Area (Room) button (the first button of the pair) is received. They have an eight second (adjust to suit) timeout, after which they expire. If no Device button (the second button or the pair) is pressed, this timeout prevents the program from being 'locked in' to that Area forever. If it stayed locked in, and an hour later you pressed another button thinking you were pressing an Area button while the program interpreted it as a Device button, confusion would result. This timeout also means that you must press the second button of the pair within eight seconds of the first. If you press Area 1 when you meant to press Area 2, just wait eight seconds for it to time out, then proceed normally. Eight seconds works well for me. The eight folders are titled HCA Group n, where again n represents the Area. Each folder has a single condition: Folder Conditions for 'HCA Group 1' Add conditions to limit when programs in this folder are allowed to run. If Program 'HCA Group 1 Flag' is True Then Allow the programs in this folder to run. When an Area button is pressed, the corresponding folder is enabled for eight seconds. Each of these Area folders contains sixteen programs--an On program and an Off program for each of the eight Devices within that Area. The On and Off programs cannot be combined into a single program in the usual way because we are dealing with button-pairs as opposed to single button presses. The programs are named HCA m-n Off (or On), where m represents the Area and n represents the Device. The programs may contain anything you want. Since this section of the code is for direct, discrete device control, my programs are very simple: Program 'HCA 1-1 Off' If X10 'A1/Off (11)' is Received Then Set 'Insteon Device Name' Off Run program 'HCA Group 1 Flag' (Else Path) Else - No Actions - (To add one, press 'Action') They simply turn the corresponding device on or off, and then run the Else Path of the corresponding Flag program to terminate it, so that the next button press will begin a new pair. This step is very important. That takes care of the Device component of the code. Next we'll look at the Scene portion. Right now, I have a dinner engagement, so if you'll excuse me, I'll see you later. Be sure to tune in again tomorrow. Same time, same forum !

Zellerman, that's cool ! I haven't tested it, but it looks like it should work. Maybe Chris or Michel could confirm?