apostolakisl

I wouldn't worry about it. SH/SL has way too much invested in their current protocol to make any changes that make ISY obsolete. They just can't since that would mean that you wouldn't be able to link any of the new devices to old devices. After all, it is the PLM that makes the links, not ISY and the PLM is made by them. The one thing they could do if things got nasty is to simply stock making the PLM. But that would take out more than just ISY and I imagine there would be lawsuits. It appears the deal is that new devices with unique functionality are not getting supported by ISY . .. as far as the uniqe function is concerned. What this means to you and me is, we dont buy those products but instead get a z-wave version of the same thing. This seems quite counter productive to being in the best interist of SL. There are some comments in a different thread theorizing that SL has outsourced its engineering and that they actually don't even know how the heck it works. I suppose this could be true. In the end, you can always get an Insteon hub to access some of those unique features, especially the one-time setup stuff.

If you are scattering your leak sensors all over the house, you will likely not be in radio range of the PLM. If your leak sensors are fairly concnetrated, then locating your plm within that same area may do the trick. Generally you don't need a lot of dual band devices to move your signal accross a house. 1 or 2 probably? As mentioned, depends on what your house is made, other radio interference that may exist, size of your house and layout. Battery device do not repeat signals for obvious reasons. Star by putting the leak sensors where you need them, and put the PLM/ISY where it suits you best. Try to link the devices. If they all link right off, then you are done. If they don't link at all, you may try relocating your PLM/ISY. If you don't want to screw around moving your PLM all over, just buy 2 or 3 lamplincs (dual band devices that repeat) and automate a few lights while your at it.

The isse as I see it is that it fills the log with a rediculous number of entries that just make it difficult to find anything else without first putting it into excel and then filtering out the 100,000 entries that are all 1% humidity changes. And I can tell you that with very still air, the humidity still changes by 1% every minutes or so. I have 5 thermostats in a building that sits unoccupied with the AC completely off for days on end and it still give is constantly bouncing by 1%.

It isn't a constant update. It only sends when it changes. But it only takes a 1% change to trigger and it changes by 1% a lot.

I like to use remote desktop or teamviewer to log into remote sites and then run the admin console from there. I find it works better than running the console on a remote computer. Of course you need an onsite computer that is either running at all times or have wake-on-lan enabled.

Is it safe to say that the motion detector works just fine if you are OK with the default settings? In other words, the time out and the night only mode can't be changed from ISY?

You've gone from most things having 0 hops left to nothing having 0 hops left.

If the device you just replaced had nothing going except this one scene, then what you did is fine. Typically, you would use "replace with" command from the ISY admin console when replacing a switch. It will replace your old switch the new switch everywhere it existed (programs and scenes . . . all of them all at once). 1) Physically replace the old switch with new switch 2) Right click switch you are getting rid of and click "remove from folder" if it is in a folder, if not you can skip this step 3) Add new switch to ISY (click on the start linking swirly button at the top of the admin console and then push and hold the set button on the new switch until it beeps) 4) New switch shoudl show up on your screen, click "finish" so new switch is added, let it delete all olds links 5) Right click old switch and click "replace with" and then select your new switch (which at this point will just have a number name) 6) Let ISY do its thing 7) Reopen admin console and put your switch back into the folder (if you had it in a folder), the original switch will be gone and now a switch with the same name will be your new switch. Done. Keep in mind, replacing one swithc with a dual band device will not do much for comm since the radio will not have any other switches to talk to. The more dual band devices, the more paths the radio has.

I understand that SH has not released the "api" or whatever they call it to UDI. So, what does this mean? Is it not supported at all or is there limited suppport? Basically, I am in the market for a couple of motion senosrs and I want to know if these are going to work at all. The purpose is to look for room occupancy and if none is detected for a period of time, to shut down the AC. I plan on having the motion sensor trigger a program with a wait of 45 minutes or so. After 45 minutes, it will shut down the AC. If it has motion, it re-triggers and starts the wait all over. Just need to know that I can do this before buying them. Thanks.

Your communications are likely to improve significantly if you replace your older single band (2476 models) with dual band (2477) ones. Smarthome is having a sale right now with 25% off and if you buy the multipacks the price is pretty good. This holds true for both the dimmers and on/off switches. No doubt, your problems are communication related. a 5-pack of on/off switches is $211 minus 25% gets you down to about $31/ea. You'll need to add something else on there to get back up to $200 for the free shipping. I've been slowly replacing mine and either retiring my old switches or moving them to low priority duty.

That would be a CHOICE you make in writing your program. Unless your two scenes are EXACTLY the same (which would be pointless), then no, your statement is false, you would always be able to differentiate them (unless you CHOSE not to for whatever reason).

I think you need to re-read my post.

