ncoig

Add me to list. Local connection works, two different devices suddenly 404 blocked using an active portal sub. -N

I don't mean to disagree, but I'm trying to do so without being disagreeable! I have an open/close sensor (TriggerLinc v.43) on my pantry door -- I had setup a scene for the light with two members: the light, and the sensor, both as controllers. If I left the door open and turned the light off, the sensor would change status to "off" or "closed" according to ISY. As a result, I removed the light switch and re-added it as a responder only so that I could see from the ISY if the door was actually open or not. Hopefully this helps someone if they happen upon this information. -N

Thank you for the idea - regrettably, this isn't the primary concern -- rather I need to be able to control the load-bearing switch directly, but have it respond as the scene to keep the other indicators on KPL's in sync. Thanks, though! -N

This is true and good information, unfortunately, the link to the Wiki with the aforementioned information is darn near impossible to find, even knowing that it's there. In fact, Michel had just pointed this article out to me a few days ago. I still can't find it when I google, I'm just glad he hyperlinked it. For those looking, it's here: https://wiki.universal-devices.com/index.php?title=INSTEON_Random_All_On_Events I did have several IOLincs that were 2009 vintage, but I still maintain the oddity of it was the sudden onset after 10 years of that never happening... search me. Fortunately, I left those behind at the other house. Knowing the instruction set is omitted in new hardware is also invaluable information.Just to beat the horse, I want to quote the wiki to make sure I (and subsequent users with this issue) understand -- the wiki states in pertinent part: You don't have any programs that use Control for a device and then send a Scene command to a scene which includes the same physical device. So different buttons from the same KPL are considered one device Don't Use a Control for a device which is already a Controller for some Scene and then have the program send other INSTEON commands to other devices/scenes. This basically causes two or more events arrive at the PLM at the same time Now, I read this to mean, by way of example, that a program shouldn't turn ON a device, then also turn ON a scene with the same device as a member. The qualification statement does confuse me, however - but I believe it means that if you have a KPL, you can't turn on the load with a command, then turn on a scene which has, as a member of the scene, one of the KPL's buttons. I'm pretty sure I've done this before, and it severely hampers utility if you're verbotten to utilize the same physical switch for two different reasons - can this be mitigated by calling a second program to change the scene? The second forbidden action is more confusing - can anyone offer a real world example of what this means? -N

I recently encountered something I couldn't reproduce or explain, figured it may be worth noting. So on restoring the ISY from a backup, I've noted, and in the various materials here have read, that at the end of the restoration, the Console should prompt to restore network settings if they are disparate from that which is stored in the ISY. On the backup of my old house (taken under 4.7.3), a restore does just that. However, I started anew, and have noted that none of my new backups (under 4.7.3, 4.7.5, 4.8, 4.9, or 5.3) ask for that at the end. I have tried this sequence of restoration of both statically set and dynamically configured ISYs, with various firmware versions, and keep coming up with the same thing - the backup I took 18 months ago will prompt for network restoration on any ISY, any firmware, but my recent backup never asks. I've noted the location data doesn't seem to always restore, either... Are there times when parts of backups just aren't taken? -N

...and I should have added that I have come up with this solution, I just don't think it's very elegant... but it does seem to work without adverse effects... Scene UD-Den Fan - [ID 0xxx][Parent 0xxx] If Status 'Den / Den Fan*' is Off Then Set Scene 'Den / Den Fan (MW)' Off Else Set Scene 'Den / Den Fan (MW)' Fade Up Set Scene 'Den / Den Fan (MW)' Fade Down HOWEVER --- this method does not work on lighting that is dimmable, so it's useless for the problem originally posted... -N

