Javi

Is there an error in the log? The log shows both when UD Mobile received the the fence crossing event from the Android Operating System and when the enter/exist commands succeed or fail. Currently the app is not checking the coordinates only requesting so Android Operating System gets the update. So it could be any of the following. If you can narrow the issue it would be very helpful. Command Failed. This would be logged as a failure but the app should still show the correct status, even though the ISY was never updated due to network command failures or Android blocking network access due to battery saving or restricted background access. The Android OS never notified the App about the fence crossing. Currently the app does not calculate fence boundaries, it relies on the Android OS to calculate and notify of crossing. The app does request location when Location Services are active to force the Android OS to update location as some Android devices are not doing this as intended. If this is the issue there will be no fence crossing logs in the app only location updates if location services are enabled. If we can verify the app logs the correct location but the Android OS did not notify the app, then we may be able to calculate the fence in app. The GPS coordinates are inaccurate. Users will need to check the logged coordinates as sometimes Android is over a quarter mile off of the actual location, if this is happening then increasing the radius solves the issue. My wife and I both have Pixel 6 XLs, my phone was constantly showing outside of the fence while home with 500m radius. My wife's fence is set at 200m and accurate all the time. I needed to increase mine to 700m to avoid erroneous exists entries. . For users experiencing intermittent connection failures we recommend increasing the fence size and/or creating multiple fences. For example create a 700m and a 200m with the 700m being the trigger for both entry and exit. Then setting the 200m with entry only command. This way, if the 700m fails for some reason the 200m may trigger the enter command. The same can be used for missed exits with a larger fence (1000m) only triggering exit.

Please send me a PM with copy of the UDM backup file or check the Geofence Log. As of today, all logs received from users show either a setup error, disabled Geofence, or the issue was resolved by increasing the Geofence radius.

I'm not sure how the YoLink Node Server gets data, this would be a question to ask the YoLink Node Server developer. Some devices/services can be connected locally without cloud service (i.e. openSprinkler, iTach), some devices/services require a cloud component (i.e. weather data not obtained from your own weather station). IMHO if you own the device and it is on your local network you should not need a cloud service for local connections. If you own the device, it is on your local network, and you are required to have a cloud service to query/control from the local network, then you have to ask yourself how is the MFG covering server cost. Every connection requires the MFG to foot the bill to maintain the server. We have all seen many companies offer these services for free then later realize they are losing money due to server cost. At that point they shutdown or charge a fee for access to the device that you thought you owned.

In the program are you controlling the Scene or the KPL button? Due to Insteon limitations Keypad Link buttons can only be changed by a scene, not a direct command.

Are you using Safari? Safari may be unzipping the file but it is possible other browsers have a similar feature. A Google search will show you how to disable this feature. Hovering over the link below shows it is a zipped file

Beta Version 1.1.0 Added PG3 UI for Local Connections. Added PG3x Remote UI for PG3x (Portal account required). Please report any issues on the Universal Devices Forum. Note that Local Connections require that Local Connection Settings are enabled and valid for your System (Settings-Tab > Systems > Your System > Local Connection Settings). Local Connection Settings requires location permission and your WiFi SSID. Polisy requires manual upgrade to PG3x for remote connections, eisy shipped with PG3x.

Please send me a PM with a copy of the UDM backup file so I can review the logs.

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.