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