Illusion

I have a program that alerts me if my house goes outside preset temperature ranges. I have another program that queries the t-stats about every 3 hours. Immediately after one of those automated queries yesterday at about 5p I received multiple notifications of temperature outside the range, but nothing was wrong at the house. Any thoughts as to what happened here? Temperature Alert! If Status 'Bedroom T-Stat' > 88° (Temperature) Or Status 'Bedroom T-Stat' < 56° (Temperature) Or Status 'Living Room T-Stat' > 87° (Temperature) Or Status 'Living Room T-Stat' < 56° (Temperature) Then Send Notification to All Else - No Actions - (To add one, press 'Action')

I re-wrote the programs so the test switch is first in the program and it happened again last night and the results were the same. I went to the log and found this relevant entry: XX- Test Switch V.27 On 255 Mon 10/26/2009 08:20:44 PM Program Log Front Porch KPL On 255 Mon 10/26/2009 08:20:44 PM Program Log XX- Test Switch V.27 Status 100% Mon 10/26/2009 08:20:44 PM System Log The detector sees motion, runs the initial program, but the ISY does not realize that it succedded in turning on the front porch, so when it runs Front Porch Motion Off Not Enabled it stops the program because it runs the Else Clause erroneously. Notice that there is no System Log for the KPL status! The ISY still thinks the KPL is off even though it is really on. This prevents the test switch from getting turned off because the ISY thinks the KPL is already off! So I have answered the question of how this is even possible, but now I have another question: If the ISY sends a direct command to a device like "turn on" is there a communication failure that would allow the device to turn on but have the ISY think the device is still off?

Make sure that the "ON" only jumper in the battery compartment is not set. Make sure the Motion Detector does not see any motion at all for the full amount of time that the timeout period is set for.

Are the lights directly linked to the I/O or are you waiting for a program to execute? If you are using a program, how about just putting the I/O linc sensor in a scene as a controller and the lights as a responder? If you are willing to have all the cabinet lights come on at the same time you could save a bunch of money and just use the I/O linc you just bought. Just wire all the magnetic contacts in parallel to the sense terminals. If any door opens the I/O linc will know about it.

You can also do some elegant program saving steps with something as simple as a control switch like: If Control 'Bedroom ControLinc.1' is switched On And Control 'Bedroom ControLinc.1' is not switched Off Then Send X10 'E1/On (3)' Else Send X10 'E1/Off (11)' As a new user it took a while for me to get used the the fact that the ISY is event based. This is why it does not keep sending commands. It runs the then when the conditions become true and the else when the conditions become false. This is important to remember when building new programs because this efficiency does have some unexpected consequences for the uninitiated. For example, in your program, if you were to turn off the J9 manually when it was on because the program had turned it on, the light would stay off till the next event changed the condition of this program. IE: J9 would not get turned on by the ISY until the next night, when the conditions once again became true.

Rand, Thanks for taking the time to wade through those interrelated programs. I thought the same thing about the program becoming false, but the program is Not Enabled. As I understand the ISY, and as I have these programs set up, that action changing a condition of the program should not be a factor here. The "IF" is only evaluated when specifically called on from Motion-Front Proch. A change to any condition after this evaluation should not have any effect. Or so I thought. Am I wrong on this point? Have I been misunderstanding the way the ISY functions? If so, I have a whole bunch of programs that are Not Enabled where the conditions are changed by the actions that I will have to revisit.

Lets assume a comm failure. The SWL and KPL are on the same circuit. At this point, I am only trying to understand one thing: Why does the ISY think that the test switch is on, and in fact it is on, after this program sequence has run? But it thinks the KPL is Off. If there is a comm failure to a device in a program, does the program stop running? That is the only explanation I can currently come up with. In fact, I am going to reverse the position of the devices in the program so the ISY talks to the test switch first.

Motion sensor is only linked to the PLM. ISY controls all actions.

Successful Low Battery notification. #2420 Rev 1.0B Duracell Alkaline Battery at 7.9V

