paulbates

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