Chris Jahn

For X10, you don't need to configure anything at all, just add it to your program. It sounds as though many of you are having trouble triggering something from X10. I have tested it here, and it works fine, so I trying to figure what could be going wrong. When you send an X10 signal, do you see the LEDs on the ISY flash? I'm wondering if we are receiving the X10 messages, or if they are just not mapped correctly.

Don't worry, we're not going to change the format, I just want to be clear on setting expectations: - This is intended as a machine representation of the program, and not meant to viewed directly. - If this file is modified in any way, and then Imported, we make no guarantees as to the stability of your box. Having said that, this is standard XML and it will remain that way.

The import/export is available in the popup menu on the program tree. Just right-click on the program tree and you will see it. - If you have a program selected, it exports that single program - If you have a folder selected, it exports the folder along with everything in the folder. To export everything, do the export from the root 'My Programs' entry. I can find no way to Export/Import Programs. When I applied the File->Restore Devices a requestor appeared that my RemoteLinc was not found, Thank you! and Request Failed. But contrary to 2.4, Restore Devices is apparently going through all my devices again, rather than only the failed devices. Which means the RemoteLinc linking mode will probably time out before it is restored. In my case, I haven't changed anything, just thought I would make certain all the devices were in sync, so all it is costing me is some time before I can delve into 2.4.9. Thank you and Owl-b-Baac, Rand

What you are saying does make sense, and it looks like the non-toggle fix went a little too far. The logic should be: A program is run if the button changes to the specified value and the 'If' condition is true But it currently is: A Program is run if the button changes and the 'If' condition is true. This will be fixed for the next drop.

Got it, fixed in the next drop.

This is an XML file, but is not intended to be read by anything outside of ISY. In fact, we went back and forth on whether we should export this as a binary file vs a semi-readable XML file. Import/Export is a convenient means of backing up your programs without backing your entire system. It also allows everyone to share programs by exporting/importing them.

Did you try the program I posted where the switch turns the light on, not the program, and the only thing the program does is turn it off: If Control 'Guest Bath Main' is On Then Wait 1 hour Set 'Guest Bath Main' Off I think this should solve the flicker problem with Finally. You could instead check the Status if the 'Guest Bath Main' can be turned on by different controls.

Yes, I would say use 'Finally', because you are guaranteed to have the light turn off if the program turns the light on. BUT It would be better to directly link the light to the switch in a scene. The switch would directly turn the light on, and the program would only have to turn it off after an hour. You could either test the control or the status depending on what you want to do. If Control 'Guest Bath Main' is On Then Wait 1 hour Set 'Guest Bath Main' Off

This has been fixed for tomorrows beta. Basically, it thinks that the programs were updated by a different client, and thus reloads them.

Hi Mark, Can you post that program here.

Actually, if we added 'Else', then it would have to replace 'Finally' because 'Finally' would never run. Your example program would do the 'Then' when temp > 90, as soon as it drops below, it does the 'Else', as it goes above it does the 'Then' etc. Here is the solution using two programs, one turning it on, and another turning it off. I think its pretty straightforward. If Status AC is Off And ( Time is 5:00PM Or Time is 4:00PM And Temp > 90 ) Then Set AC on If Time is 9:00PM And Status AC is On Then Set AC off 'Finally' was originally intended as cleanup for time ranges, but of course applies to all types of conditions. eg. If From Sunset To Sunrise Then Set 'Security Light' On Finally Set 'Security Light' Off Anyway, at some point in the future we can revisit 'Else' if there is a demand for it, and it provides something that can't be done with this mechanism. I guess I just feel more comfortable using an ELSE when I want one of two actions to happen. It certainly is not a bug in the beta, because 2 programs can accomplish the same thing, but it might help in making our programs easier to manage. Here is an example of what got me to thinking about it: Let's say you normally turn your A/C's on at 5pm, but on very hot days you want to get them cranked up 1 hour earlier. In simplified form where the program runs everyday at 5pm it might look like this: If Temp > 90 then Turn ON the AC's wait 4 hours else wait 60 minutes Turn ON the AC's wait 3 hours finally Turn OFF AC's Thanks George

