Illusion

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.

Mike, I have always enjoyed your posts where you refer to the minimizing of transmissions. I have re-written nearly every program I ever have made after trying to look at them thorough your eyes. I have increased the complexity of the work the ISY is doing considerably while drastically reducing network traffic. Now I have thermostats. I am working on my porgrams for them, and continually referring back to this post. I am a little perplexed why a person who is so relentless with the attempts to reduce network traffic why you have a 15 minute query cycle. I currently have 2 thermostats, but will be adding a third soon. It seems to me that with 12 extra transmissions and receptions an hour I am likely to reduce the reliability of my system. Would not an hourly query work nearly as well for your purposes. I love the idea of an up to date status in the ISY, but with 7 motion detectors triggering events around my house, surely one of these motion events would end up coinciding with a query if I was doing 144 of them a day. Do querys take less network time than other commands. Could you explain how you reconcile performing a query every 15 minutes when you are sooooo careful elsewhere to minimize insteon communications?

Thanks Darrell, I did search the forums and did not find that info. The Wiki had not occurred to me. I will check there first before posting a question next time.

ISY-26 here. How many characters can the password and or username be? Is caps allowed and relevant? Are symbols allowed? I am trying to change my password to an 11 character and I get an error of <,> not allowed. There is no "," in my attempts. I am a little hesitant to just try different options as last time I had to reset the password and username in the ISY via Telnet because it took one and I could not figure out what had happened and could never figure out what it was looking for. I did notice that with this new version (2.7.5) it shows what I typed with a dialog box before submitting it. Much better.

Guy, I have that $100 X-10 fan control and it is GREAT! The only waste of money is the fact that it is X-10, tuff to include in scenes and the thought that an Insteon fan control may come out. I am hoping for one myself.

I am trying to get this. Simple example. I have a table lamp, it is linked to KPL.D. It also is part of an all off scene and a movie lighting scene. The all off scene is KPL.C in non toggle mode and will turn off all the lights in the Living Room regardless of what is on. The movie scene is triggered by a RemoteLinc.5 It seems to me that I should track status with a program in the ISY but this post by Michel makes me wonder if I am missing something more elegant. I tried putting the KPL.D in the movie scene as a responder, but that did not work as the table lamp has an on level of off for the movie scene, and the KPL.D gets turned on then. Is it different if the KPL.D is a Controller vs Responder? Can a KPL secondary be a controller of more that one scene?

I have spent the better part of a day working on my Verizon Fios Actiontec MI424-WR modem/router. I have several thoughts I would like to share as this thread was tremendously helpful and I would like to add to it. I am not sure that a static IP address is necessary with this router. The first screen you come to when you attempt to forward ports is "Add Port Forwarding Rule" Rather than specifying an IP address on your network to port forward to, this router allows you to specify a device. If you specify a device (the isy) I believe the applied port forwarding rule created will follow that device to whichever IP address the router assigns it. This is how I am doing it now and it appears to work flawlessly. First off, Sloop and Michel, I think there is a much easier way of accomplishing this. I have read the instruction manual for this router and have come up with this: If you simply select "HTTPS - Secured Web Server" from the protocol drop down it creates a rule: "TCP Any -> 443" the exact rule created by manually adding a server port as Sloop did and I did initially. This further buttresses the claim that the source port needs to be set for Any. Michel, I think setting the source port to any at this point does not in fact create a DMZ Host. While I am not clear what this function is for in this router, I found a preexisting rule for the local host and it included any as its source port... in the server port subsection, not in the parent port forwarding rule. You still have the selection "Forward to Port:" set as "Same as incoming port" in the rule. While all this is a bit confusing I think setting the isy up in this router could be as simple as a couple of steps. If you have an isy with the default port of 443 still set and set for DHCP I think all you need to do is connect it to your Actiontec router, let it get an IP address and follow these steps: 1. Login to your router 2. Click Firewall 3. Click yes 4. Click Port Forwarding in the left hand Navigation screen 5. Click the add in the bottom left of the screen 6. Select the ISY in the "Networked Computer / Device:" drop down menu 7. Select the HTTPS in the "Protocol" drop down menu 8. Click Apply This will create a rule that should chase your isy. The rule created will be identical to what Sloop made, but the server port settings will be put in by the router. No need to set the isy to a Static IP, no need to configure the router to deal with a Static IP, no need to specify server ports. And now on to the issue of Dynamic IP from the ISP: It appears from the manual that this router will update http://www.dyndns.com/ if you use that as you DNS Hosting site. In the advanced settings you simply select Dynamic DNS and input your DYNDNS account info and wamo, you have an updating account without any client having to run on your computer. I just did this yesterday, so we will see how it works when Verizon changes the public IP. I have my fingers crossed.

