Javi

Fixed in firmware:

Hi All, Thank you, issue has been replicated. We are looking into the issue now. Issue: https://github.com/UniversalDevicesInc/UD-Mobile-iOS/issues/55

I believe the missing protocol was fixed. So the original version should work...

Thanks @DennisC. That is great news and reduces some of my fears of WiFi trigger implementation.

Thanks @dbwarner5 and @larryllix. I'll leave this for @Michel Kohanim as not related to UD Mobile.

I'll see what we can do with network change triggers, likely after the default geofencing has been implemented. That's great, the default geofence implementation should work in your case. I assume you are not using the WiFi method used by @JimboAutomates, my Samsung devices had mixed results compared to Pixel devices with regards to WiFi disconnects during long durations of screen off.

Can you verify the time of last change value on UD Mobile differs from that in the AC?

Hi @dbwarner5, This time is published by the ISY as a string and not modified by UD Mobile. You may notice there are two formats as the REST and Subscription strings differ. The times should match the last run time in the Admin Console. Sometimes messages via email, or email to carrier to sms, can be delayed or arrive out of order. In my personal use I add a timestamp the message, although it is not needed as much now with Push Over. When I was using the email to sms for my messages some would arrived 12-18 hours late. Also be sure you are on the latest firmware as I recall the time being an issue in previous firmware versions.

I've used a similar tasker profile in the past as my results were also better with WiFi than geofencing. I feel that the basic iOS geofencing is superior to the basic Android geofencing, especially when we consider multiple manufacturers (i.e. Samsung) implementing their own battery saving features. However when adding the required permissions, changing settings, and adjusting polls with Tasker I feel Android has the advantage. I am very hesitant to implement the WiFi method as I foresee too many support issues. If you know what your doing tasker works fine, if you don't the same implementation on UD Mobile will not work either. The main issue being WiFi will disconnect a few times a day event if the device is in the same location, some of this is mitigated by disabling battery saving features. There was a time a few years ago I swore I'd been hacked or haunted as the lamp in my office would turn on/off at random times day and night as I had left a Tasker profile active on a development device. The cell tower density of rural, suburban, or urban environments along with type of transportation have a role in success rates. Living in an urban area most of my errands and previous employers where within 3 miles, so the basic geofencing implementations failed frequently when driving, but worked well when walking. If I had Google maps, or any other gps app, running while driving geofencing worked better. However I have no reason to use Navigation driving to locations within my community. Finally, trying to add family members into the mix, some who frequently have a dead phone, children who have restricted use times, and some who frequently left the device at home, it became too much. I say this as, much like @MrBill, I found another way to ensure security is being monitored. In my case we walk more than drive and parking in not attached to the home, so we just need to monitor the doors and motion sensors. With that said we do plan on implementing the basic geofencing methods by Apple and Google in UD Mobile. If the basic geofencing methods do not work for a user, it may be better to find another solution to monitor location.

Hi @bhihifi, Understood. This feature should be live on iOS within the next 2 weeks.

Hi @bhihifi, As of today Alexa Configuration from UD Mobile is only available on Android. The same feature should be live on iOS in the very near future. Until that time ISY Portal can be used. Portal and UD Mobile use, or will use, the same Alexa database. Although, if I understand correctly, the issue is the device is not showing in ISY Portal. If this is true, does refreshing the web page work?

Hi @bhihifi, UD Mobile or ISY Portal can be used to add/edit/remove devices linked to Alexa. If added from ISY portal they will be shown in UD Mobile, if added from UD Mobile they will show on ISY Portal. In addition to a pull down list of devices, you will also be able to add/edit/remove the Spoken Names from the Devices screen in UD Mobile.

Hi @bhihifi, Alexa configuration is available for Android in Beta, this should be released soon to production. We are in the process of adding the same for iOS now. ISY Portal is required and must be linked to UD Mobile. Configuration in ISY portal will match the configuration in UD Mobile.