Hey All, So we all know that when you have multiple switches, KPL buttons, etc., as members of a scene, and you press any of the members' buttons (assuming all are CONTROLLERS) of the scene, that the remaining members will update with the correct status, whether that be the rocker switches' status bars, or a KPL button light, etc. We also know that if you use the ISY, or Agave, or REST or what have you, to control the load-bearing DEVICE versus the SCENE, the remaining members of the scene will NOT update, and thus not reflect the true/current status of the load being called upon. The solution, of course, is to control the SCENE in the ISY versus the load-controlling switch, which is all well and good, however there are some instances where things like a Lamplinc or other non-updating module can cause issues if controlled locally, or, particularly in my instance, if controlled by Google Home - causing the device to respond appropriately, but the remaining members to not reflect the correct and current status, as outlined above. Yes, you can have Google Home control the SCENE versus the DEVICE, but then the device won't show up on your Google Home Hubs or in the Assistant app as a device at all - just a phantom that you can control by voice, but no other way. (at least in my experience) Real world example and current problem: Among others, I have a Living Room string of 8 can lights on a 5-way circuit, with 4 KPLs all having a single button set to control the load. If I configure in the portal for Google Home to control the SCENE, versus the load-controlling DEVICE, voice commands are fine and all works correctly, but there is no visual presence in the Google Home app or in display devices like the Google Home Hub (now Nest Hub?) that show the device so you can touch versus speak commands. Conversely, if I add it as a singular DEVICE in the portal, it shows (annoyingly in all lower case in abject defiance of my grammatically correct entry, but that's another matter) up in the list, but manipulation of the device doesn't update the scene, so 3 of the four KPLs show the incorrect status. In years past, I simply had an updating program that would watch for status changes and update the KPL every so often, which worked well enough, but in this installation, there are far too many of these instances to be practical, and I feel doing so would be too taxing on the ISY to continually scan for changes, and likely cause sluggishness elsewhere. So has anyone come up with a clever way around this? I can just monitor the status of the switch in a program, and when the status changes from OFF to ON, or vice versa, I can activate the scene or deactivate it, but that kills any dimming control, because activating the scene goes to the pre-determined on rate, which results in, for example, the light turning on to 20% as I ask, then ramping the rest of the way to the scene's set 70%. I can manually program a watch program for each scene, but I was hoping for something that was simpler - and simply querying the scene doesn't update the members as I'd hoped. Any ideas? I searched for this but found nothing on point -- if it's there, kindly point me that way. Regards, -N

By way of an inconclusive update here, I sold the house in question and moved away. Prior to the move, I had simply unplugged the ISY, leaving the PLM and all switches in place. The issues vanished, and I never again had the phantom operations occur. Thus, something was afoot in the ISY, or something was triggering the ISY to go bonkers. I took the offending hardware and have employed it in a new location, wiped clean and started from scratch, taking care to factory reset every single of my 100+ Insteon devices before programming the first one. So far, so good. -N

So in terms of an update, I ignored the advice here to "reset" all my Insteon devices in order to clear potential X10 addresses. I let the problem linger, just to see what would happen, because statistically, that just didn't resonate with me. I still would notice periodically a light would go on or off erratically, but then, as if a big "screw you" from my house, at 330AM one night, all 5 garage doors opened on their own, every light, every device in the house turned on, and scared the ever-living crap out of me and my wife. Since then, these behaviors happens every so often, now at least once a day it seems, whereby either every device is triggered on, or off, and is accompanied by my thermostats referring to a different program as well. Sometimes it's everything, sometimes it just shuts off my water, but frequently enough, everything is turned ON or OFF, and thermostats and all other modules are included in the fracas. I see nothing in the log that looks out of the ordinary, and I've changed no programming recently. Something else is clearly afoot, but I'm not sure how to track it. I'm moving soon, so I may just light all this insteon stuff on fire and find something else to use, because I'm really not interested in chasing phantoms through the dozens of devices I have, and this type of malfunction is not only inconvenient, but harrowing. It would certainly seem to point to the ISY as the culprit, as the chances of EVERY device being triggered by something else seems HIGHLY unlikely, but as of now, I don't know where to look. -N

Is there any way to ascertain if a device has an X10 address without assigning such? Do you happen to know if a Filterlinc would filter X10 "noise"? -N

I meant the *notion* that the capability would be touted, advertised, sold, etc., but then deemed somehow unfit. I cast no stones at another forum member, I promise you. While I understand your premise, so long as the opener remains "code compliant" I would imagine finding another way to push the button would not affect that compliance. But, I'm sure if you're stating that, you've read something that some legislator was paid to add to something to make life more difficult! None of your solutions effectively replace it, so I'm all ears on this Z-wave solution - have a name or a link? I won't be doing it on this house (7 overhead doors and I'm not about to walk those back) but may on my next house. That's friggin' cheeky!!! -N

Well, I would tend to agree, but when the PLM is in the wall and not on the UPS where it was having the issues, the X10 commands no longer showed up. Moreover, due to the extremely unlikely happenstance that two IOLincs manufactured months if not years apart would both have an identical and errant X10 address, I'm having trouble thinking that is the issue. Add to that the now third unit that randomly went off without a PLM connected, and, well... Funny thing is, I tried using some old X10 devices at some point and they wouldn't work in my house -- at all. Too much racket and interference to use them at all, so that somehow they could be receiving X10 commands when X10 modules themselves wouldn't work is ... laughable? I don't have a word for that, LOL. Your indication that noise can't be misconstrued is well taken and what I thought to be the case. I guess I just wanted some validation on that issue before moving further down that rabbit hole, because then SOMETHING is issuing an Insteon command... without a PLM attached, the question is what? Thanks! -N

