d_l

I'm not sure for what reasons some people use two programs to turn a device on and off, but my practice is to have an on and an off point within the program if possible. This is for two reasons: 1.) it keeps the program proliferation down and the total number of programs more manageable, 2.) and I typically name a program with a statement such as "Entry Lamp On" and then program status column will read true or false for that statement. To answer your question, here is a program I use to activate an X10-controlled lamp: If From Sunset - 45 minutes To 10:30:00PM (same day) Then Send X10 'C1/On (3)' Else Send X10 'C1/Off (11)'

Email control would be a handy feature to have. The ISY would have to be polling your POP email server repeatedly to do this. The response lag to your email command would be determined by polling frequency, e.g. if the ISY only checks email every 15 minutes, then it may take up to that long to be able to command an action at your place. You would probably need a secondary password just for emails to authenticate that your email is indeed from you and not from someone else. To maintain security, you would not want to give out your primary access password in emails because of the non-encrypted nature of email transmissions. Additionally you would want a unique email account just for communications with the ISY rather than having it read one of your regular email accounts. You wouldn't want the ISY having to continually read through and digest all your other email and spam looking for the one command to light up the fireplace. I've set up a remote rebooter for the power supply on my home network so I've previously considered these facets of email remote controls.

I have mostly X10 devices operated with non-extended commands and in simple on/off mode. I held off purchasing it until they added X10 support and I knew from reading this forum that it just had basic X10 capabilities. I'm very happy with the ISY! In fact, the ISY's capbilities have greatly exceeded my expectations I've made a suggestion someplace around here for an separate X10 tab to place "programlets" that show the last command (on/off) given by each X10 device. This tab would mimic the Main tab as much as can be possible for X10 devices and keep those X10 status tracking "programlets" out of the Program Summary page. Do I need that tab (or something like it)? No. I can live without it. It would be nice if they could implement it without a major distraction from the other promised feaures they are working on. Hopefully when they get a chance they can add it or some other way to better organize/separate the X10 devices.

Upstatemike, the Insteon devices at least have the Main page tab to keep all the devices and their status listed. The X10 devices have nothing similar. I have "programlets" for each X10 device address to track its state and give it a name. It would be nice to have a tab like the Main page, but just to organize all the X10 state programlets. It would keep them separate from the real programs and keep the Program Summary screen from being filled up. As it is now, I start the name of each X10 programlet with "* " so I can use the sort by name to bring them all to the top when I want to check the status of X10 devices, but that is a kludge compared to a dedicated X10 tab. Dave

Good question, aLf. I've wondered if this could be used by a program to automatically power off the old version Togglelinc Relays which power up in the on state after a power interruption.

OK I've figured out the problem! All my X10 status programs were in a folder with the set condition "If QueryAll is true". One other folder had that conditon as well. I see that the "QueryAll" isn't an offered conditional option for folders in this firmware version. Once I removed that conditional test from the folder, the programs report their status correctly. Problem solved. So something had changed in the underlying logic code for the Status line.

That's just it. The status column does not change from False now. With 2.4.14, it would change between True and False as per your quote. Java Console output from several D3 on/off cycles: Using JRE version 1.6.0_02 Java HotSpot(TM) Client VM --snip-- 2007/11/29 13:10:08 : [ X10] hc=D uc=3 cc=3 2007/11/29 13:10:12 : [ X10] hc=D uc=3 cc=11 2007/11/29 13:10:19 : [ X10] hc=D uc=3 cc=3 2007/11/29 13:10:22 : [ X10] hc=D uc=3 cc=11 2007/11/29 13:10:32 : [ X10] hc=D uc=3 cc=3 2007/11/29 13:10:35 : [ X10] hc=D uc=3 cc=11 2007/11/29 13:12:20 : [ X10] hc=D uc=3 cc=3 2007/11/29 13:12:24 : [ X10] hc=D uc=3 cc=11

The operation of the Program Summary Status has changed from the way it worked in 2.4.14. Previously, a little X10 status program such as If X10 'D3/On (3)' is Received Or X10 'D3/Off (11)' is not Received Then - No Actions - (To add one, press 'Action') Else - No Actions - (To add one, press 'Action') could show the last received D3 command -- True if On or False if Off -- in the Program Summary Status. I have one of these little state programs for each X10 device and this was useful in keeping track of X10 status. It helped me "simulate" the on/off info of the Main page for the X10 devices. Now these programs no longer function in 2.5 RC1. Is this an intentional change or a bug?

Man, I wish I had found this thread last night when I installed my ISY! For some reason, I have no "Show icons for networked UPnP devices" so I have no My Lighting icon. I simply (ha ) worked out the direct http link method from some other threads in the forum. To find that unique port for the ISY, I made a serial connection through the Com port to the ISY shell. In addition to that port, I also used the shell to find the MAC address of the unit. It is listed in the output of a reboot. jgraziano, instead of assigning a static IP to your ISY outside of your DHCP pool, if you have more advanced router, you maybe able to assign what is called a "static" DHCP address to the ISY. This allows the router to assign the same IP to the designated MAC address if it is present on the network and re-use that IP for some other device if that device isn't present. I had to do this because of some network complications in which I end up with two DHCP servers and the secondary server was making the wrong IP assignment on the ISY. The static DHCP method forced the correct IP to the ISY. I found that I couldn't simply set the ISY to a static IP if a DHCP server was present on the network. After entering all the new IPs and mask, a reboot simply erased the entered data and re-acquired the DHCP IP.