Using Disabled Program Status for UD Mobile Node

[Jimbo.Automates]

I have a disabled program that I wanted to use as a UD Mobile Favorite, but a disabled program does not change status True/False when the items in the "If" change.  If you update/save the program then it changes, but not when the nodes or variables change.  I confirmed this with a simple program checking a variable value on latest ISY and IoP releases.

So if this is not considered a ISY "bug", is there an easy way to work around it?  I can't have the programs run from the triggers so they must be disabled, but I want to see the correct status in UD Mobile...  I also tried putting them in a folder that was disabled with an if condition, and they also don't change status.

 

[DennisC]

8 hours ago, JimboAutomates said:

I have a disabled program that I wanted to use as a UD Mobile Favorite, but a disabled program does not change status True/False when the items in the "If" change.  If you update/save the program then it changes, but not when the nodes or variables change.  I confirmed this with a simple program checking a variable value on latest ISY and IoP releases.

So if this is not considered a ISY "bug", is there an easy way to work around it?  I can't have the programs run from the triggers so they must be disabled, but I want to see the correct status in UD Mobile...  I also tried putting them in a folder that was disabled with an if condition, and they also don't change status.

 

I have a disabled program in my favorites in UD Mobile. While mine has no if statement, I run it manually, I thought I remembered the icon changing to indicate running. I just ran the if statement manually and it did display a filled in dot in the corner to indicate running.

Not sure if the comparison is the same.

[Jimbo.Automates]

I have a disabled program in my favorites in UD Mobile. While mine has no if statement, I run it manually, I thought I remembered the icon changing to indicate running. I just ran the if statement manually and it did display a filled in dot in the corner to indicate running.
Not sure if the comparison is the same.

Not what I'm saying. I want the idle True/False to show the proper status of the if statement when the conditions change outside of running the program.

Sent from my Pixel 6 Pro using Tapatalk

[Javi]

12 minutes ago, JimboAutomates said:

Not what I'm saying. I want the idle True/False to show the proper status of the if statement when the conditions change outside of running the program.

Sent from my Pixel 6 Pro using Tapatalk
 

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.

[Jimbo.Automates]

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.

Thanks Javi, I was hoping for an easier workaround. That's a lot of work to do something simple in UDMobile especially since I currently have 3 similar programs. Program conditions are also evaluated when it is saved. Maybe I can convince them to add this as an option to always evaluate them.

Sent from my Pixel 6 Pro using Tapatalk

[Javi]

1 hour ago, JimboAutomates said:

Thanks Javi, I was hoping for an easier workaround. That's a lot of work to do something simple in UDMobile especially since I currently have 3 similar programs. Program conditions are also evaluated when it is saved. Maybe I can convince them to add this as an option to always evaluate them.

Sent from my Pixel 6 Pro using Tapatalk
 

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.

[Jimbo.Automates]

50 minutes ago, Javi said:

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.

Yes, I understand why this is, and I've submitted a ticket which @Michel Kohanim cc'd@Chris Jahn to get the experts opinion.

That's another possible option you mention, but still just jumping thru hoops to achieve something that seems very desirable in UD Mobile.

I've been trying to think of an enhancement in UD Mobile to handle this better, but haven't come up with anything that makes sense...

[jfai]

Hopefully, a disabled program remains out of the evaluation queue. I am disabling programs because I want them ignored completely. I think what Jimbo is requesting should be done with a different program calculation mode, something meaning "evaluating but not executing". So we'd have "enabled", "disabled", "evaluating".

[Jimbo.Automates]

Hopefully, a disabled program remains out of the evaluation queue. I am disabling programs because I want them ignored completely. I think what Jimbo is requesting should be done with a different program calculation mode, something meaning "evaluating but not executing". So we'd have "enabled", "disabled", "evaluating".

Yes, that was part of my request in the ticket.

Sent from my Pixel 6 Pro using Tapatalk

[Jimbo.Automates]

9 hours ago, Javi said:

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.

Using an integer variable as only condition does not work, it has the same issue, the program state doesn't change when integer changes value.

On to try another workaround...

[Javi]

22 minutes ago, JimboAutomates said:

Using an integer variable as only condition does not work, it has the same issue, the program state doesn't change when integer changes value.

On to try another workaround...

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.

