Hey @nate - thank you for that - I did run into that issue (pointing to ST and HE) as part of migration, and I believe I have them all deleted from ST, and the API endpoints are only pointing to the HE device (in my case, http://192.168.1.7/apps/api/104, and HE has a static IP reservation). Is there any other place to check besides the device status page for that?
I am testing it presently to see if I can get them to quit responding in the app, and I reproduced the issue by rebooting the hub (again, all boards available on network, but HE quit updating status).
Note that "shutdown Hub" does not create this issue - if I "shutdown" the hub, and then power-cycle it, things work OK (as long as they were working prior to that - it will not fix the issue once they quit reporting in). It's the reboot option that seems to repro the issue reliably.
So hopefully that is helpful - if you want logs/versions/whatever, please let me know. One more thing I just noticed in testing. Using a PC, I rebooted HE to repro issue, then tested (didn't work), did a "shutdown", and power-cycled. Tested (didn't work), so on the PC, I went to apps/Panel 2 (where the door is at I have been testing with) - instead of opening right away, it stayed on a screen that said "Connecting to Konnected Service Manager" for much longer than normal, so while it was coming up, I carried my tablet to the door; part way there, I saw the "current states" update from Closed to Open and then Closed again - almost like the status had been queued, and didn't get read again until i opened the app in HE. It now works again - difference is that it seems to only have had to load the Konnected Service Manager - I didn't have to click Next/Done for it to start working again.
Secondly, though, any thoughts on something I could put in place to monitor for this happening in the future?