Gary, I am getting ready to drop a bunch of money with Smarthome on the Venstar 1700 insteon thermostats (20% off sale). I cannot tell what features the ISY supports without adding the device. Are you saying that the ISY cannot poll the information the thermostat receives from the outdoor sensor? If that is true I will save the dough on purchasing the outdoor sensors as ISY integration would be the only reason I would get them.

Rand, I do not have a ISY capable of the Weather Module, but am considering getting one. Am I reading you posts correctly that the module receives current data, but not predictive data. For example, one of the things that would justify the expense and hassle of changing my system to a new ISY would be knowing that it is greater than 70% chance of rain tomorrow or going to be high humidity, or low temp, so do not allow the sprinklers to run today. Or it is going to be really cold tomorrow, even though it is really hot right now, so do not crank down the AC, just wait. The way I am reading your post, this is not supported, and the data is not even there. Am I correct?

Okay Michel, I will accept that this is "fixed". I had a hard time accepting this. I have tested this for two weeks since installing 2.7.1 and the chime only has double sounded twice, which I suspect was do to X-10 issues. I have not seen the double command sent by the isy in the event viewer since upgrading to 2.7.1 While I know this puts this issue to rest with you {since there is no longer a problem} if someone else is reading this and can satisfy my curiosity I still would like to hear your thoughts. If you read the previous posts carefully, you will see that the trigger for the isy sending the second, undesired X-10 command was an if then program in the isy that had nothing to do with the program that was supposed to send the single X-10 command, except that the program in question was called from the same program that initiated the X-10 command. I am stumped, and it took me a long time to even find this association, but when I did it was a 100% correlation. Michel, thanks for fixing this issue. See that, I did not use quotes there, indicating that I really am coming to terms with this being a fix.

Have you had any luck reproducing this? Even if you do not have a fix, I would like validation that I am not crazy.

More data points for analysis: I changed Front Porch Motion On to: Front Porch Motion On: If From Sunset To Sunrise (next day) And Status 'Front Porch' is not On Then Set 'Front Porch' On Else - No Actions - (To add one, press 'Action') Now if I trigger the motion detector after sunset, the isy only sends the second X-10 F3 on command set if the porch light is not already on. If the porch light is off I get the two distinct command sequences sent from the isy and the chime sounds twice. If the porch light is on, the isy sends one command sequence and the chime sounds once. So it is the actual act of turning on the porch light that seems to be causing the isy to send an undesired second command set. Why in the world would altering a downstream program that has nothing to do with X-10 have such an effect as causing the isy to send multiple X-10 command sequences in another upstream program? Chris Jahn Help!

Michel, No, the dusk/dawn feature of the detector in question is disabled via the jumper. The detector is active 27/7 I think we have a bug here, or at the very least an anomaly. Last night I did some troubleshooting. I removed the line Run Program 'Front Porch Motion On' (If) from Motion-Front Porch and triggered the program after sunset by moving in view of the detector, and the chime only sounds once. The event viewer confirms that the isy only sent the F3 command once. If I put that line back in and trigger the detector after sunset the isy sends two F3 on command sequences. (Of course sunset is subjective here because for testing purposes I am altering the internal clock of the isy to facilitate daylight hours testing.) The system did not used to do this per my memory. This anomaly started with the betas somewhere around 2.6.13. That is not a hard and fast fact though as it is only now that I understand when the double chime is happening. It took me a while to figure out that it was only after sunset. One more data points for analysis: The chime will not occur twice if the program is trigger from the program menu. It must be triggerd by the if statement being made true via the motion detector seeing motion.