Hi @sumguy, I understand your issue, and I'll see what we can do at that time. Some geofence issues are caused by OS limitations and can not be changed by app developers. I estimate 3/4 of used cases can be covered by basic geofence implementations. About 1/8 of used cases will require workarounds with added permissions, keep alive, and wake interval settings. The final 1/8 of cases may never be resolved. In the case of poor internet connection we have a few issues. The first is the OS may limit the amount of time an app has to perform background tasks, this includes sending a web request or saving data to persistent storage. If the data is saved to persistent storage when a request fails, something else would have to wake the app to check if the connection is available. Even if we have timers set to wake the app every X minutes, which Apple may reject as it would defeat battery preservation, do we still send the request X minutes or X hours later? If we do send the request late it should include a timestamp. The server (ISY and/or Node Server) needs time verification so that it does not trigger and incoming request if it has a later timestamp than the previous request.

Insteon battery sensors will not show status until there is an update. Updates are usually around every 24 hours unless triggered.

Hi @asbril, Although I have not personally tested the following integrations they are available. Windows 11 now has the Amazon App Store. So if your PC meets the hardware requirements UD Mobile can be downloaded from Amazon. New MACs with an M1 chip support iOS Apps. The app has been tested with the Blue Stacks emulator and does work. Blue Stacks is available for both Windows and MAC.

Android (Open Testing) 0.124 Systems View Advanced Settings replaced with individual groups of settings. Added alexa configuration for ISY Portal. Add/edit/view individual Alexa Spoken configuration from a Node's Dashboard by clicking the voice icon at the top. Add/edit/view all spokens from Admin Tab. Legacy Elk Module configurations (non-Node Server) is implemented but not tested. UD Mobile does not support the Legacy Elk Module so these types can only be accessed from the Admin Tab.

Hi @photogeek54, The instructions are for UDI Mobile, a third party app, which appears to have been removed from Google Play. Geofencing for UD Mobile is on our list but not yet implemented.

PM Sent

Anything in the NodeServers log when set to debug? Maybe try to restart or install another instance to see if the nodes are being created without Warnings/Errors. Also verify the nodes are shown in Polyglot, not just in ISY. If you ISY is connected to portal we could run a remote diagnostic if your interested.

Hi @glarsen, I was looking to install one of the offending Node Servers on my system. Check if I receive the same errors to eliminate the possibility it is related to the specific ISY or Polyglot instance. If the URL is throwing the same error it's not an issue with UD Mobile, so I think at this point we can eliminate the client. I still think the ISY is under a heavy load somewhere as I have Node Servers with UOM 25 an no issues. Do you have multiple instances of Polyglot (2/3) connected to the same ISY/ISY-Service? If you do does temporarily disconnecting all other instances fix the issue? Changing the address of the ISY in the instance and saving should be fine, without the need to shutdown.

Hi @glarsen, Will any of the node servers with the error work without hardware, if so which one(s) and what is the command which is failing?

Just updated to 3.0.40 from 3.0.38 and can not replicate, can you send a copy of the ISY error log? I read there were issues with 3.0.39, did you update to 3.0.39 at any point before 3.0.40? We can get to the next items after the error log. There are reported issues with older versions of PyISY (used in the Hue Emulator). Does the issue persist if the Hue Emulator NS is disabled? There is also a report involving ELK, but just a correlation and not verified as the cause of any issues, so please also disable both Node Servers if disabling Hue does not work.

Hi @glarsen, The URL looks good, and I've only encountered a persistent 404 when the ISY is under heavy load. Does anything stick out in /rest/log/error? Is this for PG2 or PG3? What is the PG version number? What is the Pol-ISY firmware? Does the error persist after Polisy is rebooted? Do you have the Hue Emulator or ELK NS installed?

Is this for Android or iOS? I don't see predefined errors within the app with this exact text, so it may be coming in at the Mobile Device OS level. Is this the error displayed when pressing the Test Connection button dialog, or is this a Notification pop-out from the top of the screen? If a pop-out this error is only because the app lost the subscription, which will happen if you turn on/off wifi/mobile-data but the app will try to connect again in a few seconds. Test the local connection without the app accessing SSID or Remote Connection as follows. Temporarily turn on "Only use local connection" then press the Test Local Connection button. If all works there then turn off "Only use local connection" and try again. This could narrow the issue to SSID or local credentials.