Illusion

Paintguy, I was in exactly the same situation as you before getting my ISY. I am on a Mac and was using Indigo but did not want my computer on all the time. I do not regret going the ISY route at all, but there are a couple of things to be aware of. 1. The ISY will control X-10 devices and can hear X-10 signals and respond to them, but the user interface is not anywhere near as friendly to X-10 as Indigo. 2. While the ISY is incredibly powerful for such a low power device, it is not in the same league as Indigo when it comes to running AppleScripts, email notifications, email based control, variables, and super simple GUI. 3. Because of the less simple GUI, and the way you write programs in the ISY, it is vastly more powerful than it first appears. While we talk "Code" here, it is not at all like "Knowing Code". The basic framework is locked into If, Then, Else statements that you put values in from various drop down menus. You do not write anything except comments if you like. 4. I am on a Verizon Fios Actiontec router and it works great. If you look into the forum post on this subject you will see detailed step by step instructions on how to set up this exact router. 5. I cannot say enough good stuff about this product and company. Michel, This whole thread gives me an idea: I talk about my ISY and Insteon to people out in the world all the time. It used to go in one ear and out the other. Then I set up internet access and because people could see my devices on my iPhone, they became very interested. Then the other day I logged into my Admin Console to show someone how to program it, and I had 4 people really fascinated by the interface and all the possibilities it opened up. I know you guys are not the most marketing focused group, preferring to spend your efforts on continuous product improvements, but there may be a real opportunity here. How about a website or simulated Java Applet that lets someone interface with a fake sample system? We take for granted knowing how the interface functions, but even the most rudimentary simulation would answer dozen of potential customer questions and put them at ease. You could include this "Demo" on Smarthome or any other distributor. It could be a great sales tool.

Michael, I have tried messing around with this function quite a bit over the months since first reading this thread and have never been able to achieve the desired results from within the ISY. I always end up going the manual route. Are your sure this is possible via the ISY? And while we are on that subject. The dialog box that opens when trying to switch to non-toggle mode has launguage that is a bit confusing as it states: Choose Toggle Mode: Off for Toggle-Off On for Toggle-On When what I think it means is Choose Non-Toggle Mode, Off for Non-Toggle-Off, On for Non-Toggle-On. Or am I misunderstanding things here and that is why I can never get this Off button on a 6 button KPL to turn Off except with the manual method mentioned here?

If you can live with longer timeouts that also will save power. I would also recommend writing programs in the ISY to handle the "off" function if you already have not done so. If you have the MD set to send the off command, just changing that via the jumper will lead to increased battery life. Changing to Day only mode will further help your cause. I do wish there was a way to prevent the dusk/dawn wasted transmissions aside from opening the device up and modifying it.

Is the culprit in a high traffic area during the day? What is the timeout on the offender?

Does anyone have experience with a comparison of battery life in the detector if it is set to detect motion always instead of at dark? Most all of my motion activated programs are night only (I do not use direct links between the detectors and any other device), but I have thought of some cool programs that could run only when the 'Away' condition is set. Like having a radio or TV turn on if any of the detectors outside detect motion, even during the day. I had thought that the less I allow the detector to xmit, the less juice used. But I have noticed that the detectors detect motion always no matter what, they just do not xmit this if the night only mode is set and it is bright out. So if the detector is coming out of sleep no matter what, how much more power does it really take to xmit this. This feature is not really worth it to me if it kills the batts twice as fast. Any thoughts? I have answered this question myself now at: http://forum.universal-devices.com/view ... 3871#23871

