Javi

@sumguy, very sorry for the trouble. We have a few reports of entries and exits happening at the same time. Some of these are due to iOS blocking network, which will be logged in Geofencing Logs as a timeout when iOS allows the app to access network again. We added a hard timeout for these network calls to prevent the request if the network is blocked. However the hard timeout was missing for credential refresh, which should be fixed in 1.1.29. Although it is very possible this is not the issue as is the case with the OP's logs. @tmorse305, The logs do not appear to show any issues with the processing for commands mentioned above. In this case it appears iOS notified the app of both entry and exit at about the same time. There is not much we can do about the timing in this situation, however It is possible the app logged these out of order due to threading. Version 1.1.30 of UD Mobile will lock the thread to try to prevent entry exits becoming out of order if triggered at about the same time.

The node server is getting terminated (Disconnected), and hopefully restarted (Connected) automatically. A good place to look for the an error is the Node Server's log. This may also happen for a short period after firmware upgrade, node server upgrade/install/uninstall or reboot. Being as this is not related to UD Mobile, @Geddy can we move this to PG3 or Sensibo subforum.

I think I have seen a similar issue. The app does not "store" the fence crossing, iOS is pausing network connectivity. The latest version of UD Mobile adds logs to assist with isolating these issue so that we can report these issues to Apple. There was an issue with the last few versions of UD Mobile on iOS which caused background geofencing to be inconsistent which may have caused your issues. Apple also has a history of breaking Geofencing with iOS upgrades, iOS was updated a couple of weeks ago. This could be related to the version (APIs) the apps target or the iOS firmware running on your phone. It is also possible (as evident from the last few versions) that we have an error in the app. We would like this to run as smooth as possible, alas for some users it does not appear this is happening. In order to find issues in UD Mobile or allow us to have enough data to report iOS issues to Apple we need logs. If interested in helping us please follow the recommendations in my previous post then send us the backup (log) file.

Try replacing https with http, http://192.168.1.107:3000, to remove browser security error for local connection

Thanks for opening a new topic. The last few versions of UDM for iOS had Geofencing issues for some users, version 1.1.27 was released Friday Night. This could be the cause of any issues before UD Mobile was updated. iOS automatic app updates usually occur between 0-3 days after release. In the previous post it shows a fence at 100m, please try the smallest fence at 500m, to see if false/entry exist persists. If false entry/exit persists we can look at the logs, if it does not then try slightly decreasing radius until the issue returns. This will show the minimum fence required in your area. Fence accuracy depends on many factors such as cell-tower/wifi density, elevation, and obstructions. Some locations may have accurate readings at 200m and others could be 1000m. My personal experience in a density populated area, 200m works well except in my basement. When my phone is in the basement (obstruction) I will get false entry/exist for anything less than ~1mi. If an entry/exit is missed again please check the logs (Setting-Tab > Geofence > Document Icon at the top) after 1 hour, it is very possible an error is logged. If the error is not self explanatory please send me a Private Message or open a Ticket and attach a copy of the UDM backup file and we can review the logs. Note that attachments to tickets require file to be zipped. Unfortunately iOS does not send UDM WiFi status and UDM cannot request WiFi information when the app is in the background/suspended/not-started. Apple also denied our request to run processes in the background related to Geofencing altogether and we have no other reasons to run background processes. So, unless Apple changes their policies, UDM cannot use WiFi as a trigger or request location itself as UDM does not receive location updates unless iOS notifies UDM of a fence crossing.

Hi @EJones01, I removed your backups and images as they contain sensitive data. Please send to me via Private Message or open a ticket. Backup must be zipped if attaching to ticket.

By default UD Mobile does not request program status at startup. Change this behavior in Settings Tab > Systems > Your System > Program and Variable Settings.

Reboot Polisy

Have you tried rebooting the system?

It appears like you are looking for tabs. I've added to our list although not sure on timeframe. https://github.com/UniversalDevicesInc/UD-Mobile-iOS/issues/90

