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