The UPS is quite old; which is why it doesn't filter much and worked with the PLM, I plan to put the entire shebang behind the Filterlinc when I get it. You may be correct, but given that unplugging the DVR prevented the switches from strobing out and so on, I'm led to believe it has something to do with that... When the FL comes in, I'll check that out, too. Thank you! -N

I actually had just read some posts on that issue. Because the IOLincs are BOTH responding and happen to be from two different vendors and different vintages, it seems highly unlikely, and because ISY can't manipulate that bit of data, there's no easy way to determine if they have an address without blanking them, which seems unnecessary considering the foregoing. I will say that even with the PLM unplugged I watch another switch turn itself off the other day, so there's definitely something going on... As to the ALL OFF bit - they are both IOLinc .41, which I think is pretty current, but maybe. That's not something with which I'm familiar. Thank you for the ideas. -N

Certainly, and your points are well taken, but my concern lay mostly with the apparent much-less-than-I-thought precise nature of the comm to Insteon devices. To your point about "security" or "mission critical" purposes, your point is well taken, however -- the ISY is tightly integrated with my ELK (by design), and Smarthome sells a kit specifically for a garage door by the boatload, which invariably houses things of "security" import, so to say we are expected not to use it for such tasks is cheeky at best. -N

Yes, I have to because Smarthome's stupid kit came with the wrong (IMO) NO vs NC contact switch. Regardless, that fails to address how an Insteon module (or two, in this case) can spontaneously flip themselves. The IOLinc for the Water Valve isn't reversed... Also bears noting that after unplugging the PLM, I had an Insteon switch turn itself off that is a member of no scenes as I sat in the room. ??? Again, am I wrong in thinking that an Insteon device has to be identified by unit ID and a command? How could noise be misinterpreted as such?!? Thanks for your input. -N

Long post, sorry, but here goes: Insteon Setup ISY-994, migrated from 99 years ago. 9-year old install. Original PLM (single band) that was obtained with ISY-99 purchase. Never had issues. Against advice, the PLM has been plugged into an old UPS with limited filtering, and has worked just fine, reaching all but perhaps one or two modules reliably. I kept this on the UPS so power to my ISY wouldn't go out, forcing a reboot, on every brownout before my generator kicked on after delay. Again, hadn't been an issue, but I do understand why it's inadvisable. So now, 9 years later, I suddenly (overnight) see the light on my PLM flashing constantly, and it can no longer communicate with most of my modules. I have added nothing of note, anywhere that I can think of in the house, besides changing a hard drive in my CCTV DVR on which it shares an outlet. I unplug the PLM from the UPS, and plug it into the wall and the flashing subsides, but I still cannot get reliable communication. I now assume the PLM is deceased or diseased. I order a new dual-band version, plug it in, and comm errors persist on the UPS, (no flashing, but I don't think the LED serves the same function here) so I plug it directly into the wall and it still has trouble, but does somewhat better. I try it at various locations near my panels, on circuits with NOTHING else on them, all to no appreciable difference, still nowhere near as reliable as in the previous 3,285 days. Of note, when plugged in the PLM near the DVR and I look at the comm log, I see tons of repeated X10 (I use nothing on J10 or much of any X10 at all, really); so I assumed a noise issue, and have ordered a Filterlinc. While I've been waiting for it to arrive, on two occasions, I have had the following, VERY TROUBLING issue -- one of my garage doors opens itself, (an IOLinc) and my water control valve shuts off. Both of these devices are on the only circuits (and a separate panel) that are near to ones that have had some comm trouble in the past, but nothing like this. CLEARLY I can no longer trust Insteon to keep my house safe now with the ISY -- my garages lead straight inside -- and have unplugged the PLM indefinitely awaiting some solution. The logs show NO indication of anything firing off those two modules near those times. So what gives? I thought Insteon was far too particular on addresses and such to have some oddball noise actually trigger devices? It seems infinitesimally possible that two modules could fail in the same fashion at the same time, so what can this be? Is my ISY bad? Sending phantom signals to my PLM and logging nothing? Seems unlikely, but I have exhausted my searching and troubleshooting. I love my ISY dearly, but this thing's going straight into the trash if it's going to expose my garage to thieves and intruders. Missed and unreliable signals are one thing; opening my family to the world without my consent is bull****. What could I be missing here? Again, the logs show NOTHING related to these modules, except "ERROR 0" or "ERROR 1" when polling for status... Thanks in advance for any insight. -N

