apostolakisl

Based on my own experience, I very much agree with the above.

Assuming it isn't the end of the world if your ISY gets flaky on you, I would try it at 5v. If it starts needing reboots, then you can move up the voltage. But if your 5v supply is nice, you shouldn't have any troubles. I certainly have not.

I have my ISY powered off of a set of terminal blocks hooked up to an ATX power supply. Along with the ISY it is powering about a dozen other items both 12 and 5v. It has been rock solid at the 5v. However, ATX power supplies produce a high quality, stable, clean 5v through a wide range of current draws. Generally speaking (and I can't say for sure with ISY), electronics like this when presented with power above their need, dump the excess to heat via a voltage regulator. I have not opened my ISY to see what is in there, but you will recognize it if it is there as a chip with 3 leads, often mounted vertically with a heat sink attached usually right near where power enters. So, in short, providing more than the minimal voltage will probably result in more heat. Heat is generally bad. However, if your 5v power supply is flaky, it would be better to over volt it a bit and let the ISY clean it up and bring it down to 5v. So, there is my opinion.

I can almost guarantee you that your problem is that during the 20 second wait, something happens that re-triggers the program to false. If Status '01-SLD-Powder Room' is On And Control '01-TL-Powder Room-Opened' is switched On The above 2 statements are triggers for the program. If the status of the light changes during the 20 second wait, then the program re-evaluates to false, and the enable lines below never get run. Then Disable Program 'Powder Room Garage-2' Wait 20 seconds Set '01-SLD-Powder Room' Off Enable Program 'Powder Room Garage-2' Enable Program 'Powder Room Garage-2' The way to avoid this problem is to split the program into 2. If Status '01-SLD-Powder Room' is On And Control '01-TL-Powder Room-Opened' is switched On Then Run program 2 then clause Program 2 If blank Then Disable Program 'Powder Room Garage-2' Wait 20 seconds Set '01-SLD-Powder Room' Off Enable Program 'Powder Room Garage-2' Enable Program 'Powder Room Garage-2'

The appliance linc would turn on if you had in a program setting it on and the program was "true" at startup. Like if it were supposed to be on between two times and the start happened between those two times. If you wanted it to revert to its last state, you would have to have a variable track its state and have the run at startup program set the on/off status according to the state.

The only thing, however, is that if the ISY does not go down with a power outage, it won't know that there was a power outage, and any run on startup programs or catchup programs won't run. Remembering, of course, that all of the stuff ISY is controlling (probably) is going to shut off when the power goes out.

Yes, except you would use "enable" timing and motion programs, not "run". You would also need a program to "disable" them when you want them to not run. For example: If light status is off and it is switched off then disable motion program If light status is on (on means 100%) and it is switched on then enable motion program The trouble with this is that you don't have any indicator of whether the program is enabled or not. If you had a kpl you could use a button on it to enable/disable the motion programs and you would know the status by if the kpl back light is on or off. Also, you might just test the basic program that started this whole thing. I haven't tested a program that uses "fade up/down" to trigger a program that in turn acts on the same switch that did the triggering setting its current level. The question I have is what if you are still holding the "fade up/down" and ISY sends the command to go to some specific percentage. I am not sure if the switch will accept that command or ignore it while someone is physically holding the fade up/down.

I am assuming the switch is connected to the load (directly to the light). If indeed that is the case, then you can not release control of the light from the switch. In other words, if you flip the switch on, the light will turn on. Turning the light on may also trigger a program that subsequently does something else. For example: If light is switched off Then set light to 25% If the light is on and you push "off" paddle (or toggle off), the light will turn off, then a split second later pop up to 25%. You can not elliminate the fact that pushing "off" makes the light turn off (provided the switch is carrying the load)

You can sort of do what you want using programs. For example, I have a bunch of programs that work as follows. If light status is off and light is switched off then set light to 25% While I haven't tried the following, I assume it would work just as my above program does. If light status is >45% and light status is <55% and light is switched fade up then set light to 75% You would need a handful of programs here to cover all the starting levels. You do have to use the "fade up" and "fade down" rather than "on" "off" because using on/off would cause the light to first go directly to on or off, followed by the program kicking in and putting the light back to the set level. This would be rather annoying.

Elk and ISY with the Elk module for ISY almost completely merges the two systems. There are a few things left out of ISY's Elk module but not many. My 2 cents here, ISY guys should add those couple things even though they aren't that big of a deal just so they can say "it is a 100% marrigage". But anyway. The basic jist is as follows. ISY has tremendous home automation programming abilities which far surpass Elk's built in programming. ISY can do a lot more with your Insteon stuff and can do it with less work and more readable and organizable formatting. Elk on the other hand is rock solid stable (not that ISY isn't, but Insteon clearly is not 100%). So you can't use Insteon technology for security or mission critical stuff. But by using the ISY module, you can get the Elk to control those security and mission critical things (like anything that deals with water or motors) and use the ISY programming interface to do it. The ISY Elk module really expands Elk's capabilities a lot and vice-versa. And not just in programming, also in notification such as emails and texts of system events.

