Javi

The only thing that sticks out is secure https entry. I think you need to use the URL to ISY from portal not "my.isy.io". Maybe post in the Mobilinc forum and somebody else may know.

Thanks! FYI: You can restrict access if you have access to the device you want restricted. Install and synchronize. Create favorites if needed. Hide the system on the Home Tab or hide any folders/devices you don't want them to access. Then Lock Edits from Settings > Global Preferences. This will prevent the user from unhiding hidden nodes/folders, Editing any Nodes/Folders, and Accessing anything in Admin or Settings Tab unless they have the pin used to lock edits.

You referenced iPad, Apple disables App Transport Security In iOS 10 and macOS 10.12 and later for local loads. https://developer.apple.com/documentation/bundleresources/information_property_list/nsapptransportsecurity/nsallowslocalnetworking

Try using http instead of https for local or vpn connections, this should avoid cert validation.

Are you pressing the button after changing the drop-down?

Does the issue persist today as we had a portal issue resolved late yesterday? Can you verify the app has Always Access to Location as Some above have reported the iOS upgrade may have reset the permission?

Thanks, let us know how it performs. For both iOS and Android some of the older Geofence methods may have been more or less reliable as they utilize different APIs supplied by Apple/Google. We target higher API levels than some of the other Geofence Apps which have not been updated in some time as higher targets are required to submit apps after the API is deprecated. So, unless the app is having issues that are logged in the UDM Geofence log, then the issue is with the Operating System.

Thanks @MrBill, Maybe others will check. UDM should check these permissions whenever the Geofence Screen is opened. It is also possible the Portal issue reported yesterday was the cause of other issues. All, please update if the issue persists.

I would not worry to much about the polling time, greater than 30 minutes should work especially if your driveway is within your WiFi range as Wifi events will trigger app to update location. The important thing is that the service is running. I have 30 minute updates and am only seeing 1% more consumption daily. Unfortunately recent Android updates now require that the app is in the foreground (UDM Location Service) to track WiFi events. If your driveway is not within WiFi range, you could setup multiple Geofences and then in commands increase or decrease polling interval to preserve battery. For example when you are within a mile from your home increase polling to every minute or two, when you exist the same larger geofence decrease polling interval. When you enter your main home geofence decrease polling, on exit increase to every minute or two. This is not done automatically by the app as it is very dependent on the user's travel distance and mode of transportation.

Hi @EJones01, Do you have UD Mobile Location Services Enabled? If there is nothing in the log then the Android System never alerted UDM to the crossing. Android has Geofencing issues which have been acknowledged by Google, see link below. The UDM Location Services tries to overcome these issues. I have been running for 2 months with little battery consumption using the default of every 30 minutes. Location Services also runs a WiFi monitor, so whenever the device joins or drops a Wifi network location will be requested, dropped WiFi connections have a delay of 2 minutes to allow time to exist Geofence. https://wiki.universal-devices.com/index.php?title=UD_Mobile#UD_Mobile_Location_Services

Thanks guys, I've replicated when using portal. Is this happening to anyone on a local connection? Note that you must have Local Connection Settings enabled and tested in UDM or it will use portal.

Do you get the same error as @TSinclairon UD Mobile? It should work. Please open a ticket and we will take a look. Please included a zipped copy of ISY backup file and UUID. Also let us know if you have ISY Portal as I may be able to run a remote diagnostic with your approval.

Thanks I'm wondering if the device is switching from WiFi to Mobile when the command is sent. Can you please try to increase the radius to allow time for WiFi disconnect?

Thanks @MrBill, I'm racking my head on this one, but I have not upgraded to 16.4.1. It does appear to be iOS stopping network requests. Edit: Confirmed the other user reporting issue is also on 16.4.1 @tmorse305, Are you on 16.4.1?

Thanks. What is the command being sent on fence crossing, such as device, scene, variable or program? Are you using TestFlight? I'm going to try to modify the connection request in case Apple is cutting the app's network access, but do not want to release to all users without testing.

Request timeout, odd that it took almost 10 minutes to log. The good thing is we know the app is still running. I have one other similar report, but have not received the log so not sure if it is the same issue. How large is the geofence radius? Are you in a vehicle when this happens, if so does your device connect to the vehicle WiFi?

Great! Thanks for testing!

The context is 2 way communication between ISY and an external device or service which is why Node Servers were created. Operating a group of devices is dependent on the developer and the devices receiving the commands, so if this can be done in NRbridge is see no reason this could not be done in a node server. If these devices are network controlled with different IP Addresses then multiple threads must be used so each device can receive the command at about the same time.

Yes, but this would only work in your specific situation. Most API Calls return something that needs to be parsed then converted into a value accepted by ISY. The prefered method for this type of integration is a Node Server. Which will eliminate the need to use variables and network resources.

Great! Just awaiting Apple's Approval.

@mbking, Do you happen to have an app backup file? This looks like something in Favorites are causing the crash. It will be much easier to locate if I have the setup. Edit: Replicated issue and removed from test flight. I think you can downgrade the version, but only attempt if you have a backup file...I have not attempted this before so am unsure if it is destructive. Edit 2: Should be fixed in version 1.0.30

I think I see your crash report. Looking into this now. XCode (iOS development) was updated and required dependency updates also which may be the cause.

Fixed in Android 1.1.4 and iOS 1.0.29

Hi @MBell, Thanks for the report. I tried but cannot replicate the issue. Are you using the Z-Matter module or Zooz USB stick? Update: Replicated. Looking for cause

Server version is usually updated a few days after the forum posts, think of this as a staggered release. Force Upgrade from app will still upgrade to latest version even if it is not known to the app. I was just informed there is bug in the semantic version comparison if you upgrade before server version is updated. This is causing the app to show Firmware Update Available when you have a version greater than known current version, even though there is no upgrade available. Will be fixed in the next version.