Tests done on REV 1.1 motion detector. ISY99i/IR Pro v2.7.6: The main purpose for this test was that I wanted to see how much more battery power it would take to have my motion detectors operating always and let the ISY always do the determination of what actions to take vs night only operation. 8.08mA on initial power up. No programing as this Motion Detector (MD) was already part of my system. This would be the same effect as a battery replacement. This was the condition created when I broke the circuit to put the amp meter in line. Now this is interesting. If I left the MD alone it would never go to sleep. I tested this for 30m. During this time the MD would not respond to Dusk/Dawn nor motion. It took several presses of the set button to knock it out of this mode and get the MD to flash its led and show up in the event viewer. Then it would drop into sleep mode. I tested this 4 times with the same results, but only once did I let it run for 30m. The other tests were just a few minutes long. This explains how I killed a nice lithium battery in one of my detectors when I replaced it. New rule: always make sure the detector shows its actions before you put it into service after a battery change. IE: press that set button till you see the led flash, it may take several attempts. For further confirmation make sure its commands show up in the event viewer. If not there is a good chance that the detector is not going into sleep mode and about a week from now you will have a dead batt. This also makes me wonder about the MD I sent back to Smarthome as defective because it would eat batteries. I wonder if I just did not get it to go to sleep after repeated battery changes. 33µA in sleep mode 14.34mA to Xmit a command Energy cost of allowing the led to flash: (all values exist only for the duration of time for the led flash) 900µA LED at 255 (Very bright) 350µA LED at 100 (Not so bright) Almost nothing at 1 (Very Very dim, but still visible in darkness) nothing with LED jumper disable (no led flash at all) 900µA LED at 0 (0 makes the LED the same brightness as 255? bug?) MD set in always detect mode, LED disabled via jumper, .5m timeout: 33µA sleep mode 486µA pulses about every 30s while in sleep mode 14.3mA to Xmit motion sense MD set in night only mode, LED disabled via jumper .5m timeout: 33µA sleep mode 486µA pulses about every 30s while in sleep mode 2.35mA standby mode for 30s on motion detect without Xmiting 14.3mA to Xmit For the MD to not Xmit, it still detects the motion. Even though the jumper is set for night only mode and it was bright for this portion of the test the MD still comes out of sleep. It does not use the high power of 14.3mA to xmit, but it goes into a sorta halfway sleep mode for 30s with a .5m timeout. With a 3m timeout the sorta halfway sleep mode was even longer at 57s. Once darkness befalls the detector set for night only operation the power draw is identical to the always detect mode. It jumps out of sleep to Xmit and then goes right back to sleep. Real world test: Simulating a motion event during the day. I created motion intermittently over the course of 30s during the "day" with the detector set to night only mode and always detect. LED at brightness of 100 and a 3m timeout, on-only mode: Night only mode: Average power draw of 1.772mA over 1:30m Always Xmit mode: Average power draw of .345mA over 1:30m It took over 5 times as much energy to not transmit the command. Even though the always on mode used 14.3mA to xmit, it did this for just an instant and then went right back to sleep. While the night only operation did not waste 14.3mA xmitting a command I do not care about, it sat at 2.35mA for so long in that halfway sleep mode that the average power draw was massively higher over this 1m30s test. Conclusion: It is way better from a battery life perspective to just let the MD send commands during the day and use the ISY to determine whether to execute an action or not based on other data (Sunrise/Sunset, Dusk/Dawn sensors, Weather Bug light Data, Time of Day... Etc...).

Does anyone have experience with a comparison of battery life in the detector if it is set to detect motion always instead of at dark? Most all of my motion activated programs are night only (I do not use direct links between the detectors and any other device), but I have thought of some cool programs that could run only when the 'Away' condition is set. Like having a radio or TV turn on if any of the detectors outside detect motion, even during the day. I had thought that the less I allow the detector to xmit, the less juice used. But I have noticed that the detectors detect motion always no matter what, they just do not xmit this if the night only mode is set and it is bright out. So if the detector is coming out of sleep no matter what, how much more power does it really take to xmit this. This feature is not really worth it to me if it kills the batts twice as fast. Any thoughts?

Hi guys, Interestingly, as I was performing my current draw test to see if I should put that last battery sucking detector back in the system, I got several more notifications of low battery as I made and broke battery connections by hooking up and changing ranges on my meter. My notifications are based on control, not status.

If it is a beta, it is not by choice. I have 7 of these, most were purchased when they became available without pre-ordering. I have never had a successful low batt warning before this incident. I had, until recently, been using the GP alkalines. 1 month ago I had a detector die unexpectedly with no warning. I replaced the battery with a long life lithium battery and about a week later it was dead as well. It apparently did not go to sleep even though it had been fine for 6 months prior to that. That was replaced by Smarthome. Then about 2 weeks ago when the replacement arrived I put a lithium in it and I changed all the other units to lithium batteries. A week goes by and I get a low batt notification from a detector that had never had issues before that. I have put an included GP alkaline in that detector, factory reset it, pressed its on button several times and did some current testing that seems to show it going successfully to sleep. We will see if it goes to sleep or kills this new battery. I was unwilling to sacrifice yet another expensive lithium 9V on a chance.

I did finally get a low batt warning. I had just put long life lithium batteries in all my detectors. After about a week I got a low batt warning from one of the units. It appears that it killed the battery by not going into sleep mode. Version 1.0B

Tim, I think your ISY works differently than mine. I powered it down and upon reboot it does not in fact know the last run time of programs that have not run since the reboot. That field is blank. That said, I think I am strongly leaning towards the UPS. Most power outages in my area are just a couple of minutes long and infrequent at that. I am guessing that I might miss one or two triggers a year if I do it this way. Yea, they are all the same events with different timings. Thanks for all your input. Do let me know if you have a revelation though.

