paulbates

Ok. I wouldn't feel dumb, the migration is a significant upgrade and a lot has changed. The next step would going into IOX, going to Tools/Diagnostics/Event Viewer. At the bottom of event viewer is a box for setting the level, set it to 3. Then go through the moves of what you are trying to do, event viewer will capture the Insteon protocol at a detailed level. Post the results back here. I'm not the best at decyphering those but there are members here who are and will likely review it and come to a conclusion.

In iox, pick one of the keypads, right click and pick "Restore Device". Give it some time as keypads can have a lot of scene programming. Maybe pick one that is the least complex in terms of scenes. Test that on again and see if it fixed it.

To add a note to Guy's suggestion, the original switch has to be moved out of its folder to the root area of the device tree or it wont work. Once replaced (if it works), the new switch can be dragged back to the original folder

Which PLM USB or Serial. If serial, did you use UDI's kit for connecting to eisy?

Try it again Shut eisy down Pull PLM out of the wall, count 10 seconds, plug back in Restart eisy

In iox, go to Tools, diagnostics PLM info. Does it say connected? If no, try restarting eisy, then check that again

Follow this procedure: 1) Pull out ToggleLinc’s Set button to create an air gap. 2) Wait 10 seconds. 3) Push in Set button and hold it. Do not let go. ToggleLinc will begin to emit a long beep. 4) When beep stops, release Set button. A few seconds will pass. ToggleLinc will double-beep. LEDs will return to normal brightness. The connected load will turn on. Then go in iox and restore device to put any scenes back

Yeh I wouldn't try 50 in one move. The amount of insteon traffics could be significant and who know how it would end.

How many scene members? Here's how I've done it for Insteon only scenes: You can create a scene #2 and click/drag it in iox near scene #1 on the list. Hold control and click on each scene member in scene #1.. (I think you can click the first scene member, the press shift and click the last but it's been a while). After the scenes are all selected click on any one of the highlighted scene members and drag them as a selected group on top of scene #2... it should copy/populate.. might take a few minutes based on how many members as the scenes are programmed into devices. You'll want to click through the new copy and make sure controller / responder roles copies correctly

To be fair to UDI (and others), matter remains in a state of flux. As an example, the specifications for matter scenes are just starting to surface; today's matter products with scene capability are proprietary and candidly lacking. Different device manufacturers are adding their own tweaks and special sauce to matter/thread device settings, which also aren't standard across brands Matter/Thread is improving and there is progress, yet a moving target and hard for controller manufacturers/integrators like UDI to hit day-to-day. The approach you mention for connecting to a large player's hub like apple, google, etc, is how it works now.

Insteon battery devices can get flaky if the battery dies. Factory resetting them generally helps. Hard to say because yours is pretty old. You'll need to put it in linking mode afterwards and "Restore Device" from iox. I don't think it will hurt the remote, but if its that old and factor resetting it causes problems, it's time to replace it This is the manual for the newer one, see if the procedure will work Insteon SupportMini Remote (Wireless Switch) - Owner's ManualDownload PDF

I have a really old ring door bell battery in this condition. Takes hours to charge it up, or appears charged enough to work. But it keeps working for a number of months including video recording activities. It's not landfill worthy yet so I keep recharging it, waiting until its a functionality problem or drains in a few weeks. Depending how often the mini remote is used, eg occasionally or more often daily, you try brian's approach, see how long you can get away with using it normally, until the recharging becomes annoying.

This is kind of generic advice, but I have a number of PS01 i3 paddles, a couple of them needed to be factory reset to link and behave properly. Also, some had unexpected things turned on (or not turned on) in their settings, or their separate Flags node setting. One head scratcher was the Flag for turning wireless off, it was enabled for my furthest away switch so it wasn't communicating on rf.. took a while to figure out what was going on. I almost returned it. They've all been fine for several years since working around this kind of thing. Take a look at all settings and flags. If those look ok, factory reset it and try again.

In iox you can get the same capability with 3 variables and an iox program to convert the data real-time to gallons for use in your programs that need to work in gallons. I've done something similar with yolink 8003 temp/humidity sensors to track humidity rise for a bathroom fan. Liters to Gallons program - provides a state variable for programs in gallons. It catches changes from yolink sensor real-time and assigns to state variable for programs to use. Read all of this and see the assumption in the notes and test it first. If liters_variable <> yolink-node-liters (Catch the sensor changing its value) Then gallons_variable_local = yolink-node-liters (capture the current liters from sensor) gallons_variable_local *= 0.264172 (convert to gallons) gallons_variable = gallons_variable_local (separate var so conversion does not confuse your programs) liters_variable = yolink-node-liters (reset liters value, its last so the program doesn't stop executing) Assumption: Based on my experience, yolink sensor data changes can be minutes or more apart. If its updating every few seconds, this program is not a good idea, but i find that unlikely Run it for a while and watch the gallons variable to make sure it's doing the right thing. With the program running correctly, use the gallons_variable state variable to trigger the automations instead of the node until the plugin gets updated. About the variables: liters_variable - must be state - tracks changes from the yolink node. Set precision to equal to the node gallons_variable_local - can be int or state - handles conversion to gallons without affecting programs gallons_variable - must be state - ready to use gallons value. Use this for gallons for your actual application

I had some flickering in a few places (not PW3 related) that was loosely associated with Insteon powerline traffic affecting dimmers. I originally put dimmers in those locations "just because", and the reality is that in several years they've never been dimmed. The imbedded micro module dimmers are affected the most. I replaced the micro dimmers with on/offs, and in one room set the i3 paddles to relay mode that stopped it. This may not be the ideal solution for everyone, but worked for me. No more WAF issues.

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