Javi

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.

Have you tried what @apostolakisl suggested? To eliminate the possibility the commands are coming from a source outside of ISY or PLM, disconnect the internet ethernet cable. ISY and PLM will still function but completely remove the possibility of outside interference.

Thanks @DennisC. The precision appears to be the same if the values are incremented by a whole number even if a decimal value of zero is shown. To help me find the root cause of the app not scrolling can you verify if the AC initializes the setpoint command to the current temperature or to another number such as zero?

If not using polyglot, and you are not having any issues with the app, then the errors can be disregard as it relates to the Node Server slot 1. If you would like to remove the error I can ask you for some additional information. Correcting the error will have no changes to a system not using polyglot, and may be corrected automatically when/ if you start using polyglot in the future.

Connected Status in the picture is the connection status between the Node Server and Polyglot. States are connected, disconnected, and unmanaged. The status may show connected for a Node Server as long as the connection between Polyglot and the Node Server is not terminated. The Node Server may be able to communicate with Polyglot and show connected even when the Node Server is not "working". An example would be a Node Server is started and communicating with Polyglot but still needs credentials for the service it supports.

The first error indicates a parsing error for the National Language Support (NLS) file. What Node Server is installed in slot 1?

Yes it is either a picker or raw input. I assumed your request was for a list of values, was I mistaken? What is the Status (current temperature) decimal precision (i.e. 0.5 or 0.1 or none)? Normally the picker should automatically scroll to the current set point, so there may be another issue. This could be a few things including the Command (setpoint) is NOT hard coded to be initialized (mapped) to the Status value (current temperature), or the app could not match the current temperature in the list. The latter is likely the issue if the Status (current temperature) has a higher precision than the list of step values. If the Status (current temperature) precision matches the precision you entered into the Step editor then the issue is likely a missing initialization (mapped) in the Node Definition. I'll try to round the Status (current temperature) to the precision of Commands (setpoint) in a future update. That should allow the app to scroll to the close to the current Status (current temperature).

Due to a design flaw found during a security audit PGC was shutdown until further notice. So, any PGC Node Servers will have the last status reported to ISY until ISY is restarted.

Android 0.132 (Beta) Fixed default values for Node Def Accept Buttons. Fixed database reentry for Node Def Accepts query Accepts Param and Mapped name creation. Joined Node Def Accepts Mapped name tables into Node Def Accepts Query. Added Accepts Command Name and Parameter Name to Parameter Picker/EditText. Added increment and decrement buttons for Accepts param raw input. Fixed default values during edit of commands with multiple parameters. Added Editor Range editor. iOS 0.7.2 (Beta) Fixed Editor Range Step values for undefined Steps. Added Value request in Node Dashboard when application becomes active. @DennisC I think a found a solution to change Step from within the app, although it will need to be tested for your case. In Android 0.132 (should be live in the today) I've added an Editor-Range editing screen which allows the step value to be changed. There is still a 200 Step limit so the Step value may require a value greater than or equal to "1" if the min/max or subset values are greater than 100. To edit the param select the edit button at the top of the dialog for the raw entry.