Javi

Fixed in 0.136 should be live soon.

Thanks @DaveStLou, Looking into it. I bumped the Android version target in 0.135, the error it looks related to version target.

I understand the intent of the comments, not trying to invalidate just adding some additional information for other users and acknowledgment of a bug. Example device and url key values are not populated as they should be. It may be a good idea to add separate parameter for learned codes as single entries. The custom typed params will allow for this with all three params (device, button, code) in a single entry. I'll add it to my todo list. The Node Server was designed to copy and paste the entire codeset for a device from the control tower database. There are instructions for the Control Tower database in this subform, which could save lot of time if your codes are available.

Beta 0.135 Added Load Profile function. Updated gradle. Fixed missing Custom Params entry when empty. Fixed Hanging indicator. Fixed show Hide Custom Params button. Fixed double dialog popup for new PG3 system. Beta 0.136 Fixed Intents for API 31. Beta 0.137 Reverted navigation component as deep links do not allow navigation to lower tab indexes. Beta 0.138 Reverted target version to fix MQTT Paho crash.

Hi @akorkosz, Can you please open a ticket? We may need personal information to find the error. https://www.universal-devices.com/my-tickets Thanks

Some of this could be improved in the future. I think the iTach could be found automatically, it is likely a few days of work to build the necessary files, so not really worth the effort unless there are hundreds of users. I've contacted GC in the past about commercial access to the Control Tower API, but never received a response. I can try to see if they will respond if I can show remote creation with UD Mobile, this would allow automatic import. I believe the Custom params are for data which would be impractical to add a drop down, such as IP Addresses. If a drop down can be created I think it should be done in the AC/UD-Mobile frontends. Maybe @bpwwer has some ideas to make the key static and not show as editable for the required parameters.

0.134 Added PG3 frontend port, minor bug fixes: App Saves and encrypts PG3 credentials. Link a new or existing Portal Account, portal account can be shared with ISY for single login. Poral Login required to purchase Node Servers to help prevent unintended purchases. If Portal account is linked in app there is no login required to install purchased Node Servers. Allows for multiple PG3 instances (Polisy systems). Add and edit ISYs linked to PG3. Access PG3 store. Install Node Servers. Purchase Licenses (directed to ISY Portal for secure web purchase). View License options and purchases. Add/Edit configuration parameters. Node server commands Start/Stop/etc. View Node data and logs. Known Issues: Double dialog popup on new system setup. Fixed in 0.135 Load Profile button returns error. Fixed in 0.135 Configuration Params show/hide button return error. Fixed in 0.135 Custom Parameters can not be added when there a no values. Fixed in 0.135 Limitations: Currently PG3 can only be accessed from a local network.

Hi @apostolakisl, Thanks for the feedback. I noticed that the Configuration Parameters and sample data is not imported on install. I'll try to get this fixed soon which should help new users during setup.

I think this was just a case of me forgetting to push fixes to production. Please try version 2022.01.24 when available. There currently appears to be an issue when updating the store, so if the Node Server is missing from the store, try again at a later time. Thanks.

Clear Java cache and download launcher. https://wiki.universal-devices.com/index.php?title=Main_Page#Quick_Start_Guides

Hi @chris.com, Thank you! All M1 issues are being tracked as app bugs. So, the issues will be addressed, with the most severe issues bumped to the top of our list. Issues of lower severity and enhancements for larger screens have a lower priority.

This topic holds the latest release notes for UD Mobile on Android. Please scroll to the last post for the latest information. UD Mobile available for public testing. Please create backups after favorites/customization creation/change when using beta builds. iOS: https://testflight.apple.com/join/xHtzI5R3 Android: https://play.google.com/apps/testing/com.universaldevices.udmobile

Release announcements have been moved to the "Current Release Announcements".

Great.

Backup restoration was the OP's issue as well and it has been replicated. I think it may have to do with the global preference open to favorites tab and that the app data is not deleted when uninstalled on the M1. There are a few other crashes observed but this appears to be the only one that prevents the app from opening. To fix Delete the "UD Mobile" folder from "Documents" on the Mac M1 and launch the app. For an import make sure the backup has a default launch setting on your iPhone. Then swipe away the app, this is only needed to clear a working database as sometimes database writes are still in queue. If you open the app on your iPhone and it is not directed to favorites create a backup, and import the new backup onto the M1. Notes and M1 Issues: Setting launch preference to Favorites tab on the M1 will prevent the app from opening. The app does not appear to have the ability to read WiFi networks on mac, so it will work with a portal account or "Only Use Local Connection". Favorites moving may not refresh correctly and show duplicates. Fix by toggling the edit button and app will refresh and remove duplicates. Favorites will be moved on long press without the edit button, refresh will be an issue here also.

@Mayben, I was forced into the M1 Max for the 32GB, a memory upgraded for the M1 Pro was one of the middle of May options. The M1 Pro/Max difference was less than $300 after memory and hard drive upgrade so the M1 max may be a better investment a few years down. I have both a 64GB and a 16GB Mac mini. The 16GB has a slight performance lag, but barely noticeable until I run android/iOS emulators. I think I would have been good with the 16GB version if emulation was not a requirement.