Tim, You are right. As I think more about this, I kinda want a back-up program looking after things. I was thinking of building a couple of "Last Run" safety programs, but as I look at it, it appears that the ISY does not know when a program was last run after reboot. Am I correct on this? If so, it kills that idea. Wake Temperature 6:00AM If Program 'Wake 6:00AM' is True And Time is 2:00:00AM And Program 'Away Flag' is False And Program 'Suspend Temp Programs' is False Then Run Program 'Wake Temperature Sequence' (Then Path) Else - No Actions - (To add one, press 'Action') Wake Temperature Sequence If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Wait 8 seconds Run Program 'Standby Thermostat Query' (Then Path) Wait 10 seconds Run Program 'Wake Temperature Set Bedroom Cool' (If) Run Program 'Wake Temperature Heat Sequence' (If) Else - No Actions - (To add one, press 'Action') Wake Temperature Heat Sequence If Status 'Bedroom T-Stat' is Mode Heat Then Run Program 'Determine Temp Less 58' (If) Else - No Actions - (To add one, press 'Action') Determine Temp Less 58 If Status 'Bedroom T-Stat' < 58° (Temperature) Then Set 'Bathroom Floor Heater' On Wait 3 hours Set 'Bathroom Shower Heater' On Set 'Bathroom Sink Heater' On Run Program 'Heat Bedroom Wake ' (If) Wait 30 minutes Run Program 'Heat Liv Wake' (If) Wait 40 minutes Run Program 'Heat Bedroom Sleep' (If) Wait 30 minutes Else Run Program 'Determine Temp is 58 ' (If) What if I changed the IF in the 16 different versions of Wake Temperature 6:00AM to say: If Program 'Wake 6:00AM' is True And From 2:00:00AM For 3 hours And Program 'Away Flag' is False And Program 'Suspend Temp Programs' is False Then Run Program 'Wake Temperature Sequence' (Then Path) Else - No Actions - (To add one, press 'Action') Now I do not put a UPS on the ISY. If there is a power failure while the sequence is running at least the events will happen right? The ISY wakes up, reboots, and re-evaluates the programs right? So now this is still true if it is within whatever time window I decide is worth it, like two or three hours. Then it starts the sequence again, so if the power was out for 6 minutes right over one of the sequence commands, that will get picked up, just late. The nice thing about this methodology is that I only need to slightly tweek 16 programs to implement it. The down side of course is that if the power goes out 2 hours after the sequence has started, the whole thing has to start over. No, it is looking like the UPS is the best idea and I will just miss any call that occurs over a power failure. The only other solution I can come up with involves writing more programs than the ISY-26 can handle, and even if it could I do not want to deal with administrating 400 temperature programs!

Tim, Excellent suggestion. Couple of questions and thoughts. If last run is used, will the ISY employ catch up scheduling after a power failure? I have spent hours trying to figure out how to use this feature with my wake programs, but I just do not see it. The main problem I have is that there are 16 different possible temperatures for my room to be at wake up time, and the sequence of events and timing of those events is different for each of the 16 temperatures, and there are 16 different times for those sequences to be initiated. I could use last run for the initial start of the sequence of events, but I do not see a way to streamline the timing of the individual events within the temperature possibilities. See this post: http://forum.universal-devices.com/view ... 2258#22258 Without getting too detailed as I have over 150 interdependant programs dealing with this wake sequence, this is my big problem child: If Status 'Bedroom T-Stat' < 58° (Temperature) Then Set 'Bathroom Floor Heater' On Wait 3 hours Set 'Bathroom Shower Heater' On Set 'Bathroom Sink Heater' On Run Program 'Heat Bedroom Wake ' (If) Wait 30 minutes Run Program 'Heat Liv Wake' (If) Wait 40 minutes Run Program 'Heat Bedroom Sleep' (If) Wait 30 minutes Else Run Program 'Determine Temp is 58 ' (If) I have 16 of these programs, and each one has different waits based on start temperature. To further complicate matters, there are two additional steps that will be added in there when I get some more insteon modules, as well as another 50 interdependent programs. I really like the last run idea, but I cannot figure out how to use it without writing separate "if" programs for each item, and possible start temperature, and now again I am at 256 programs or so just for this part of it. Now if I did that, any time I did not like the timing and I wanted to tweek it a little, think of all the changes I would have to make. As it is now, if I did not like the way things worked when the bedroom was below 58 to start with, I would only have to change a couple of waits in one program. This same program is called on by all the 16 different possible wake times. I am thinking UPS for the ISY but you have a lot more experience using last run, and I think I really like that idea. I just do not see an efficient, clean way to implement that in this case.

