Javi

@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.

I still have a OPEN COMMAND PICKER (editor range picker/edit text, i.e. select arm, disarm, ect.) as a Favorite type on the Todo list, this may be a better option in this situation.

Color mappings are at the Node Status Level (ST,GV0,ect.). So, If using the same node status value on multiple favorites adding/changing the mapping will affect all favorites and home screen for that node. Changes on Home Tab, assuming changes to home screen display status.

Yes, both of my suggestions were for COMMAND type. The latter with 2 programs would show a proper toggle. Although my preference is the former in this situation as, I assume, a home alarm could have more than one status (armed home, armed away, disarmed, violated, etc.). As a developer you have another option. Adding DON and DOF commands with DON init to status (ST) and use a uom for Z-Wave or Insteon lights. I can lookup the exact UOMs if needed.

This is a simple program with one status as a condition so it should be simple to implement in UD Mobile. See the Door Lock example as it is very similar and uses a disabled program. https://wiki.universal-devices.com/index.php?title=UD_Mobile#Favorite_Custom_Toggle For example you would add this program as a UD Mobile favorite COMMAND, In the commands at the bottom. Then add the "Alarm-Elk / Home' Armed Status" as the DISPLAY NODE. Now when you click the favorite it runs the command and also shows the status of "Alarm-Elk / Home' Armed Status" Just in case any one else finds this the Program method I mention involves keeping the same Program but setting to ENABLED than removing THEN and ELSE: Arm Stay Example - [ID 036A][Parent 0367] (ENABLED) If 'Alarm-Elk / Home' Armed Status is not Armed Stay Then (EMPTY) Else (EMPTY) Then having another program used the status of the program above as the IF Condition to run while "NOT ENABLED" TestProgramTrue - [ID 00DA][Parent 00BB][Not Enabled] If Program ' Arm Stay Example' is True (The program above) Then Set 'Alarm-Elk / Home' Bypass Set 'Alarm-Elk / Home' Set Armed Status Armed Stay Else Set 'Alarm-Elk / Home' Set Armed Status Disarmed

Enable the current program and set the integer variable 1 for true 0 for false. Move the current THEN/ELSE Bodies to a new program set the variable as the if condition and disable. Now you can call the disabled program same as before. The same process for programs only except you don't set a variable (leave empty) and in the new disabled program check the status of the original enabled program.

I've seen similar arguments in the past where users wanted this changed, but from a programing perspective it is logical and the request can be achieved in multiple ways. There may be a better argument to remove evaluation at save. Another work around would be to use 2 programs one without THEN/ELSE which evaluates and the other which is disabled and uses the first program Evaluation (True/False) in the If condition.

The Idle-True, Idle-False, Running-Then and Running-Else status for the IF condition is only evaluated when IF is run. Disabling a program will cause IF condition to not be evaluated unless manually triggered. So, when a Program is disabled it will show the status of the last evaluation. A work around would be to use a State or Integer Variable, State if used to trigger a program, Integer if only needed for status. Then Set the Variable as the status node, Finally add the value mappings to have human readable status values displayed on UD Mobile.

That does make more sense, maybe @bpwwer can chime in regarding this parameter. I know there are some changed in PG3 regarding status but I'm not up to date with the exact changes.

I see how it could be confusing. Maybe better words would be "running" and "stopped". If a NS does not crash, or does not stop itself, then it should remain "connected" (running) until stopped by the user.

See download link for ISY Launcher to launch the Admin Console https://wiki.universal-devices.com/index.php?title=Main_Page#Quick_Start_Guides

Exclude can be done from from any zwave controller, does not have to be the same controller which included the device.

The best option is to restore your backup If you have a one. If you do not search "excluded <lock name>" on Google and there should be a few videos/instructions.

If you search the form preferably with google ( site:forum.universal-devices.com Yale ) you will find many users with issues communicating with Yale locks. I recall a post (although I could not find it with a quick search) that stated the only way the lock would work reliably was with the ISY within a few feet. The same users stated communication would not work through a repeater, possibly due to the security level. There are other users with posts having issues similar to yours when batteries are not close to 100%. Other locks work much better, although some require the device to be very close to the ISY during initial inclusion. I assume there is an issue with this manufacturer, if locks from other manufactures function correctly at a much greater distance. I have a couple of Schlage locks about equal distance from the ISY, some 20-30 feet through 70+ year old 1.5" plaster walls and backer board. For context to the extent of signal degradation in the home, it is almost impossible to get WiFi outside of the home, 20-30 feet from the access point. One lock is hard wired to my whole home 12v system, with voltage transformer the other is using batteries. The wired unit rarely reports an unknown status, the battery unit more often especially when batteries are low, although both will report correct status on query.

The only time it should be overwritten is if the step value is not null during synchronization. So, if the value was initially empty then the value you set should remain. It is possible that a firmware update or Node Server update (Node Servers only) adds/changes this value.

Hi Dennis, I made some adjustments to the position calculation in 0.133, please try changing the step value to "1" again. If this does not work I may need to run a remote diagnostic to find the cause. Android 0.133 Added value rounding for editor range scroll position.