apostolakisl

Go back to my post where I first created both programs. It includes instructions on how to do that.

Either way on the jumper, it should still be sending a "controlled switched on" when it opens, and program 1 should trigger on that provided the program 2 timer has finished. If the "status" of 'device 1' is "on" (at least as far as ISY is concerned), then it would trigger and run false. I would suggest checking the program summary tab and see if indeed you are getting a false run of program 1 when it fails to perform as expected. This would confirm an issue with the status of 'device 1' being either actually on, or ISY incorrectly believing it to be on. If the load on 'device 1' is "noisy" it may be interfering with comm making ISY think it didn't turn off.

It would not be the program. Once the timeout on program 2 is over and program 1 get re-activated, then it will run on receiving a triggerlinc command. Perhaps you have a communciation issue? Check to see if the status of device 1 is correct on your console. Also, if device 1 is a dimmer, "not on" means "not 100%". (this is probably not your problem, but you should be aware of that as many people assume not one is the same as off).

For the most part, you need to split this into 2 programs. Program 1 If From Sunset To Sunrise (next day) And Control 'Triggerlinc' is switched On And Status 'Island (Mudroom Door ICON)' is Off Then run program 2 else clause Else - No Actions - (To add one, press 'Action') Program 2 If blank (or an optional condition if you want to terminate the wait) Then blank (or enable program 1 if you include a terminating statement in the if) Else Disable program 1 Set Scene 'Island' On Wait 15 minutes Set Scene 'Island' Off Enable program 1 Also, if you wanted to terminate the 15 minute timer, you could include whatever you wanted to cause the termination in the "if" of program 2 and put "enable program 1" in the then clause of program 2. Also please note that whatever you use in program 2 as the terminator condition in the if, should only have a true option (like "control triggerlinc is switched on") otherwise the else clause could run unintentionally.

I don't know much about this, except that as I read other articles it would seem that it is not as simple as being a "linux" problem. It seems to be this "bash" interface which may or may not be a part of any particular linux system and could be part of non linux, unix based systems.

This is not correct in all situations. In your particular example, it is correct, because all the conditions are "status" conditions, which are triggers upon any change in status. For a "wait" to terminate, the program must trigger, and not all conditions are triggers. example if status light is 100% and $integervariablex is 1 Then something wait something else. The above program DOES NOT abort the wait if the variable changes to something other than 1 because integer variables are not triggers. Only if the status of the light changes does the program abort the wait.

Here are 2 ways to set variables to the date. I wrote both sets but feel that the second set is more elegant (the set in the forum, not the wiki). I would read my wiki entry for the first set of programs as it will help you understand both sets. http://forum.universal-devices.com/topic/13750-i-wrote-a-new-date-variable-program/?hl=date http://wiki.universal-devices.com/index.php?title=ISY-99i_Generic_Calendar_Using_Programs_and_Variables Here are programs for setting the time to variables.(last post in this thread) http://forum.universal-devices.com/topic/13295-variable-based-scheduling-of-programs/?hl=%2Bhour+%2Bminute&do=findComment&comment=109505 Having an email sent at power restore is nothing but writing a program that runs at boot that sends you an email. The time the email was sent will be the time power was restored. If you install the above programs and have it send you the value of the variables, for hour, minute, and date, you will see what time/date power went out. The only trick is that if ISY manages to correct the time and date prior to sending the email, But I have some delays built into those programs that should prevent that.

The cheapest way to do it is to put your ISY on a UPS. Install the programs I wrote a few months ago that set variables to the time (hours and minutes). Have a program that queries a reliable device every so often, like once per minute. Then write a couple programs that set start of power outage to two variables (like $i.powerouthour, $i.poweroutminute) when the query first fails. The same program enables a second and disables itself. The second program writes the end of of power outage variables when the query succeeds (like $i.poweronhour, $i.poweronminute) and then that program re-enable the first program and disables itself. Of course if the power goes on and off multiple times you will only get the last one. Alternatively, you put your ISY and internet service on a UPS and have ISY send an email when the query fails and an email when the query first succeeds.

