paulbates

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

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?