I have a KPL v.2D that I have been having intermittent problems with for some time. I have my front porch light as the load for this 6 button KPL, which is triggered by the ISY in response to motion. Sometimes the light will be on when I know it should have turned off. I created a program to query the state of the switch for conformation, but that did not help. I would notice the light on when it should be off, open the Admin Console and see that the ISY was complaining of 'Failure to Communicate' with this device and the status of the device would show as off. I added a SwitchLinc v.27 to the circuit and the programs to test whether I have a comm issue, or a defective switch, but the results of this test confuse me even more. Motion-Front Porch Enabled If Control 'Front Porch-Sensor' is switched On And Program 'Dark Outside' is True Then Run Program 'Front Porch Motion On' (If) Wait 5 minutes Run Program 'Front Porch Motion Off' (If) Repeat Every 0 seconds Wait 10 seconds Set 'Front Porch KPL' Query Wait 5 seconds Run Program 'Front Porch Motion Off' (If) Wait 5 seconds Wait 15 seconds (Random) Else Repeat Every 0 seconds Run Program 'Front Porch Motion Off' (If) Wait 10 seconds Set 'Front Porch KPL' Query Wait 5 seconds Wait 15 seconds (Random) Front Porch Motion On Not Enabled If Status 'Front Porch KPL' is not On Then Set 'Front Porch KPL' On Set 'XX- Test Switch V.27' On Else - No Actions - (To add one, press 'Action') Front Porch Motion Off Not Enabled If Status 'Front Porch KPL' is On Then Set 'Front Porch KPL' Off Set 'XX- Test Switch V.27' Off Else Stop program 'Motion-Front Porch' I had the failure the other night. I open the Admin Console and get the expected warning about comm failure with the KPL, but no exclamation point on the device tree. The ISY shows the status of the KPL as off which is false, but expected with the comm failure. As the ISY believes the KPL off, the loop in 'Motion-Front Porch' is stopped. The ISY shows the status of the test switch as On. A query of both devices changes the status in the ISY to On for the KPL and the test switch also has its status stay as On. How can this be? If the program ran as it should, the test switch should have been off. Does the failure of the KPL to respond affect the ISY's ability to send the next command in a program. If I had a comm failure to the switch as well as the KPL I would expect the ISY to show an Off condition for the switch just like the KPL regardless of reality. If I did not have a comm failure, why is the test switch on? Any thoughts or help would be appreciated. I am missing something here, I just do not know what it is...

Okay, 5 months later, Verizon changed my public IP. The DYNDNS service worked perfectly, apparently being notified of the change by the router itself.

You need to get the status of the front porch light into another program. Any time you turn on your front porch light between sunset and 12.01a this program will again become false and run the else path. See: http://forum.universal-devices.com/view ... highlight= While these programs are built around motion detection, they will also work perfectly for this application.

Using what I have learned from my tests I am going to begin testing long term battery life. I am attempting to maximize my battery life in these tests. I have 7 Motion Detectors. I have taken all the MDs apart and dripped black liquid electrical tape on the photo eyes thereby disabling the Dusk/Dawn feature. With 7 detectors that is 5110 radio transmissions and Insteon power line transmissions eliminated each year... minimum. As I use the ISY to determine time to keep devices on, and those waits are much longer than the internal timeouts in the MDs, the MDs would often see the area that was then lit up and would xmit a Dusk/Dawn command. Now those events will be eliminated as well so it is many more than 5000 radio transmissions and Insteon power line transmissions eliminated each year. I am only using the "On" from the MDs, letting the ISY determine the off for devices that are reacting to the MDs. This will save 50% of the radio transmissions and Insteon power line transmissions that occur as a result of each motion event. I have increased the default timeout from 1m to 3m on the detectors. This will reduce the number of retransmissions when motion is continuous in an area. This does have some potential negative results but I hope it is worth it on the battery saving front. The detectors always detect motion and xmit and the ISY will determine what action to execute based on sunrise/sunset conditions. This is due to my finding that this actually takes less energy than night only mode. The LED is set to a brightness of 100. Battery life could be improved if I disabled this via the jumper, but I really like seeing the LED for feedback. I am using lithium batteries. I will post back here when they die.

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!