The reason for the dropdown at the top is that you can select multiple rows at one time to mass enable/disable etc. your programs. I'll add the popup menu to the list of requirements, but not sure if it will make into this release though.

The divider actually does move, but only if you size the screen quite wide. I'll add this one to the bug list.

Mark, I've added the "right-click" popup menu for the program tree, its in the next beta drop.

What happens now when this program runs? In know for some Insteon devices, if you send them an 'On' command, and then another (possibly different) 'On' command then this second one will be ignored if the first hasn't finished. You might want to try adding a 1 second wait after setting it to 20%, or adding a 'Brighten' between them.

George, Can you give me an example/scenario where you would use 'Else'? In most scenarios I have gone through with 'Else', it turned out to be much cleaner just to have 2 programs.

Yes, this is identical to the non-toggle button problem. It has been fixed and will be in the next beta drop.

You are right, if something other than the vent switch turned the vent on, then it could go off unexpectedly. If only the vent switch controls the vent (not other triggers or anything else), then this would not be a problem because each time you hit the switch it would restart the trigger.

This is a great idea, I'll add it to the requirements list.

This is no longer a problem in the current beta drop (2.4.9) ------------------------------------------------ For 2.4.8 beta drop There is a problem with 'Last Run Time' program references in schedules such that memory is not being properly cleared and may impact the stability of your box. For this reason please do not use 'Last Run Time' in your schedules until the next beta drop. The specific problem occurs when in program A you reference the Last Run Time of program B, then you delete program B. Sorry for the inconvenience.

Steve, Mark, Thanks for the detailed responses; they should help me isolate the problem.

We are planning the next beta drop for this Friday (09/28).

You are correct, it will still try to turn the vent off in 60 minutes. It probably wouldn't hurt anything to have it try to turn the vent off if its already off, but using STATUS would prevent that. It may actually be simpler to use STATUS, just having one program for the light and one for the vent. You wouldn't need any program for the control. Something like: If Status 'Vent' is On Then Wait 60 minutes Set 'Vent' off

Have a look at the Office Hours hold example (http://forum.universal-devices.com/viewtopic.php?t=272). Instead of using a schedule, use a button as the condition. To allow triggers to run during Vacation, test: If Program 'Vacation' is True To prevent them from running during Vacation, test: If Program 'Vacation' is False Program 'Vacation' If Control 'Vacation Button' is On Then - No Actions - (To add one, press 'Action') Finally - No Actions - (To add one, press 'Action')

There are two ways to put a hold on programs, either by directly referencing another program, or putting a condition on a folder. This example shows two different ways to both shut off the Main Lobby light, and prevent it from being turned on outside of office hours. If multiple switches control 'Main Lobby Lights' and you want to ensure the lights are off outside of office hours, the following program is also needed: If Program 'Office Hours' is False And Status 'Main Lobby Lights' is On Then Set 'Main Lobby Lights' Off Option 1) Reference another program directly 1. Create a program called 'Office Hours' as follows: If On Mon, Tue, Wed, Thu, Fri From 9:00:00AM To 5:30:00PM (same day) Or On Sat From 10:00:00AM To 2:00:00PM (same day) Then - No Actions - (To add one, press 'Action') Finally - No Actions - (To add one, press 'Action') 2. Create a program called 'Lobby' as follows: If Program 'Office Hours' is True And Control 'Main Lobby' is On Then Set 'Main Lobby Lights' On Finally Set 'Main Lobby Lights' Off Option 2) Add a condition to a Folder 1. Create a folder called 'Office' 2. Create a program called 'Lobby' inside folder 'Office' 3. Add the following Conditions to folder 'Office' If On Mon, Tue, Wed, Thu, Fri From 9:00:00AM To 5:30:00PM (same day) Or On Sat From 10:00:00AM To 2:00:00PM (same day) Then Allow the programs in this folder to run. 4. Add the following to program 'Lobby' If Control 'Main Lobby' is On Then Set 'Main Lobby Lights' On Finally Set 'Main Lobby Lights' Off This case is identical to the first, except the 'Hold' part of the program has been moved to the Folder. Any other programs that you add to this folder will also be held in the same way.