paulbates

So what you show there has worked for me and in the past. The new variable in the equation, for me, is Apple. I think they have their own handling for priority alerts? Check the ios settings for the pushover app for critical alerts

When you change the priority, there are new parameters you have to add to the string.. retry = how long in seconds to wait and retry if the message isn't received expire = how long in seconds until pushover gives up &priority=2&retry=60&expire=3600 Both are "academic" in that I can't image what that would prevent. But pushover won't budge until you send them

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.