Division math expression in set variable action not working reliably

Abalsam

Active member
I feel like an idiot but sometimes the same command works and sometimes it fails. I am building a POC macro to illustrate how to find out when the next alarm is scheduled (in seconds) and then break that down into how many days, hours, minutes and seconds from now that is. Sometimes it gives me the correct answer and sometimes it fails to process the expression so I get a 0 instead. I thought since I am using the same working variable that it was processing too quickly so I put in 1 second pauses between steps with no luck. I can't figure out what I am doing wrong. Any feedback/advice would be greatly appreciated.

I do know I can use a shell script to have date give me this (assuming the next alarm is less than a day away) but the fact that I can't get the other method working reliably has me confused/concerned so I want to keep on this and figure out the (likely my) issue.

ThanksScreenshot_20220120-170858~2.png
 

Abalsam

Active member
To add more detail, here are the logs from 2 runs. The first run calculates minutes (but not hours) and the second run did not calculate any of them correctly.

ThanksScreenshot_20220120-173215-110.png
 

dsnz

Well-known member
it's difficult to say without knowing the variable types and running ourselves
(perhaps you should post macro code)
but are your variables that get division results of decimal type ?
have you thought about rounding issues ?

edit: I've got similar code and it works like a charm
 

dsnz

Well-known member
see also


and .. why the "wait time" actions ??
 

Abalsam

Active member
The variables are all integers and I thought about rounding so I tried with a decimal as well, no change in behavior.

Also, I would have thought that a rounding issue would still process the expression but the logs show that has not been happening. In addition to that, I would expect the same action to be processed the same way every time and it is not....
 

Abalsam

Active member
see also


and .. why the "wait time" actions ??
I will look at that thread thank you. As I mentioned in the orig post, I was afraid the cause might be macrodroid moving on to process the next line before the variable update from the previous line completed so I put in waits.
 

Jacob L

Moderator (Lawsonator)
An app called Setedit shows the system settings tables. One of those tables has the next alarm format which you can use to find the difference between now and your alarm.
 

dsnz

Well-known member
I will look at that thread thank you. As I mentioned in the orig post, I was afraid the cause might be macrodroid moving on to process the next line before the variable update from the previous line completed so I put in waits.
out of order execution ? 😂😂
no it's not possible, no waits are needed 😊
 

Abalsam

Active member
An app called Setedit shows the system settings tables. One of those tables has the next alarm format which you can use to find the difference between now and your alarm.
The poster asked if there was a way to do it in macrodroid so I found a way with a plug in. The issue now is converting that time in seconds to days, hours, minutes and remaining seconds.
 

tanutanu

Well-known member
I feel like an idiot but sometimes the same command works and sometimes it fails. I am building a POC macro to illustrate how to find out when the next alarm is scheduled (in seconds) and then break that down into how many days, hours, minutes and seconds from now that is. Sometimes it gives me the correct answer and sometimes it fails to process the expression so I get a 0 instead. I thought since I am using the same working variable that it was processing too quickly so I put in 1 second pauses between steps with no luck. I can't figure out what I am doing wrong. Any feedback/advice would be greatly appreciated.

I do know I can use a shell script to have date give me this (assuming the next alarm is less than a day away) but the fact that I can't get the other method working reliably has me confused/concerned so I want to keep on this and figure out the (likely my) issue.

ThanksView attachment 2097
You don't need to divide in decimal. Calcite the time difference as you do. then:
int hours = int diff / 60sec x 60min
int minutes = (int diff - int hours x 60min x 60sec) / 60sec
int seconds = (int diff - int hours x 60min x 60sec - int minutes x 60sec)
Useing temporary variables makes these math easier.

Side note that decimal variable is double, so it is reliable in 8byte range. The total number of significant decimal digits is 15 or 16. Before the latest update, it was still calculated in float, so the testing result in if condition was wrong, but Jamie fixed the issue.
 

Abalsam

Active member
UPDATE!!!

I just updated macrodroid and then tried the macro again and it worked flawlessly (5x in a row) I wonder if it was a bug in the previous version.
 

tanutanu

Well-known member
see also


and .. why the "wait time" actions ??
I am also going off track though,
before 5.20.2 or 3, having small waiting time, 50ms to 250ms, was meaningful to keep better performance with loops, plugin calls or text manipulations or even continuous setting variables values if a macro contains a shell script action due to unnecessary rooted check frequently. The issue had solved, seems to need no longer adding the wait:)
 
Last edited:

tanutanu

Well-known member
UPDATE!!!

I just updated macrodroid and then tried the macro again and it worked flawlessly (5x in a row) I wonder if it was a bug in the previous version.
Actually it had.
21,225 / 86,400 = 0.245659722, is over float range, so the result doesn't assigned to the variable nadays. but It's ok while 0.999.... in this case if initialized nadays 0.
the following isn't updated because the result is the same, 21,225 - (0 x 86,400) = 21,225.
21,225 / 60 = 353.75, is within float, so it has no problem.
After 5.21.2, the calculation is correct even in double range(and long but calculate in integer range as well)

EDITED: ah, either float or double, the result is zero if the variable nadays is int:( seems to be natural not updated if zero. You had to store in decimal data type once, when you need below point(for the variable naworking in this case). It seems to be the macro bug or just confused when the variables were not updated.
 
Last edited:
Top