gduprey

Howdy, I split my time between two homes (50%/50%) and I've equipped both homes with an ISY for automation and an Echo. Both Echo's are linked to my Amazon account and I'm going to have the ISYPortal on both ISYs How would I approach setting this up so that commands issued to the Echo at one house control only that houses ISY and vice versa? Thanks! Gerry

Is there a list of good and bad words to use with this? For example, I tried to create a program entry "open garage door" and alexa keeps saying it can't find anything called "garage door" (stripping the open or close). This happens with the short version or the explicit "run program open garage door". I find that other words like having "lights' in a name really seems to make things ambiguous. It cannot process the word "counter". It says it cannot find a device named "counter", so it understands/parses the word, but it cannot match things (for a test, I renamed a light to just "counter" -- nothing else -- and it still said it couldn't find counter. Renamed it to "hallway" and it worked fine. Is "counter" a special word? I can get things to work, but it looks like there are pitfalls regarding what words you can and cannot use and finding a map/list would be a huge help. In concept though -- it's brilliant!! I can't wait to make more of it work. Gerry

I'm pretty sure there is no change to the unit itself -- they just swapped a NC sensor for an NO one in the package sometime after Aug 2014 and Nov 2015 (my two sample points). If you mean the "reverse trigger" feature of the IOLinc, I agree -- conceptually a good idea that fails because it only works on reports, not on queries. Can't imagine anyone would complain if they fixed it so it worked on reports and queries, but good luck Gerry

That's my current guess too. I'll confirm it (next month) when I'm around the units purchased in mid 2014. For the moment, I just reversed some logic, but I always hate when things aren't consistent, so I know I'll eventually change the sensor on the new one to match the old ones

From what I've both seen and read, that "middle of the night" query thing happens mostly because someone has used the "trigger reverse" option. Trigger reverse does "reverse" state change reports, but doesn't reverse the result of a query on the device. So middle of the night when you have the ISY query all nodes, it will get a different state from anything with "trigger revese" than was last reported do to a change in sensor.

Thats what I have now (CLOSED => ON). My earlier ones show 'OFF' when the door is closed. So that either means there was a change in the supplied sensors from NO (today) to NC (a year ago) or something with the older config. Again, won't know for sure until I'm back out there, but will try to remember to post after to settle the issue.

If you're sure of that (I never feel sure of anything when dealing with IOLincs), then the only other possibility is that SmartHome switched from an NC sensor to an NO sensor sometime in the past year. While that would explain things, it seems like the sort of thing folks would have noticed/commented on. At the moment, my other IOLincs are 900 miles east of me and I won't be able to test them until next month. I'd be curious if anyone else who has purchased their 'garage door kit' in the last 6 months has noticed if they got an NC or NO sensor? Gerry

By report I mean that each time there is a chance, the unit successfully sends a report and it shows on the admin console (state change). The LED is ON when the console reports OFF and vice versa (light goes off and admin console reports ON). I'm using the Insteon garage door kit which is the same kit I used on two other doors I have (that work correctly). I do understand the differences between NO and NC contacts. I can promise you that at the moment, using the same hardware kit, this unit is reporting opposite of what my other units do. I also read in the iolinc manual that it considers the state that the sensor is in when the unit is linked and uses that as its "ON" state, so I'm guessing I had this one in a "door closed" state when I linked it and the others were in a "door open" state. Gerry

I actually did a factory reset and restore for those reasons. Plus I did it while the sensor was in the opposite state hoping that would "catch". No dice. The light on the iolinc does track the actual sensor correctly and I am seeing reports correctly, but seeing ON when I should see OFF and vice-versa. Gerry

Howdy, I've just found out that one of my iolinc's reports it's sensors ON/Off state backwards from the rest of my iolincs. I've confirmed that none of them have the "trigger reverse" option set. From reading, it appears that the state the iolinc's sensor is in when it's added to the ISY is used to determine whether that is an ON or OFF. My guess is I had the sensor in the wrong state when I added it to the ISY (well, opposite of my other iolincs when they were added). My gut was that I have to unlink the iolink from the ISY and re-link it back again. Problem is I have a bunch of programs that will "break" if I remove the device and re-add it. Is there a way to "re-learn" what sensor state sends an ON vs OFF for an already linked iolinc? I don't want to use the "trigger reverse" option as there are numerous problems with that. Thanks!! Gerry

Howdy, I did the PLM restore and everything seems good again! My ISY is plugged into a UPS (the PLM isn't, of course). The PLM is only 6 month old. I'll keep my eye on it and if this happens again, I'll look into replacing the caps (old hand with soldering iron and electronics). Thanks all!! Gerry

Well, further investigation seems to suggest the PLM lost it's entire link table. I noticed that using Tools->Diagnostics->Show PLM Links, there were only a few links, but after I restored about 3 devices and checked again, it had a lot more. So something wiped my PLM link table! I'd like to use the "Restore PLM" option. I know it's meant primarily for replacing a defective PLM, but I wanted to ask if folks think I can use it to just restore the link table of my current PLM? Reading it over, there are "scary" notes about having to re-program all by battery devices (which number over 20 now and not all very accessible). Is that only the case when replacing the PLM (as the PLM address would likely change)? If so, would I be safe just disabling battery device writes and doing a PLM restore? Thanks for any help/suggestions! Gerry

Howdy, This morning I noticed that none of my ISY programs seemed to be working (timed lights and such). I spent time reviewing the programs, thinking somehow I disabled them, but all worked fine. I could turn lights on and off from the admin app just fine. Manually turning the lights on/off did not show (even after a refresh) in the admin app, but using the "Query" option correctly read the device. So it seemed like the switches stopped sending updates when they were manually turned on or off. Look further and testing, **every** single switch on my ISY network (which has about 70 of them) all stopped. On a hunch/guess, I did a restore on one of the switches and after that, it started reporting manual changes again! I tried a few more and for everyone I "restored", they then correctly report manual changes again. So on the upside, I can recover, though it's a royal pain. On the downside -- WTF? Other than adding a few Insteon leak sensors yesterday (which added without incident and are reporting fine), I cannot imagine why every single switch would stop working like that. I know it's a shot in the dark, but I thought I'd ask around here if 1) anyone has ever seen this before and 2) if anyone had any idea, theoretical or not, how something like this could happen system wide? Also, is there some way I can have the ISY basically restore every single switch from it's internal definitions? That would save a tremendous amount of work. Thanks for any pointers/suggestions!! Gerry

Howdy, Thanks -- that was exactly what I was looking for. Enabling the two nodes thing allowed me to bind ON to a scene and leave off under program control. So my on occurs when either door is opened virtually instantly and the off is done with logic when both doors are closed with a small (but totally fine) delay. I really appreciate the tip and advice!!!! Gerry

Howdy, I have a utility closet with french doors that open into it. I've installed 2 hidden door sensors - one per door - and a switchlinc to control the overhead light. The idea is when either door is open, the light automatically turns on and when they close, the light goes off. First attempt was creating a scene, adding both sensors as controllers and the switchlinc as responder. For turning the light on, it worked *GREAT*. Virtually instant response to a door being opened. Unfortunately, when either door was closed, the light was turned off (even if the other door was still open). Ideally. you'd only turn the light off when both doors are closed. Second attempt was writing 2 programs. The first turns the light on when either door is opened. The second program turns the light off only when a sensor is closed (control) and the other is already closed (status). This worked well in that it did what I wanted, but there is like a 2-3 second delay in opening the door before the light turns on. This received a very low WAF, especially after the first attempt (which worked instantly for turning lights on) was seen. What I'd really love to do is make the door sensors and light part of a scene for 'on' use only (so either door would INSTANTLY turn the light on), but not have any scene control when a door was closed (leave that to the program -- it's no big deal if the light stays on an extra few seconds after the doors are closed). I don't think such a thing is possible, though I'd really love to be wrong. Has anyone done anything like this? Any tips to reduce/eliminate the latency in opening a door/turning the light on? Thanks!! Gerry

Thanks folks!! That makes sense (well, it works, I agree the action name is slightly confusing, but get the point). One odd thing when I'm trying this out, the "In Scene" drop-down box seems to show me only 10 items - a mix of some scenes and some devices. There are plenty of devices and scenes it doesn't list. When I switch the action to 'Insteon', the drop-down there shows me all scenes and devices (about 40). Switch back to 'Adjust Scene' and only 10 items. Is there something special about a device or scene in order for it to be listed as in the 'In Scene' drop-down box? There is nothing special or common about the 10 items I can see in it. Gerry

Howdy, I know this is bring up an older topic, but as a relatively new ISY/Insteon guy, the response here kind of confused me. As I understand it, each dimmer switch as a 'Local On' dim level (used when a person presses the switch). In addition, it can have a number of defined scenes which have various other dim levels and when the related scene is activated, the switch goes to that level. However, activating the scene does not change the 'Local On' dim level. What confused me in response #19 was what I think I read saying that the 'In Scene X Set Y xx%' changed the 'Local On' level. I thought the ''Adjust Scene" action just modified the level for the defined scene in the specified switch (so that a subsequent activation of the scene would set the switch to the newly adjusted level). I didn't think it also altered the default "local on" level too. Am I misreading that (particularly, post #19)? If not, is there a way to simply change the level/ramp for a device in a scene without also modifying the "Local On" (manual activation) default level? Sorry if this seems silly, but this made me question much of what I thought I was getting an handle on with Insteon Scenes. Thanks! Gerry