paulbates

When following the PLM replacement procedure, you'll want to pick a backup from before these problems happened if possible and restore it before connecting and performing a 'Restore Modem' from iox. The records in the current PLM have likely been polluted, and there's a chance that's what goes back to the new PLM. It can be fixed normally, but better not to start off on the wrong foot The link is from an older unit, but the basics are the same other than the backup restore suggested here

It manifests in weird behavior. A sign is if unplugging and replugging the PLM helps temporarily, but eventually starts having problems. Looking at the links count is a place to start.

There are settings way down in the stat menus for disabling/enabling the local api... my money's on that one.

A couple of things The date code is 2016, I think that was in the bad capacitor days, and having said that a long time ago in PLM years My experience with some older Insteon devices is that they will work untouched but then lose it when trying to reconfigure them Another thing is when I first set up my eisy, the eisy needed to be restarted a time or 2 before showing PLM connected. That's important because the PLM connected only comes on eisy restart, not unplug replug. You can try that

FWIW I had several different color touch stats going back over 10 years including the T7850s I had these stats in the nodelink days, and query/status is the 'bread and butter' of the api. I used the browser a lot to discover things and debug problems. If that's not working from a browser, I don't see pg3 having luck They can have pin settings, is that being used or maybe set unintentionally?

While retries aren't a bad thing for powerline only devices like iolincs, I would only add it in a mostly working steady state where a few occasional commands are not making it The diagnostic path would be best: Open iox Tools/Diagnostics/Event Viewer At the bottom of the event viewer, click level 3 device communications Leave it running and wait for it to happen again. When it does, get a copy of the iox log for that time and the contents of the event viewer and post back here There's members here better than me at walking those and identifying root cause(s) but this is the place to start

If they're bulbs, remove them and re-test that way. Dimming the bulbs to a certain percentage could possibly create noise. Temporarily try a different, higher percentage to see what the results are

When things turn on and not back off, consistently, that can mean that the load is creating noise. The noise isn't there when off, you turn it on-- noise and it can't 'hear; any more. Scenes are particularly vulnerable as there is not confirm/retransmit. What are the loads, are they the same?

If it's workable, I'd pull the plug on the MS for the approximate amount of time it takes the ALL ON event to happen and see if it happens again. I had an MS 2 in my garage for a couple of years, on power not batteries. Worked perfectly during that time, ... until recently.... It recently started having problems and I tried all of the suggestions I gave above and had problems changing parameters such that they would stick. It was sending A LOT of messages for its motion sense. Factory resetting, etc had no effect so I replaced it with something else.

Insteon MS and other Insteon wireless devices are near the top of the instigators list. Is the MS on batteries? In addition to the restore device suggestion, you can try factory resetting it and adding new batteries and then restore device. My experience is that lower the battery voltage gets on the MS, the more un predictable the behavior gets. I eventually put my MSs on a spring/fall battery rotation, ignoring the battery node from the device... and factory resetting them / restore device every time

Did you make a recent move to eisy? What color is the programs icon if you look at the program's status... is it yellow. If it's yellow, it might be due to migration, and you need to go into the program, re-pick the right item to replace undefined and resave it

Adding to the speculation, it could be argued there'll be another eisy family product in the future with the necessary HW. Having said that, AI code can be written server side on existing platforms like Claude, today.

Back in the portal, where you changed having an Alexa spoken call a scene instead of a switch, you can change it from calling a scene to calling a program, Having said that, it's unclear, from a diagnostic point of view, how that will affect the problem other than trying it. On the one hand, I had your described kind of problem with the alexa in my ecobee thermostat over a year ago. I used it for a year where it worked great, and then it was a combination of problems: Either said "hmmm I can't do that" (or something like that)... or act like it did it, and nothing happened. The voice isn't that important to me so I just shut it off. If you follow the kind of procedure @IndyMike suggested in your last post; go to Tools/Diagnotics/Event Viewer and set it to level 3. Repeat the steps that are causing the problem and post The steps you took The output from the event viewer at the same time

Your timing is interesting because these have recently been coming to a head for me as well. My Insteon network is mature and in cleanup / maintenance mode. In fact it's shrinking as all remaining Insteon sensors are migrating to Yolink. It's now dealing with these 2 little leftover problems... And more of a WAF thing.. "why does that flicker sometimes?"... and it bugs me as well. We'll be selling this house in a few years and want to get this solved and move on to other things I just exchanged emails with Insteon about these flickering / flickering on Insteon traffic, and their recommendation is try combinations of the flicker capacitors; that they can help in many cases but sometimes don't do anything. As much as these micro modules are a perfect solution for where they are and what they're doing, it's a mining operation to get them in/out. I don't look forward to one more journey in there.. let alone possibly more fiddling with capacitors that may not do anything. Everything else Insteon in my house works as expected.. so I'm raising the white flag on this one and replacing the micro dimmers with micro on-offs. I originally made these rooms dimmers "just cuz" and in several years of use in these active living areas, they have never been dimmed in any setting other than me testing it during installation. In other areas we do dim Insteon n-ways and it works great but not at these locations.