Hi All, I believe we located an issue in UD Mobile. Version 1.1.25 was released to the App Store and should be live within the next 24 hours.

Please send me a PM with the app's backup and I'll take a look. Alternatively open a ticket and include a zipped copy of the app's backup.

Hi All, I'm looking into the issues, for the most part nothing in the app's Geofencing changed so it may take time to identify the cause. As far as I can tell this started happening on iOS 16.7. Please let me know you have a lower iOS firmware which may help narrow the issue.

The URLs were likely saved by the user. Finder will not find a system which is not on the network (i.e. Portal). The only way portal URLs would be populated is if the user pressed save after manually input a remote url (i.e. Portal). In this case the url is Saved not Found. The same is true if a local url was saved. If using UD Mobile you can try the app's finder to check the url. Go to Settings Tab > Systems > Your System > Local Connection Settings (expand if needed) > press the magnifying glass icon next to Local IP Address to start the finder. Note that UD Mobile only has the numerical Local IP Address, port and path need to be appended in finder, i.e. http://<ipAddress>:<port>/desc or http://192.168.1.99:8080/desc.

Let me know if the missed fences continue. I think they were being missed due to the same crash.

I believe the issue is caused by IoX Finder, not firmware. It should be safe to ignore until fixed.

All, I believe I found the root cause, 1.1.23 was accepted so should be live in production soon. Beta is still awaiting approval from Apple.

Hi @SteveBL, My apologies, I never received notifications as a crash report is not generated. iOS is terminating UDM because the cleanup process is not terminating within 5 seconds. I cannot replicate this on any of my devices. So I'm going to try a few things but can't test solution myself. Please let me know if this persist in the next version 1.1.23

Most favorites can be migrated assuming the node addresses are the same. Go to the existing system's settings from UD Mobile >Settings Tab>Systems> Your System, scroll to the bottom and click clear UUID. If you have local connection settings, set the Local IP Address for the new system. If the app did not force you to select the system from Portal correct the remote url. In Remote Connection Settings click the search icon next to the remote url and select the new system. If using a different portal account delete the portal account from remote from remote connection settings and login to the new account. https://wiki.universal-devices.com/index.php?title=UD_Mobile#Migration

Enable in settings https://wiki.universal-devices.com/index.php?title=UD_Mobile#Program_And_Variable_Settings

Yes. Thanks.

Thanks for trying. At this point our only option is a iPhone System Diagnostic reports. Is there a Jetsam logs at about the same time as the crash Settings > Privacy > Analytics & Improvements > Analytic Data? If there is please send to me. If there is not a Jetsam log, please gather a sysdiagnose. Instructions to generate a sysdiagnose report attached. Then send to me with the exact time of the crash. sysdiagnose_Logging_Instructions.pdf

While the issue could not be replicated, I did observe memory leaks coming from the app's XML Parsers. This may be causing iOS to terminate the app when backgrounded. Let me know if the issue persists in version 1.1.22

All, I've reviewed the Apple's crash reports with user descriptions matching this issue however they are all empty and have no logs. If anyone has a system where this happens everytime, or very frequently, and is willing to allow remote diagnostic please let me know. If interested please open a ticket or send me a Private Message. Include a description on how to replicate, system UUID, and a UD Mobile Backup (Backup must be zipped to attach to ticket). I will then give instructions to approve remote diagnostic after we link to our diagnostic portal. Diagnostic approval must be done from a local connection, approvals cannot be done from Portal. Thanks

With regards to the Zigbee error. It should be removed in the next version of UDM. I see multiple reports of this crash. Will investigate today. It may be helpful, but always better if I'm told how to replicate. Some of the crash reports contain no more than the Model, Firmware, and user notes and are missing logs. I don't check Apple's reports often, unless someone says a crash report was submitted. Firebase is usually much better, although this crash is not showing in Firebase, likely because the app is backgrounded when the crash occurred.