The simple/not simple part of the home automation is not the button(s). It is setting up the button's action. How this makes that easy doesn't seem to be addressed. Plus, one button, one task. Unless you want to get complex and have the button do different things based on current conditions. But now your programming of the button just got that much more complex. This solves nothing except to look like the silly Staples commercials. Now if the button summoned your AI computer to ask you what you wanted and then it could parse out your answer and execute it for you, that would be great. Though Apple and Google are starting to get there with that.

Looks like an SNL skit. If it is real, I feel sorry for them. Gonna lose a lot of money.

You illustrate the point nicely. The red are responses to the question "in scene". Controller 1, controller 2, etc. are device names, not scene names. Human names for devices and scenes are an ISY property, not an Insteon property, and the current "in scene" format doesn't follow the naming and organizing conventions established elsewhere by ISY. Quite possibly the most important aspect of an ISY is to take the Insteon addressing system and put it into an intuitive user interface. Insteon addressing doesn't respect the human naming of scenes, ISY has created that, and in this instance, ISY is blending things. Even if it said "in scene or scene controller device" it would be accurate, though still perhaps non-intuitive. That is why I believe there has got to be a better way to organize this. EDIT: OK, here is an idea on how to do this. First change the name to "adjust device and scene settings" When you click on it, you get the full list of devices and scenes (at least ones that have settable attributes), then when you click on a scene or device, you get a pane that opens just like the main ISY page that allows you to set things using the same exact methods as you do from the main page.

No, not confusing two things, these are two things. 1) In a program, you are given the option to "adjust scene" Your next choice is "in scene" It should follow then that you are presented a list of scenes. However, in the drop down menu you are presented with a list that includes the names of scenes, and individual devices. This makes no sense on the surface and requires a fair amount of research to figure out what the heck it is doing there. A device is not a scene and to "fill in the blank" with the name of a device when presented with the question "in scene" is using incorrect naming language. What it is meaning to say in that situation is "devices controlled by this device". Of course you can't only say that, since the list also includes scenes. I am not entirely sure how to make this naming more correct and intuitive. I have some ideas, but they seem messy to me, but I am sure there is a non-messy way to do it. 2) The second thing I totally agree with you on. Since air-gap is no longer required to adjust local properties, why not include direct access to devices for changing local control properties. Why require the workaround of putting a device in a scene as a controller to adjust its local control properties via a program. I understand that it was happenstance that because scene adjusting allowed local control properties to be adjusted, that ability got in there when adjusting scenes even though the device wouldn't actually change without a power cycle.

So, I have an idea, why don't we solve the problem. 1) "Adjust Scene" is incorrect. When you are presented with a list that includes names of devices and scenes where it says "in scene", that is incorrect nomenclature. A device is not a scene and therefore should never be listed as on option for "in scene". UD should at least re-label the situation as I mentioned in another thread. This is confusing to say the least. 2) UD should also re-do "adjust scene" to include devices on their own. There are historical reasons for not being able to adjust devices programmatically, (the fact that a power cycle used to be require after such a change). But this limitation does not exist with devices made for years. 3) In the mean time, put any devices you want to adjust programmatically into a scene as a controller. If that means a one device scene, then so be it. This here is the point of this particular thread and could have been taken care of many posts ago.