I have 2 of these. Each powering one LED can recessed light bulbs. They are 5-6 year feit 9w, 75w equivalent, LED can lights. They occasionally get the dreaded traffic flicker. I have a number of i3 paddles, 7 of them are controlling the exact same bulbs in the exact same fixtures, some up to 5 LEDs per switch... no problems. I'm thinking of order the blue/yellow flicker capacitor kit from insteon. I've been avoiding it as both of these will be a mining operation to get out. But given the weather I should get going

My house has a number of recessed LED can lights that are over 6 years old. There are 10 in the kitchen and the loads are split between 2 i3 paddles and micro dimmer module. The one on the micro dimmer module started dying. The existing bulbs are all the older Feit 9 watt warm glow 2700k from Costco. I didn't want to replace the whole room, just the one. My local Lowe's hardware only had things I hadn't heard of, including this Ultitech. It works well: It looks almost identical both in fixture style and lit bulb appearance to the Feits. The group dimming is really accurate and tracks down to the very lowest dim level where it goes out a little early, but that could be blamed on different switch type and the way the load is spread. I never do that anyway. I'm happy with them for $12 vs what Amazon wants for the same Feits

I had this kind of problem in the distant past, it was an old cable drop from the pole/service to the house. The service got flaky sometimes when it was raining. The service provider at the time replaced it and that resolved it. I remember I walked around with him as he checked it out. He remved the connection from the drop to the house... shook it and water came out!

It's not that hard. In the UDI portal where you defined the relationship with the Insteon switch, you move the entry for the switch, and add an entry for the scene instead of the switch. Login to the portal. Tool > Connetivity> Amazon Echo Delete the line for the switch and add the scene

There's a few moving parts here and it's probably best to go through them. (Good brand) Cable modems are not problematic. My arris s33 cable modem about to go into to its 5th year and I've never had to reboot it. If I lose internet, lights on the front tell me that Xfinity is not communicating with the modem, not the modem What brand router do you have? That can be another weak link. In my experience, you get what you pay for with routers. Another complexity is running a VPN. If you have the UDI portal, you can access the eisy without a vpn and without opening ports in your router. Based on what's written, I'm most suspicious of the VPN. How is the VPN endpoint set up in the remote house, what is hosting it?

How old is the unit? I could be that the SD card, where all of the automations are stored, has become unseated or is going bad. Check the below link to docs on this topic. You can first use the docs to find where the sd card is located, take it out (994 unplugged). Rub over the contacts with an eraser, wipe with rubbing alcohol, dry, reinsert and try again. https://wiki.universal-devices.com/ISY-99i/ISY-26_INSTEON:Replacing/Formatting_an_SD_Card

To isolate which it is, you can try temporarily adding a 3rd nearby device to the scene as a responder. Switch the SWL - What happens, does the new device also come on? If the new nearby test device comes on, it's the keypad. Keypads can 'lose their way' after long periods of use. If updating the scene or restore device didn't work, factory reset it and restore device.

It made sense to me, I take it as a band-aid-ish way to get around the triac dimmers causing flickering bulbs when full on. I do have a lot of N-ways, and some never get dimmed so I moved them over to on offs rather than trying this. I've been in the house +3 years, there are a ton of led can lights that continue to work so not replacing. I'm using the paddle PS01, but it has the same flags The head scratcher for me is Disable RF? Why? The problem I've had is that they can come from the factory with that turned on. Of course the first one I ran into is as far away from the panel across the house, as many wire feet as you can get..... with plenty of dual band in the area and it was working flaky. I finally looked the flags to see that turned on. Had my out-of-body experiece, changed it and pressed the button. That was over 2 years ago and its been fine.

Eisy and I think policy allow you to add the newer insteon i3 products. If switches die and/or you want to add i3 devices, their not fully supported in the 994.

To follow up @xlurkr 's caution... Almost everything is triggered, like a garage door that might be on an io-linc, sprinklers, etc The Almost part: In a test I did a couple of years ago, iox ALL ON / ALL OFF buttons did not turn off i3 devices as Insteon removed the ALL ON/OFF response based on the dreaded random occurrences. If you have any of those, they won't respond. I have to assume what you're asking for would call that feature on the buttons of java iox. Depending how much link count is a premium in your PLM, creating a scene with specific participants would be the way to go.

Even with new i3 paddles there can be flicker. Using on/off where dimming is not needed makes the problem go away. We have a master bath where I simplified multiple on off switches with multiple Insteon switches. Dimming is never used, so when they flickered, on/off fixed it. If you have the eisy you could use the new i3 paddles. The advantage of i3 paddle is that you can configure it on-the-fly to dimmer or on/off... it does both.