Yes... and I'm surprised that it worked for you in the first place. The reason it got disabled it because of the issues. BTW, existing setups won't instantly break, but UI will no longer allow sharing pushover devices over hub mesh.
Hmm; I pay for Pushover Android and Desktop licenses, maybe that has/had something to do with it? Regardless, I'm fine with setting up a second Pushover instance over on the second hub if that's the right way to do it now?
@gopher.ny does the issue also impact the Twilio driver too? I haven’t setup Hubmesh with my Twilio devices but wanted to call this out in case it’s also impacted. Curious what the underlying issue was with Pushover sharing across hubs. I am happy to test this if you can provide more details on the underlying issue.
I have no idea. The purpose of hub mesh is sharing physical devices that cannot otherwise be connected to multiple hubs. Using hub mesh for connected services is kinda contrived, IMO. If an identical connected device can be set up on another hub, that's the way to go about it. Sharing connected device over hub mesh introduces multiple potential failure points and provides (as far as I can tell) no additional functionality.
That said, if you run into specific issue, ping me. Hub mesh implementation hasn't exactly been bug free.
I have multiple hubs and early on discovered that Lutron Integration worked astonishingly well with an individual instance per hub. I grinned for days when I found that a Pico button push could be used on each hub simultaneously.
That lead directly to me deploying Pushover the same way, an instance per hub, including an instance in Node-Red as well.
Once that "devices that can't be connected to multiple hubs" idea entered my brain, it got easier to deploy a resilient system.
I've shared this drawing before, but when I initially started experimenting with Node-Red, I connected it only to my "coordinator hub". Now it's connected to every hub individually as it should be.