Really the only way you can judge the status of a scene and not have it be wrong some percent of the time, is to do as suggested above, use programs. It could be quite tedious depending on how many scenes and how many devices in each scene, but it will work and it can be tailored to your specific idea of what it means for that scene to be on. Basically, you go through all the devices in a scene and say what level each device should be, or you can do a range for each device (basically doubles the lines of code since you need a greater than/less than line. If device 1 is greater than x and device 1 is less than y and device 2 is greatar z and device 2 is less than a and so on. The status of the program is thus a flag for the scene. You leave the "then" and "else" empty. If you don't have overlapping scenes, and you don't ever turn control devices within a scene without using the scene, then you can just pick any device in that scene and use it as a flag. For many people, that isn't the case. It sorts of defeats a great deal of the reason we own Insteon and ISY, so we can have all kinds of fancy scenarious. I suppose a nice feature for ISY would be to add an "auto-program". The "auto-program" would instantly put all the devices in a scene into the "if" section of a program along with the scene deisgnated level for each device.

Or you could drop the repeat "every . . . " and just have a "repeat" which just repeats forever. Then you use one or more "waits" in the program. As it stands now, repeat every x minutes stuff is functionally the same as Repeat (every 0 minutes) stuff wait x min OR, probably the easiest and quickest correction would be to change the label to "repeat after waiting x minutes" I think that is more clear than "repeat with wait" and requires no code change, only changing the label.

When you select a scene on the console, it lists the devices in that scene and their status, it does not list a status for the scene. What it means for a scene to be "on" is not exactly clear. I suppose, it means that every device in the scene is at the exact level that the scene dictates. But generally, that does not work out how you might want it. If scene 1 is turned on, and then a single device in that scene is later changed, perhaps only slightly, maybe from 80% to 50%, is the scene now off? Some of the third apps offer an option to designate a device in a scene as the "flag" for that scene. If that device matches the scene level, then the scene is "on". I think that is a reasonable approach, but requires that you manually define the device or devices that meet criteria.

OK, so, in short, I'm waiting for version 3. At that point, I'll go ahead and make the leap to the portal. In the mean time, I'm not going to waste any time creating more IFTTT applets.

I'm guessing the issue is how the ATT gateway IP passthrough works. It isn't really a bridge and it will "pick off" traffic it thinks belongs on its subnet or that it thinks is unsolicited. Assuming your gateway configures similar to my ATT Uverse gateway 1) Use the DMZ plus mode on the Arris. This will instruct your Arris to pass almost everything through to whatever you designate. In your case, you designate your TP link router. 2) Set your TP link router to use 192.168.2.x subnet

It sounds like your ISY might be on the wrong subnet? Are you able to access your ISY admin console when connected to each of those two routers using a computer simultaneously connected to the same one? I assume you can at least log into ISY when on the ATT device from a computer also on the ATT. From there, check to see that the ISY is in DHCP mode. This is not a port forwarding issues. That is only an issue for traffic that is initiated from outside your local network.

I just checked my log. I have 9 thermostats and the log has 65,000 entries for humidity. I isolated one thermostat, 10,000 entries in less than 3 weeks. It appears that humidity reports as the actual 1-100 percent and reports with a single percent change. A typical interval is 1 minute. Temp on the other hand rarely reports and looks like it requires a 4 point change. It does not report the actual temp however, it is rescaled so I don't know what 4 points is in degrees F. The typical time interval is generally in the hours range. Now, what does this all mean? I don't know if all this traffic is adversely affecting anything.

I just hit the quote button without deleting all the stuff I wasn't talking about. Just saying, running an on/off module just to have as a flag seems kind of less than ideal. Don't you have at least one device already in those scenes that is only ever operated by the scene? Any device that is a scene controller that is not also a responder to some other scene will work. Any such device will always track the scene. The only exception is that all devices are responders to ISY so if an ISY program controlled or if you manually did it from ISY, it would be out of sync with the scene, but my guess is that you aren't doing that. If it were me, I would have programs track the scene as I listed above.

OK, I'm confused. I think I hear you saying you have to have multiple Amazon accounts, one for each echo, but simultaneously I think I hear you saying they can be on the same Amazon account. I'm confused.

I don't really sit around with my eyes closed taking in music. Aside from my theater system, music is there to break the background silence while I engage in other tasks. I guess my real question is, if I had the portal, does that offer any ability to differentiate which Echo is sending the command when there are multiple echos on the same Amazon acct.

I guess if you have the on/off module just sitting around and have no other use for it, you can use it as a "flag". But that seems like an expensive way to track a scene. Why not use a program? if <list all the things that control the scene> is switched on and <list all the things that control the scene> is not switched off then - - - else - - - Now the true/false status of this program tracks the scene. I guess this is a little more work to set up and if you change what devices control the scene the program would need to be manually re-configured. My guess is that your scenes aren't changing often.

I use the prime music feature on several of these. I assume your "dummy" accounts don't get that?

Benoit, I have used IFTTT for my echo commands direct to my ISY (no portal). With my echos all being on the same Amazon account (I have 6 of them), all respond to my ifttt trigger. Are you saying that with the portal, I could specify that only certain echo's respond to certain commands? For example, I might want the echo in my bedroom to be the only one that accepts the command to turn on/off my bedroom light. Or, I might want to be able to say "shut light off" and have each echo respond by shutting off the light in the room it is located. I suppose I could set up my echo's on different accounts, but I suspect I will run into issues there with my Amazon prime features and stuff.