[Jimbo.Automates]

2 hours ago, Javi said:

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.

Sorry, first paragraph makes sense, but you lost me in the second paragraph, and not sure which if those programs you purpose be the UD Mobile favorite?

And FYI, this is the simple program that I just wanted to add as a Favorite node in UD Mobile:

Quote

Arm Stay Example - [ID 036A][Parent 0367][Not Enabled]

If
        'Alarm-Elk / Home' Armed Status is not Armed Stay
 
Then
        Set 'Alarm-Elk / Home' Bypass
        Set 'Alarm-Elk / Home' Set Armed Status Armed Stay
 
Else
        Set 'Alarm-Elk / Home' Set Armed Status Disarmed
 
This is activated in Sleeping mode...
 

That would be a simple toggle to show if it was Armed Stay or not and allow simple arming.

Edited March 18, 2022 by JimboAutomates

[Javi]

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
        
 

 

[Jimbo.Automates]

Thanks @Javi now it makes sense, the part that wasn't mentioned or I didn't see was to use COMMAND, not a node reference program. I already use command and was looking for a cleaner way to implement, and a disabled program seemed perfect.

Sent from my Pixel 6 Pro using Tapatalk

[Javi]

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.

[Jimbo.Automates]

Thanks, yes I already do this with the original program mentioned and monitor the status of the armed state node.

But I found what looks like a bug in UD Mobile. I have 2 similar commands, one for armed stay and another for armed away. When I configure the color mapping for one it changes both? May have to send you a video tomorrow.

Sent from my Pixel 6 Pro using Tapatalk

[Javi]

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.

[Jimbo.Automates]

Oh okay. Makes sense. So now I'll have to create the extra program like you mentioned to show color status different for each.

Sent from my Pixel 6 Pro using Tapatalk

[Javi]

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.

[Jimbo.Automates]

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.

Yeah, not sure. For this I want the simplest interaction since I usually have my hands full backing out of the driveway or holding dog leashes and I only Armin stay or away mode most of the time.

Sent from my Pixel 6 Pro using Tapatalk

[Jimbo.Automates]

Using a Program as the Status Node in a Command takes a lot longer to show current status when initially opening favorites.  It takes ~11 seconds to see the Armed Status node, but ~1:45 for the program status to show up... Yes I have a lot of nodes and programs, and this was when using portal as well.  Using a Variable comes up after ~18seconds, so I'll use that instead.

 

[Javi]

6 minutes ago, JimboAutomates said:

Using a Program as the Status Node in a Command takes a lot longer to show current status when initially opening favorites.  It takes ~11 seconds to see the Armed Status node, but ~1:45 for the program status to show up... Yes I have a lot of nodes and programs, and this was when using portal as well.  Using a Variable comes up after ~18seconds, so I'll use that instead.

 

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.

 

[Jimbo.Automates]

Thanks for all the details, much appreciated.

1. That's what I did, only request initial state of integers so I'll just use those when I need initial status.

2. Good point, I did that, since I rarely use it in development.

3. I had already increased mine to 5 minutes, didn't want to go much longer for fear of battery drain

4. This is possible from a couple PG2 nodes I still use.  Unnecessary updates should not happen with PG3 since Bob improved it, but we can still see updates for some things more rapidly like wind speed and constant temperature changes in wireless tags.  The WeatherFlow NS has a way to turn off rapid wind speed changes, but I like to know about high wind guts asap.  Maybe I'll shut down the PG2 ones I still have like Blue Iris which I currently don't really use.   But watching the event viewer I don't see a lot of craziness coming thru.

[Javi]

10 minutes ago, JimboAutomates said:

4. This is possible from a couple PG2 nodes I still use.  Unnecessary updates should not happen with PG3 since Bob improved it, but we can still see updates for some things more rapidly like wind speed and constant temperature changes in wireless tags.  The WeatherFlow NS has a way to turn off rapid wind speed changes, but I like to know about high wind guts asap.  Maybe I'll shut down the PG2 ones I still have like Blue Iris which I currently don't really use.   But watching the event viewer I don't see a lot of craziness coming thru.

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.

[Jimbo.Automates]

It shouldn't matter for PG3, I thought @bpwwer added a check to not push the same value?

Sent from my Pixel 6 Pro using Tapatalk