Just wanted to thank you for taking the time to do this write-up. I had been using more primitive means (curl) via tasker and while it got the job done, your routines here prove to tickle my inner OCD. It's also helped me to refine my routines for using my smartwatch to control my home, and receive status of modules as well so that I'm not just "toggling" in the dark. Thanks again, -N

Why would this matter ? It's been a while but I had insteon devices before I had my ISY and when I installed that, it discovered existing scenes... -N

They are all state variables.

So I recently tried to pare down my lines of code in the ISY, and combined a few things into single programs versus more. Evidently I should have left it alone, but I need understand the WHY of my failure... I know that if a THEN or ELSE statement contains a WAIT and the conditions change during the WAIT, it changes the evaluation, however, in my simple program, the state doesn't change, the program still shows "TRUE" yet my variable doesn't change and programs dependent on that variable don't fire. WHY? My program: If Elk Area 'The xxx Estate' 'Armed State' is Armed Away Then Wait 8 minutes $House_Occupied = 0 $Night_Mode = 0 Else - No Actions - (To add one, press 'Action') The purpose of this (not that it matters) is because I don't want my HVAC settings going up and down over and over if I leave, then run back up the stairs to get something and have to disarm/arm the system in quick succession, as well as leaving lights on until I'm well gone. -N

I'm not sure I follow -- "previous information"? In any event, here's the Event viewer after my programs runs and tries to set the brightness for 8 Switches: Thu 02/07/2013 07:53:20 PM : [ Time] 19:53:22 0(0) Thu 02/07/2013 07:53:20 PM : [iNST-TX-I1 ] 02 62 14 D7 F1 0F 11 FF Thu 02/07/2013 07:53:21 PM : [iNST-ACK ] 02 62 14.D7.F1 0F 11 FF 06 LTONRR (FF) Thu 02/07/2013 07:53:21 PM : [iNST-SRX ] 02 50 14.D7.F1 12.9F.81 2B 11 FF LTONRR (FF) Thu 02/07/2013 07:53:21 PM : [std-Direct Ack] 14.D7.F1-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 02/07/2013 07:53:23 PM : [ 14 D7 F1 1] ST 255 Thu 02/07/2013 07:53:23 PM : [iNST-TX-I2 ] 02 62 1B 9C B6 1F 2E 00 01 07 37 00 00 00 00 00 00 00 00 00 00 93 Thu 02/07/2013 07:53:23 PM : [iNST-ACK ] 02 62 1B.9C.B6 1F 2E 00 01 07 37 00 00 00 00 00 00 00 00 00 00 93 06 (00) Thu 02/07/2013 07:53:24 PM : [iNST-SRX ] 02 50 1B.9C.B6 12.9F.81 27 2E 00 (00) Thu 02/07/2013 07:53:24 PM : [std-Direct Ack] 1B.9C.B6-->ISY/PLM Group=0, Max Hops=3, Hops Left=1 Thu 02/07/2013 07:53:24 PM : [iNST-TX-I2 ] 02 62 1D 35 5A 1F 2E 00 00 07 7F 00 00 00 00 00 00 00 00 00 00 4C Thu 02/07/2013 07:53:24 PM : [iNST-ACK ] 02 62 1D.35.5A 1F 2E 00 00 07 7F 00 00 00 00 00 00 00 00 00 00 4C 06 (00) Thu 02/07/2013 07:53:25 PM : [iNST-SRX ] 02 50 1D.35.5A 12.9F.81 2B 2E 00 (00) Thu 02/07/2013 07:53:25 PM : [std-Direct Ack] 1D.35.5A-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 02/07/2013 07:53:25 PM : [iNST-TX-I2 ] 02 62 1D 35 BB 1F 2E 00 00 07 7F 00 00 00 00 00 00 00 00 00 00 4C Thu 02/07/2013 07:53:25 PM : [iNST-ACK ] 02 62 1D.35.BB 1F 2E 00 00 07 7F 00 00 00 00 00 00 00 00 00 00 4C 06 (00) Thu 02/07/2013 07:53:26 PM : [iNST-SRX ] 02 50 1D.35.BB 12.9F.81 2B 2E 00 (00) Thu 02/07/2013 07:53:26 PM : [std-Direct Ack] 1D.35.BB-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 02/07/2013 07:53:26 PM : [iNST-TX-I2CS] 02 62 1F B6 D5 1F 2E 00 00 07 7F 00 00 00 00 00 00 00 00 00 00 4C Thu 02/07/2013 07:53:26 PM : [iNST-ACK ] 02 62 1F.B6.D5 1F 2E 00 00 07 7F 00 00 00 00 00 00 00 00 00 00 4C 06 (00) Thu 02/07/2013 07:53:27 PM : [iNST-SRX ] 02 50 1F.B6.D5 12.9F.81 2B 2E 00 (00) Thu 02/07/2013 07:53:27 PM : [std-Direct Ack] 1F.B6.D5-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 02/07/2013 07:53:27 PM : [iNST-TX-I2CS] 02 62 1F B6 DA 1F 2E 00 00 07 7F 00 00 00 00 00 00 00 00 00 00 4C Thu 02/07/2013 07:53:27 PM : [iNST-ACK ] 02 62 1F.B6.DA 1F 2E 00 00 07 7F 00 00 00 00 00 00 00 00 00 00 4C 06 (00) Thu 02/07/2013 07:53:28 PM : [iNST-SRX ] 02 50 1F.B6.DA 12.9F.81 2B 2E 00 (00) Thu 02/07/2013 07:53:28 PM : [std-Direct Ack] 1F.B6.DA-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 02/07/2013 07:53:28 PM : [iNST-TX-I2CS] 02 62 1F BB F7 1F 2E 00 00 07 7F 00 00 00 00 00 00 00 00 00 00 4C Thu 02/07/2013 07:53:28 PM : [iNST-ACK ] 02 62 1F.BB.F7 1F 2E 00 00 07 7F 00 00 00 00 00 00 00 00 00 00 4C 06 (00) Thu 02/07/2013 07:53:28 PM : [iNST-SRX ] 02 50 1F.BB.F7 12.9F.81 2B 2E 00 (00) Thu 02/07/2013 07:53:28 PM : [std-Direct Ack] 1F.BB.F7-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 02/07/2013 07:53:29 PM : [iNST-TX-I2CS] 02 62 20 42 40 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 Thu 02/07/2013 07:53:29 PM : [iNST-ACK ] 02 62 20.42.40 1F 2F 00 00 00 00 00 01 00 00 00 00 00 00 00 00 D0 06 (00) Thu 02/07/2013 07:53:29 PM : [iNST-SRX ] 02 50 20.42.40 12.9F.81 2B 2F 00 (00) Thu 02/07/2013 07:53:29 PM : [std-Direct Ack] 20.42.40-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 02/07/2013 07:53:30 PM : [iNST-ERX ] 02 51 20 42 40 12 9F 81 11 2F 00 00 01 0F FF 20 A2 17 12 9F 81 FF 1F 06 93 Thu 02/07/2013 07:53:30 PM : [Ext-Direct ] 20.42.40-->ISY/PLM Group=0, Max Hops=1, Hops Left=0 Thu 02/07/2013 07:53:30 PM : [iNST-TX-I2CS] 02 62 20 42 40 1F 2E 00 01 07 7F 00 00 00 00 00 00 00 00 00 00 4B Thu 02/07/2013 07:53:30 PM : [iNST-ACK ] 02 62 20.42.40 1F 2E 00 01 07 7F 00 00 00 00 00 00 00 00 00 00 4B 06 (00) Thu 02/07/2013 07:53:30 PM : [iNST-SRX ] 02 50 20.42.40 12.9F.81 2B 2E 00 (00) Thu 02/07/2013 07:53:30 PM : [std-Direct Ack] 20.42.40-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Let me know if you need anything further. Many thanks, Neil

Howdy: So from what I can see the LED brightness setting is somewhat of a mystery. I sought to program something to soften the brightness of these LEDs at night, and bring them back up to full brightness in the morning. Simple enough, but several (new) switches don't seem to want to respond. What I find particularly curious is that the program seems to "know" the difference between those switches that use a % (1-100) and those who use this oddball 15/7 scale for on/off, HOWEVER, when trying to set the brightness on my 2487S v.41 (KPL Relay) the programming suggests it's a value of 1-100; but if I click "LED Brightness" in the interface, I get the "on / off" style of input. Am I missing something? Probably yes, but please do point out my folly! -N