paulbates

Pushover is mentioned and the post is under ISY994. But also email is mentioned. And iPhone. I don't understand all the links and what the chain looks like. Provide the technical details... If its pushover on a 994i than likely you're using network resources to create the notification, show that if so. If not, what facility are you using for pushover notifications?

Zigbee and Thread traffics share Physical and MAC layers and can coexist over-the-air. However at a network and App layer, they are mutually unintelligible. One does not get you the other. Zigbee does not use IPV6

No better way. The performance might be felt only when managing the scene.. adding, modifying or removing scene members. Especially if any of them are wireless sensors, which doesn't sound like the case. The scene itself is a single group # programmed into all the scene members. They all wait for that one group number so, no, run time performance is not a factor. What can be a factor is that the PLM can handle 1000 links and large scenes can affect the approaching or exceeding that. No sure I'm following. Each new controller in a scene activates the scene... that's it. A controller activating the scene tells each group member to do whatever it's been told to do for that scene. A follow up is that scenes are a one time, fire-and-forget Insteon moment. Large scenes increase the odds that one or more member doesn't hear it.

Look under the config tab in iox, there's a checkbox option to turn Insteon capability on or off. What you're describing sounds like the symptom of it being unchecked

There is a Home Assistant Integration for UDI products.. Think of it sort of as what a plugin is to eisy. You install the "Universal Devices ISY/IoX" integreaton on your local Home Assistant server on you local network, and configure it to log into your ISY on your local network. IMO the Home Assistant built in notifications are very unsophisticated, good for debugging programs, that kind of thing. The don't seem to be kept for long after you view them. I think UDM notifications are more sophisticated / better. For Pushover, another option if you have a policy / eisy, is to get the paid for notification server plugin from the plugin store, it works very well and has options galore. This gives details on how "how to"

That is a no regret solution. It takes a little to set it up, especially the extremely long Network Resource links. But once you work through those it's a solid, fast solution that is relatively easy to change and expand to new notices. Its additional advantages are what Pushover calls Apps. What they call Apps is actually folders, you can sort your notifications in different folders and each group has a different notification sound and a presence. I have house notices = report kinds of things like sump pump daily activity.. no notification, just there to review. I have another "App" for Battery levels, and one for House Alerts for critical things that screams. Another advantage is that other non-eisy things like firmware upgrades for my router. Those come through an Pushover RSS feed from Zapier. There are a ton of alternative inputs

I used Insteon sirens, iolincs, motion and leak detectors successfully with eisy and they worked as they did on ISY. I assume you're talking about the First Alert Smoke Bridge? It's not sold anymore but see no reason UDI would choose to remove an Insteon device that's been integrated for years. However, the concern to have is that First Alert phased out the One Link designation for the RF used by the smoke sensors compatible with the Insteon Smoke Bridge years ago. I owned the smoke bridge well over 10 years ago and the compatible First Alert devices were replaced with something else as they were EOL. Is the Insteon Smoke Bridge compatible with newer First Alert wireless/rf products??

The portal remains as the tool for integrating google home / Alexa. Its pointing the automations at the eisy vs the ISY.

yeh I was going to comment.. Unless it's a keypad, it's often easier to set up new switch, move it into existing scenes and remove old from those scenes. Programs are the trick, if you know that its less of a fishing expedition

I think it's time to open a ticket. A lot of these migrations go well but sometimes they can go sideways. UDI tends to be very responsive.

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.