Jump to content
View in the app

A better way to browse. Learn more.

Universal Devices Forum

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

IndyMike

Members
  • Joined

  • Last visited

  1. Thanks, that produced a spontaneous laugh. I needed that today.
  2. Update - the app note I posted above is a bit misleading. It is in fact what the older Insteon supplies were "modeled" after. However the Insteon version regulated at 30V (not 5v as is the App note). The attached schematic was developed by jbauer back in 2006. As noted, the schematic is not complete. I found one of my malfunctioning ICON relay units from 2006 (photo's below). I had noted that the unit "cycled" when I pulled it. Unit powered up OK without a load. I disassembled and verified the supply regulated @30V as jbauer had documented. My unit had an additional MOV (SDS 201KD07) across the power input (201V threshold). The C2 470u cap appeared to be in good condition as did the D1 30V zener diode. C1 is the large brown (Mica?) cap. I would not expect this to degrade.
  3. Your 3 way switches are "virtual", meaning that only one is actually connected to the load. The other switch simply communicates with the load connected switch to turn your lights on. Bottom line, you only "have" to replace the load connected switch. I3, relay, your choice. .... Or you could swap your current dimmers to see if the triac is dying on the current one connected to the load. I have a number of dimmers that have dead triac outputs - just use them for communicating "ON/OFF" commands to other devices.
  4. Now that's an oldie. Not necessarily a goodie. I didn't realize that Smartlabs was making the Togglelinc back in '06. Insteon devices from that time frame had power supplies based on a Microchip App Note 954 located here: https://ww1.microchip.com/downloads/en/appnotes/00954a.pdf They had a habit of burning up the filter cap/zener due to powerline voltages/spikes. Another issue was with the micro switch contacts themselves. Since the device is a relay switch, I'd guess that the 470uF cap (c2??) is breaking down (power supply drop out). You could open and inspect, but to be honest, these devices are probably at the end of their useful life. The relay units are not bad to open up (no Triac soldered to the heat sink). I still have a number in service, but when they die, will retire them. The good news is that you apparently have very well regulated power as well as rather "clean" powerlines. Later devices incorporated dual band as well as additional simulcasting improvements.
  5. @brockp , it appears that Houselinc is still available here: https://support.insteon.com/support-knowledgebase/2016/6/1/houselinc-windows HouseLinc is a PC based interface for Insteon control. It was the forerunner of Smartlabs Hub based system. I still use Houselinc for it's diagnostic/signaling capabilities. I have it setup on a Windows 11 mini PC with a USB to serial adapter to the PLM. The following was a test that I ran after having issues to a new refrigerator install. Houselinc ran 1000 tests on 17 different devices and rolled up the success %. I had "Disable PLM Retry" selected and "Hops" set to 2, so this was similar to a standard ISY scene (no retries, HOPS=3). You could certainly use this to give your questionable PLM's a workout. 1 word of caution - using Houselinc to link to existing devices will alter their link tables (without the ISY's knowledge). Make sure to use the ISY to restore the Link tables after testing.
  6. @someguy , now that I've re-read the post, you are probably correct about "Instagram" being a typo. You might be surprised to learn that there is an Instagram add-on for Home Assistant... There's a lot of conflicting information here. You're symptoms are following the "random on" events that have been attributed to communication collisions or PLM to EISY serial errors (pointed out by @kclenden ). The Event log that you provided earlier did NOT show any PLM to EISY serial errors that I could find. @kclenden is far more experienced at screening for these. I would welcome his input on the issue. Questions and things to try: Your newer devices should not be susceptible to an all-on command from the PLM. Please verify that this is true by executing an ALL-ON from the MY Lighting Admin console and then physically which devices turn on. Devices like the IOLinc were not updated the last I checked. When you find a light on unexpectedly, does the ISY have knowledge of the Light State? If it does it could point to a Rest command telling the ISY to turn devices on (the ISY knows it sent an on command in response to a Rest request). Try disconnecting the ISY from the Lan to interrupt Rest communication. You'll likely need to leave the system disconnected over a couple of nights to verify any improvement. Manually linked devices can activate devices outside of the ISY's knowledge. I've had this happen previously when visitors were in the house and accidently put devices into linking mode. Scan the device link tables and restore if necessary. The link table that you provided earlier showed only a link for your PLM. Only your PLM (or another controller) should be able to activate this device. If nothing above has helped eliminate the problem - disconnect your PLM. That should prevent any device direct communication. Check for "other" controllers. In the past I've had HouseLinc running on a separate PLM. A PLM can control your devices even with NO links in the device table (just verified this AM). Make sure you don't have any other controllers capable of issuing device direct commands to Group 0. If things are still acting up, we are down to X10 communication or local power upsets. You've already factory reset some of your devices - that should eliminate any programmed X10 addresses. If you factory reset a device and leave the link table blank (do not restore) the only device that should be able to activate it would be a PLM using a device direct command. An all-on command should NOT turn the device on. If the PLM is disconnected, there shouldn't be any controllers capable of turning the device on. If it does, there's something very next level going on. Please report back your findings for the all-on test.
  7. @someguy , from what I remember, you did not have any Alexa communication in the event viewer file that you provided. You also had only 1 link in your affected device link table (to the PLM). That really doesn't leave many options. Since you do have a PLM link in the device, the PLM (EISY) can still turn on the device. That includes any REST device (alexa and other). You might try disabling (unplugging) your network connection to eliminate external commands. @oberkc mentioned that he has been having issues with Instagram communications - I have no experience with that but it sounds like it could be a player. The other possibility would be an "all-on" event. Your older devices are susceptible. The newer device (71.C2.58) should not be. Not sure what this device is - please post back and confirm. You can test to determine whether your devices respond to the "all-on" command from the admin console. From the "my lighting" tab in the admin console tree, hit the "all-on" button. After activating you'll need to visually inspect for devices that have responded. Newer devices will not respond (command removed). Older devices will respond. Very curious about your 71.C2.58 device.
  8. @BobM99 , to the best of my knowledge you will not receive a "message" from querying X10 devices. There are not many 2-way x10 devices out there. Most devices will not respond to queries. Even if a X10 module is 2-way compatible, the ISY will not generate an error if it does not respond to a query (ISY994 won't generate an error). If you are seeing a "Request Failed" error from the EISY, it's possible that it is not communicating to the PLM. Check the "Tools\Diagnostics\PLM Status" for connection errors. If the PLM is a recent replacement, it's possible that it does not support X10. I've heard that X10 was removed in some newer modules, not sure about the PLM's themselves.
  9. @PapaBear , the fact that this is a new sensor is relevant. It's possible that it's mislabeled or just defective. One curious item is the device address - 45.D1.A2. I have 4 of the MSII's that are already several years old. They all start with the address 4A.xx.xx. Insteon device addresses don't normally decrease on newer units. One last thing to try before we declare the unit "broken" - manual link to another Insteon device. This is just in case you have a misprinted address label on the MSII. I just did this with a LampLinc I had laying around - Place your MSII into link mode by holding the set button for xx seconds Place the device you with to link into link mode. Linking should be almost immediate. Assuming this works, you can find the MSII address in the link table of the device you just linked (use show device links + compare). In the example below the mismatched link is the manual link just added. The 4A.6F.7A is the address of my MSII. Remember to restore your test device to eliminate the manual link.
  10. @jlloyd_UD , please report back your progress. I have to believe there are others similarly affected.
  11. @jlloyd_UD , the last I remember you were able to stop the random on/off activity by unplugging the EISY from the Lan. In my mind that places to problem external to the EISY. Filters, resets, and restores of devices likely will not help. My suggestion at this point would be to: Nuke the Alexa/Portal integration Verify (over days) that the problem has been resolved. Add devices back to the Alexa integration SLOWLY. Unfortunately, I do not know how to accomplish the above nor do I know how much work is involved. Hopefully the forum can help here. If not, I would suggest opening a ticket with UD. While not specifically an EISY problem, I'm sure they could assist in eliminating the integration.
  12. @oberkc , You are correct that it doesn't hurt to try... I just ran both methods and they work equally well with my spare MSII's. That said, I am using an ISY994 whereas @PapaBear is running the EIsy. @GlowingHair , I believe you are referring to hitting the "Node limit" in the standard ISY994 (254 nodes). PapaBear is running the EIsy. I don't know the node limit but believe it to be substantially higher than the ISY994. I don't recall anyone hitting the Eisy limit as yet.
  13. @oberkc , simply two different methods to link. Bottom line is the command shown below that is being executed by the ISY is correct (get Insteon Engine Version). If the MSII hears to command it should respond with an I2 engine version. It is not responding which leaves us with the following options: Device address is incorrect. Possible, although I've never encountered a mis-printed label. There are methods where the device can be manually linked to determine it's address. The device can't hear the PLM because of interference in the area (or PLM can't hear the MSII). Move to a different location and re-try. Faulty MSII (it happens)
  14. @PapaBear , the ISY is trying to contact the MSII. It retries 3x and then times out. Did you happen to try monitoring the Event Viewer while re-connecting power to the MSII? I'm assuming you had the sensor connected previously. You also seem to be getting a lot of activity from the device @14.16.B3. I'm guessing it's a thermostat. That's both good and bad. The thermostat is communicating well with the Insteon network (do know the point of access). The bad may be the traffic it's throwing at the system. You might still try re-locating to a separate room - this will force a different RF access point to the system.
  15. @PapaBear , I've been taking some swings at this and have not been able to reproduce what you are seeing. I've tried different communication modes (I1 vs I2), linking methods, power methods, and device versions. Things seem to just work. Would you mind posting the contents of your Event Viewer when things fail? The following is what I get when I intentionally enter in the device address. The ISY tries 3x to communicate with the device and then times out with the error message. Another possible check - If your MSII has been linked to the PLM previously, it will still contain the PLM address (even after a factory reset). Assuming the PLM still contains your MSII link (hasn't been restored from backup), you will see the MSII address pop up in the event viewer when you apply power. The communication below is from my MSII @4A.6F.7A telling the PLM that it has turned on when power is applied. Use this to quadruple check your device address (labels do get old and disfigured). The following is the method that I've settled on for linking the MSII's. Using "Auto Discover" is easier that scrolling to the bottom of the device list, and it populates the Sensor Version (v.46 below). If none of this appears to work, it is possible you simply have a defective MSII or RF Interference in the area around your PLM. You could try linking the sensor away from the PLM but close to a different RF repeater. The MSII's are 915 MHz and it's possible that you would have other devices in this range. That's not a problem that I've encountered. It is also possible that you have device(s) spamming the powerline and disrupting things while you're trying to add the device. The event monitor should show evidence if this it the case.

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.