This works, but it requires that you put in multiple "if" conditions for each and every year going forward. If this is something you almost never need, then you can just write the program with multiple "if" conditions for each year going forward 10 or 15 years and call that good enough. If you think that you would be writing lots of date programs like every December, or every 3rd wednesday, or every 3rd day, or every Jan 3rd, and so on, then you should consider downloading the date function programs I wrote a while back. http://www.universal-devices.com/mwiki/ ... _Variables

Yes, it would be nice if ISY natively made all of the individual components of date separately addressable programmatically. That of course is exactly what I created with those programs. If you currently do not have any variables on your ISY it is a pretty quick thing to import the programs and name the variables. If you already are using varialbes and have conflicts it gets more time consuming depending on the details. I considered re-writing the programs starting with variable 50 assuming that almost no one will have used that many variables already, but frankly, I have better things to do right now then "fix it if it ain't broke" The programs work very well. I have had it up and running for a long time now, maybe a year without any problems. It also successfully managed the recent leap year.

Here is a series of programs I wrote for ISY. http://www.universal-devices.com/mwiki/ ... _Variables Perhaps it is more complex than you want, but once implemented it opens up the options for virtually any date function. This would include every other,third, fourth, etc. You can also do even/odd days only, things that happen on a weekly schedule or on a specific week of every month. Also annual recurring events like holidays, birthdays, and the sort.

Do you have an ETA for zwave?

If you are keeping your PLM, then just restore your 99i backup to the 994i and you are done. It sounds like you are giving up your x10 module and have no others so that should be it. Once you have the 994i up and running with whichever PLM you are keeping, then you can factory reset the 99i and the plm you aren't keeping. Then you can re-validate the x10 module on the 99i and give it to your friend as a clean unit along with a clean plm. I would suggest running the new system for a few days before wiping the old stuff.

Exactly

I also migrated to 994i from 99i. It was a straight forward matter of creating a backup of the 99i and restoring it to the 994i. And you should have both running the same and most up to date firmware first. If you plan on also replacing the PLM. After you restore the 994i with the 99i's backup, then replace the PLM and use the 994i to run a restore PLM. If the only module you have is the x10, and you plan on letting your friend have it, then you don't need to ask UD to transfer anything to the new unit. Otherwise, send them an email with the UUID number (located on the help/about menu) from both the old and new unit and what you want transfered. If you are using the web serer section of the ISY, that needs to be moved over on its own. It doesn't transfer with the backup/restore. I do believe everything else transfered.

I believe by device viewer he means the links table. It sounds as though the links are also in the ISY links table and perhaps got there during an import of the device? At any rate, it conceptually sounds like the same issue I had. Links in the ISY links table that do not correspond to a scene in ISY, basically orphan links. As far as I can tell, it is not possible to instruct ISY to delete individual links when they are not associated with a scene known to ISY. Perhaps there is a way to do it telnetting into ISY and manually removing them rather than through the Java GUI.

I'm trying to understand how ISY manages links tables: It seems as though it is only capable of removing links from a device/its own tables when the links are part of an ISY scene? It seems as though ISY does not do any "house cleaning". In other words, it does not try to reconcile its links tables with its known scenes. So if an extra link exists in its table, there is no way to access that link since it will only delete links that are part of scene memberships as known to ISY. It would be nice if there were a way to have ISY clear the links table, then rebuild the links table using the device's scene memberships. In this way, any orphan links would be removed without having to remove and rebuild the device manually. Ideally, a single button press "rebuild device" would do the job of clearing the links table from isy and device, then repopulate the links table from the list of scene memberships, then write the links to the device.

I'm pretty sure the answer is no, at least none commercially available. I've seen people post hacks for the oregon units but they did not look like they would be all that great and definitely not worth the effort. It's easiest to get temps into ISY if you have an Elk. Also the weatherbug module gives you weatherbug temps. CAI webcontrol has one wire sensors and those can be synced to ISY. If you find a way, I would certainly be interested. I have a number of oregon units in the house, in the wine cellar, in the beer fridge, and outside the house.

Good idea, I'll look into it.

Only the DVR is connected to IP. I believe the DVR is UPnP although my router is not so I manually configured it.

No, its not an ip based camera. They are analog cameras wired directly to the dvr. The dvr is connected to the internet for viewing and configuring. You can also skip IP all together and just plug a monitor directly into to it. It's a Swann camera system I got at Costco.

OK, thanks.

OK, so its not an error at all. But I'm still baffled as to how my camera system dvr is doing this. 192.168.1.8 is a static address assigned to that unit. I just manually did the get/desc command and it appears to just give a description of the ISY unit. Correct? Why the heck would anything be doing this thousands and thousands of time on a gradually incrmental port number.