Javi

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.

Hi @CNelson03, May be an expired remote access subscription, please go to UD Mobile > Settings-Tab > Systems > Your System and the app will attempt to diagnose connection issues. If you prefer local only access without portal see: https://wiki.universal-devices.com/index.php?title=UD_Mobile#Local_Connections_and_Local_VPN

Added "response", as this was the context.

There is no way to set variables using Network Resources response. You could try the AV Remote Node Server which shows Denon support in the description. Another option would be to use UD Mobile to trigger the the volume change in IoP instead of a direct connection to the equipment.

Beta Version 1.1.2 This version re-enables local connections to PG3/PG3x and remote connections to PG3x. Please report any issues in the UD Mobile sub-forum. Note that Local Connections require 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 will require manual upgrade to PG3x for remote connections, eisy was shipped with PG3x. Added PG3 Remote Connections for PG3x. Changed MQTT Library for local connections and re-enabled local PG3 connections. Added PG3 Notification Options. Added darker gray color for cell subtitles. Fixed click listener for favorite folders with variable display node. Bug fixes

Are you using the Z-Matter USB stick? Does the Address of the Z-Wave device match? ISY had ZW prefix to Z-Wave Addresses, Z-Matter prefix is ZY.

Hi @fustesj99, While the app does have custom scheme urls most of them will not work with chrome, see link below, although I believe could use the intent anchors listed on the same page. https://developer.chrome.com/docs/multidevice/android/intents/ https://developer.chrome.com/docs/multidevice/android/intents/#syntax https://developer.chrome.com/docs/multidevice/android/intents/#examples See the following post for intent to launch UD Mobile from tasker for the parameters. https://forum.universal-devices.com/topic/32544-favorites-set-as-default-first-screen/?do=findComment&comment=312306

If not already tried, the alternate code in the Node Server may work. Sometimes GC includes 2 codes for the same command.