I did not think that applied to waits though, unless the ISY saves a marker of when something should happen every time it encounters a wait in a program and internally it makes a "Schedule".

The ISY has no way to deal with waits through a power failure/reboot right? I have 16 temperature management programs that depend on waits in the 4 hour region. If I do not use waits, and I use clock time I have calculated that I will need 256 programs. I am not going to be doing that! Does the ISY know when it was supposed to do something on a wait, and it will pick it up with a schedule catchup like function, or should I be putting the ISY on a UPS in my case?

IndyMike, Now that I have thought about it, I think I will go the other way with my time-outs to reduce the dusk/dawn triggering. When you looked at the dusk reporting, did you find that the dusk/dawn period would be +3:30 regardless of time-out period selected? IE: Is it plus 3:30 for very short time-out periods as well as very long ones? Also, did you find this through documentation or experimentation? Just curious.

Yea. That works flawlessly. I will be using that feature whenever I work on the system from now on as I have lots of automated programs that could run and much with adjustments to the system.

I thought I had had a problem with this once before, but maybe I was trying to run the "if" of a program inside a folder not "then" or "else". I had been playing with this inside a test folder and it seems to work, I just got a little scared of messing with the "My Programs" folder because of the anomalies I remembered. Now that I have gone back and played more with the test folder it does seem that only running the "if" gets funky, not the "then" or "else". So here goes....

I have a program that is not enabled (I manually set it as true or false) that is set up to disable any automated program in the ISY to facilitate interruption free device adding/scene adjusting. I just realized that we can set a folder condition on "My Programs" If I have a program called "Suspend ISY" that is not enabled and I set a "My Programs" folder condition to: If Progam Suspend ISY is false then allow programs in this folder to run would this accomplish the same thing. The one thing I am concerned about, and the reason I have not just tried this is that the very program "Suspend ISY" is a program under the folder "My Programs". Will I still be able to set it as true or false and have it evaluated properly, or could I potentially brick my ISY with this setup?

Besides Humidity, the 7 day is compatible with multi-stage systems. Even if you do not have a multi-stage system, this may be a consideration for future-proofing. 2 days after installing my 2 t-stats I had my annual AC check-up. My AC guy tells me it is time for a new system, and that this will be the last summer with this unit. Now I am looking into multi-stage systems and of course I bought the 1 day which is not multi-stage compatible.

Very cool. Excellent use of the adjust scene feature. I had not thought of this use of the feature. I think one of the "Sunrise" in each statement should be "Sunset", no?

IndyMike, Very interesting. I had not realized that the dusk/dawn period is in relationship to the timeout. I do not think that my sensors are behaving very differently than yours. I do not use the off command on any of my sensors. I have a short time-out and the off command is timed and handled by the ISY, usually for a much longer period of time than the time-out. I think there is only one or two programs that have a shorter timer section than the detector time-out plus 3.30m. This is why the sensors are seeing the local lighting. I will have think about this new understanding. I was planning on shorting the time-out to 1m on all but one sensor, but now will have to reconsider this from a network traffic perspective as that will mean not only the additional On commands but additional dusk/dawn triggers for the 2 sensors with shorter ISY timers.

IndyMike....but again, that also changes the functionality of the devices itself. The motion detectors brightness setting for dusk/dawn also affect the night only operation of the detector. Further, the detectors are still pointing at the very areas lit by their operation, so any setting that is set for the proper darkness sensitivity with change the dusk/dawn sensor with a motion trigger after dark. I am not looking for a solution from the forum on this one, as I believe it is a design issue with the motion sensor product. I am just venting....

A very interesting idea. Unfortunately in my case I would also like the majority of the sensors to only function at night, again to save battery energy and network transmissions. So I would like the sensor to still be able to tell dusk/dawn. I would like to have a jumper where it does not transmit this condition, very much like the On only jumper. The unit still has a time-out value, it just does not transmit the Off command.

I have 7 motion sensors. I have never had a successful low battery indication. Also, I wish I could disable the dusk/dawn transmit feature. All of my motion sensors point at the very areas lit by the lights tied to the sensors. I do not use dusk/dawn sensing in any programs and this is just a huge waste of battery energy in my situation.... at least 10 unnecessary transmissions per detector per day. So not only battery draining, but at least 70 unnecessary radio traffic transmissions per day, usually many more.