Not sure what you are talking about. I have a scene I call "all" and it contains almost every one of my devices as a responder. There is no reason I could not add the last couple devices if I wanted to (but I don't which is why I have this scene, so i can turn all the lights on during a fire alarm and not also turn on the bathroom fans).

OK, it appears that a device that is not in any scenes doesn't show up at all. I really didn't notice this since damn near every single one of my devices is in a scene that is called "all devices" So my suggestion to you would be to create a scene and call it "all devices" and put them all in there.

I have to say, mine has some odd stuff that I would like explained. Items listed as devices, also bring up all devices that are responders to that device in the "set" drop down. If I change those other devices, and go to the scene menu for the scene it is a controller, then click on that device in the scene to get the "applied local" showing, it shows that the "set" device changed, just under the "applied local" setting for the primary device. The device does not change under its own "applied local" menu. If I select the same device in the "in scene" menu and the "set" menu, then it changes the local on level. . as expected.

You can adjust both the applied locally attributes, or the attributes as it responds to a scene. When using "adjust scene" (this is a bad name) you can adjust not only scenes but applied local. If you want to adjust the local attributes, then pick the device from the first section of the drop down list where it lists all your devices with a little square icon to the left. If you want to adjust the device as it responds to a scene, select the name of the scene (with the circle and 3 dots in it icon), then pick which device you want to adjust.

This would check for the status turning on, but exclude the remote. If control 'remote' is switched on then $i.outlettest = 1 wait 3 seconds $i.outlettest = 0 If status 'outletlinc' is on and $i.outlettest = 0 Then send email EDIT: or this might be better. If control 'remote' is switched on then disable program 2 wait 3 seconds enable program 2 Program 2 If status 'outletlinc' is on Then send email

If your outlet linc did a have a control switched on, using this as the trigger would not trigger the program from 'a stray signal' since the outlet linc would be the responder. control switched on only triggers when the on command was first generated by the device in question.

PLC firmware. The ribbon cable can be directly spliced to a cat5 or some other wire, you can use a screw down blocks, or you can punch it into a female cat5. What I have done is punch the ribbon cable into a female cat5 plug and then use standard cat5 patch cable to connect other stuff. That gets you 8 conductors which will be several more than I would expect you would need. You can cut an extra hole in that enclosure to mount the cat5. Or whatever.

You know, I am not 100% sure if safe mode stops programs that don't involve Insteon comm from executing. I suggest you give it a try, my suspicion is that it will work. Go ahead and write your programs that use a variable to trigger an email. Then unplug your plm. Then use REST commands to set the variable manually via the network. The ISY won't know the difference between a manual REST command and the webcontrol board doing it. As far as webcontrol enclosures, I have seen some sellers on ebay sell them with the custom enclosure. There is an enclosure out there designed for it. EDIT: here is the enclosure. http://www.ebay.com/itm/WebControl-Metal-Chassis-/260319272733?pt=Home_Automation_Kits&hash=item3c9c3cdf1d EDIT again: You will also need the plug and ribbon cable for the input. It is listed in the user manual which you can download. I found them at a local store altex electronics. Not sure who else would have them in stock, maybe Fry's or Radio Shack? doubt Radio Shack, but maybe.

The PLM has nothing to do with network data (such as a webcontrol/raspberrypi/etc input or email/network resource command output) into and out of ISY. Putting a UPS on the PLM is a bad idea since it elliminates all power line data in/out of the PLM forcing at least one hop each way to be rf. Also, it accomplishes very little since pretty much none of your other Insteon devices will work in a power failure (except for battery operated stuff).

Webcontrol board, Raspberry Pi, Beagle Bone, etc. True, they don't come with enclosures, but they all have enclosures available separately. They are all quite reliable in the application you describe and can be inserted anywhere you like on your network, even in an outside network provided you set up port forwarding. Personally, I have lots of experience with webcontrol board which would only require a handful of lines of code to post to ISY. If you put your webctontrol board, router/modem/switch, and ISY on a UPS, all of this will work even in power outage. If it is email/text notification you are looking for, then webcontrol can do that directly without ISY. If you wanted more robust, put a cellular communicator for your internet backup..

I wrote a rule in Elk itself that chirps the outside sirens when armed away. I used to have it flash the lights next to the garage, but found that to be unnecessary. If you do that, and these same lights are supposed to be left on at night or during some certain hours of the day, then the last line of the program needs to call the program "if" clause that sets them in the first place. If elk is armed away Then set garage light to on wait 1 sec set garage light off run program 'evening outdoor lighting' if You can't chirp the sirens from ISY (that is one of the few features not included), so that is why I used an Elk rule.

I would get rid of the wait 1 minute in the first program. It opens the possibility of the program getting terminated during that 1 minute and the second program never running. Also, be aware that the way this is written, if you change the toilet light from any value above 61% to any other value above 61%, it will start the second program over again, or if you drop below 61% and then raise it back up. That may or may not be something you want to happen. If you want the second program to run all the way through, have it disable the first program as the first "then" line and the "enable" it again as the final line.