apostolakisl

I wouldn't be so concerned about controlling your garage door over the internet. Using the https connection is going to be more secure than your garage door actually is. A garage door can be opened with a crow bar in like 2 seconds, so anyone who wants in, is going to get in the easy way, not spend days trying to crack your security key.

That is a reasonable statement. And even if SH were to falter, they have a pretty big market established that is too valuable to just get ignored. Someone would buy the patents and keep it going. The only possible exception to that is if some other technology showed up that was just a huge game changer. The fact is that 99.999% of the world is already wired the way it is wired so that really only leaves performance and price as game changing categories. And at current Insteon price/performance levels, there is only so much room for improvement, probably not "game changing" room.

I don't see where this particular program would flood the lines. It is just a single command every 2 seconds. I have several programs that operate exactly the same except I only have a 1 second wait on the loop and I don't have any issues with them running. The only thing close to calling a problem is that the beep is not perfectly at 1 second intervals, presumably the reason is varying number of hops from one PLC to the next.

Unless something has changed since 4.2.8, there is no "repeat end" and using "repeat 1" is the proper way to end a repeat. Though "repeat end" would be more logical and a "repeat 0" would not even be an option.

I suspect it would be quite complex to try and update the firmware via the PLC or wireless mode. As mentioned, a direct plug into the header would easily do it, but that is not really easy since you need special equipment. A usb could be installed on the switches, but that would add cost and (unless you want your swtiches to have a usb jack showing) require that you at least take the faceplate off and wander about your house with a laptop in hand updating one at a time. But, personally, I would be sort of OK with that.

AC motors RPM is based on the AC hz, not voltage. A dimmer will effectively drop the voltage but makes no change to the hz. So the motor keeps spinning at the same speed until the voltage is insufficient to push through the load at which point it will spin unpredictably or stop and possibly over heat and catch fire or burn up the windings. The multi speed AC motors I know of work by having more than one takeoff of the power wires into the windings resulting in different magnetic configurations that change the speed. I am not really sure how fanlincs work, maybe someone else knows. But they seem to somehow tap into the same built-in speeds of the fan without physically changing which wires are connected to what inside the motor. Just recently some of the new ceiling fans have DC rectifiers and DC motors in them and are thus infinitely variable. They are also more efficient. But they cost more. My HVAC unit runs on fans like that. One of them burned out at 5.25 years (warranty 5 years) and the new fan motor was $800 (just the motor) (compared to about $125 for a similar AC one). I bitched and they covered it under warranty. . . but you get the idea. So I have to commend Carrier on covering it, but not on having it fail after 5.25 years.

He said humidifier, not de-humidifier. There are lots of different kinds of humidifiers. Most of the ones I am familiar with don't use much electricity, so load won't be an issue. Without knowing exactly what humidifier you are dealing with it is hard to say. But, in general, no, you can't use a dimmer on an AC motor, which is almost certainly what is running the fan on your humidifier. You could look into the compatibility of the fanlinc, but I am doubtful.

In the few and far between cases that I wanted an "If" clause to always be true, I have done something like that (see my first post). It would appear that leaving it blank is functionally equivalent. I doubt UD would change the fact that blank evals to true when triggered. My speculation is that the "logic" is more of how ISY works rather than logic of the program as written. In other words, my bet is that once a program is triggered, it must result in a true or false outcome because of how the code was designed.

I'll look into this. I maybe wrong. Perhaps a blank "if" defaults to running "then" if you force a run. I just assumed that a blank "if" does nothing since it is neither true nor false. The logic of a blank "if" being true escapes me. EDIT: Indeed a blank if is somehow "true" Don't ask me how that logic works. No less, there still doesn't need to be 2 programs. The repeat every 30 minutes would take care of it If blank Then Repeat every 30 minutes $Climate_Outside_Temperature = $Thermostat_Great_Outdoor_Temp $Climate_Outside_Temperature Init To $Thermostat_Great_Outdoor_Temp Else - No Actions - (To add one, press 'Action')

Nope. Running at startup means it will trigger the "if". So a blank if does nothing. Just do a "repeat every 30 minutes" and include an "if" clause that is for sure true and set it to run at startup. If variable x is >= 1 or variable x is < 1 Then repeat every 30 minutes your stuff.

"not switched off" behaves the same as "switched off", except it is false. For example if control device x is not swithed off Then do x Else do y Is the same exact thing as If control device x is switched off Then do y Else do x Yes, you are correct that if you blink the lights, then the "status" line would screw it up. Using "beep" does not. In my case, that switch does not change status except from that switch or from ISY programs. I included the fade up and fast on commands so that any action on that switch would start the timer over. "status" would fail to reset the switch if someone did a "fast on" or "fade up" when the light was already at 100%. On the way down, the "status" line catches everything. You could easily get rid of the status line and add "fade down". You will also need to add a "not switched off" and "not switched fast off" to drive the else clause, otherwise the timer will still run if someone turns them off. The one problem would be if someone fades to off. The timer would still run and they would blink at the end of that timer. The only way to fix that would be to have 2 programs.

Here is an example of a program I wrote that is quite similar. If Control 'Alexis Room / Alexis BR-Overhead L' is switched On Or Control 'Alexis Room / Alexis BR-Overhead L' is switched Fast On Or Control 'Alexis Room / Alexis BR-Overhead L' is switched Fade Up Or Status 'Alexis Room / Alexis BR-Overhead L' is not Off Then Wait 29 minutes Repeat 60 times Wait 1 second Set 'Alexis Room / Alexis BR-Overhead L' 14 (Beep Duration) Repeat 1 times Set 'Alexis Room / Alexis BR-Overhead L' Off Else - No Actions - (To add one, press 'Action') The program allows the light to stay on 30 minutes since the last time the light switch was touched leaving the light in a "not off" situation. During the last minute, it beeps to warn you that it is going to shut off. If you want to reset the timer, any action on the switch will reset the timer from any condition, to any condition (except off). Personally, I agree that the repeat 1 time or 0 times is confusing. Repeat 0 times should just not be an option, and repeat 1 times should be replaced with "end repeat". It would then be quite obvious what is going on.

No, a scene is one command. When a device is programmed to be part of a scene, that device (along with potentially many others) then responds to that one command. For example, if a switch is set as a controller of a scene with 3 devices, when you turn the switch on, 2 things happen. 1) The switch turns itself on based on its "applied locally" settings (which may or may not be the same as it responds to a scene, this you define when programming the scenes and local settings of that switch) 2) it broadcasts a "scene <scene address> on" command. The other 2 devices "hear" that one command and do whatever you programmed them to do. Turning a scene on does not send multiple independent commands specific to each device.

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.