@chris.com, I acquired a M1 Mac Pro over the weekend and was able to produce a few crashes. I'll push fixes as soon as possible, although likely at least few weeks before it will be in beta. Hi @Mayben, Any additional testers will be helpful. Procurement is difficult even when paying full price. As luck would have it, there was a single M1 Max with the specs I needed about an hour down the freeway. Wait time for in store pickup at our local Apple stores or home delivery was the middle of May. Being a windows user most of my life the price of any high end Mac hardware is hard to justify. Currently I use a i7 mac mini for development, the hardware is great. The Mac Pro M1 max appears just as good at double the cost. Both are the best hardware I've ever owned, although both cost almost double what I would have paid for a windows PC with similar specs. Aesthetically the Macs win. More than half of the professional software I use on Mac is inferior to Windows versions, however that appears to be a development issue not related to hardware as there is software which works great on both platforms. I don't remember Android Studio crashing anytime in the last two years on either platform, xCode crashes at least once a week and needs to be restarted at least once a day. QuickBooks on mac is almost unbearable and fails to record transactions, crashes or needs restart at least a few times every day, the PC versions has been great for the last 17 years without a single crash.

Thanks, the new UOMs have not been updated on the app side, they should be in the next release.

Thanks @brians. I'll have to take a look next week sometime, I'm still on 3.0.44 as I need a stable version of PG3 for frontend integration into UD Mobile. I'm saving the upgrade tests for last but should be in the next few business days. What PG3 version are you using? Hi @stevehoyt, I'm doing the same as you, it was your idea ?

Thanks @glarsen, this error is likely related to an invalid init value for a command parameter. @JimboAutomates, do you have an init value set to "0" for a NodeDef.Accepts.Parameter somewhere?

Hi @chris.com, Thanks for the report, as of today I only have intel Macs so the app has not been thoroughly tested on M1. Apple reports a handful of Macs running the app but no crash reports. It may take a few days for me to get the reports, so I'll keep checking. In the meantime please open a ticket and reference this thread. Thanks!

Not from any legitimate sources. Most users have prefered tasker geofencing over UDI Mobile on Android for some time.

Everything looks correct and the response 200 indicates it was received. Below is a working NR form one ISY to another using portal. Do not check Encode URL, Use SNI does not appear to affect this resource. Also be sure you are using https and the portal user name and password and press "Update" then "Save" in the Resource Editor and "Save" the bottom of the Network Resource Tab before running the test. Being that everything looks ok in your posted setup and response I would verify that you are using the correct URL to ISY. GET /isy/XXXXXXX/rest/vars/set/2/2/${var.2.1} HTTP/1.1 Host: my.isy.io:443 User-Agent: Mozilla/4.0 Connection: Close Content-Type: application/x-www-form-urlencoded Authorization: Basic XXXXXXX

I think this is dependent on the Node Server, at least it was in January when I developed OpenSprinkler. The OpenSprinkler Front End makes a request for all status values every 5 seconds, so I replicated this in the Node Server. In my first build I updated all status values when received from OpenSprinkler, which caused a noticeable slow down when opening the app. The solution I found was to hold the current value and do an equality check when status is received, then only publish an update if not equal.

This is very dependent on the number of programs, variables, nodes, systems and update frequency of nodes. My main system has 358 nodes with an average of 3 status values per node so about 1000 insertions at startup. This takes about 5-7 seconds on a local network 7-12 on a fast portal connection. Status at startup is the main reason adding programs and variables is disabled by default, allowing users to see the performance impact of adding more status values to the database insertion queue. Each status (ST,GVO, ect.) has its own database column. Each program has 6 insertions and each variable has 4 insertions. Each insertion also has at least one query to get the NodeStatusRelations_id, and may have a scene calculation and status insertion. All resource intensive. How to reduce startup time: 1) Only request the initial status of Programs and/or Variables if absolutely needed. Opening the Program or Variable Dashboard will request the initial status. Program and Variable status will always be updated automatically if the value changes while the app is running even if the values are not requested at launch. Program status is not needed to trigger a Favorites COMMAND TYPE if the program is the COMMAND and using something else as the DISPLAY STATUS. 2) Disable test systems in ISY Settings, when not using the test system. This will prevent the subscription from starting and adding insertions to database queue. 3) In ISY System settings (Android only) there is a global setting for Subscription duration in minutes. Setting this value to a higher number will keep the subscription open or restart if disconnected until the Android system notifies the app it will be reclaiming the Apps resources or the duration expires, whichever comes first. If the app is reopened in within this time frame it will not have to insert all values, as the values are current. The default is one minute, for my setup I have this set for 30 minutes. I have found when using the app It is very possible I will open again within that time frame. This usually happens while leaving/returning home so the app will restart the connection in the background when the network changes and have all values populated by the time I reopen the app. 4) I have observed some node servers are sending updates when values have not changed, this adds more insertions into the database queue. Check if you have Node Servers sending updates too frequently without value change and have this corrected. If values are changing frequently verify this is a necessity, i.e. does it need to update time every second? Is the Node Server updating when the value has not changed or not changed significantly such as a high precision when users only use programs with lower precisions. This issue is usually the cause for long durations for status populations.