Optimize macro writing and working: constraint and macro disabling

[R083R70]

Hello,

I have 2 macros, the first one "gesture spegni sveglia" is for not having to swipe exactly on the icon to turn off the alarm clock



and the second one is to turn on and off the first macro, because I have the system log full of "trigger: proximity sensor did not invok because constraint failed".



But in this way I think that the whole process is not battery optimized, having the proximity sensor to work all the time, or at least between the hours specified by the triggers of the second macro.
I have the idea of the first macro that is disabled after one occurence - and then turns on again the day after - but I'm not sure if it's possible and I'm not able to write it so.
Or maybe you have other tips to write these functions in a single and efficient macro...

Thank you, bye
Roberto

 

[420]

Hello,

I have 2 macros, the first one "gesture spegni sveglia" is for not having to swipe exactly on the icon to turn off the alarm clock

View attachment 1314

and the second one is to turn on and off the first macro, because I have the system log full of "trigger: proximity sensor did not invok because constraint failed".

View attachment 1315

But in this way I think that the whole process is not battery optimized, having the proximity sensor to work all the time, or at least between the hours specified by the triggers of the second macro.
I have the idea of the first macro that is disabled after one occurence - and then turns on again the day after - but I'm not sure if it's possible and I'm not able to write it so.
Or maybe you have other tips to write these functions in a single and efficient macro...

Thank you, bye
Roberto

A disabled macro cannot turn itself back on, so you will still need 2 macro's..

I can't really give you a suggestion without knowing more about your situation..

I was going to suggest to change the 2nd macro so it enables/disables the first macro when that app opens/closes, but this might just end up being the same thing you already have if that app is always open between 05 and 09. I gues your alarm does not always go off at the same time either, else you wouldn't have chosen this time segment..

You could however add an action below the UI interaction in macro 1 to disable that macro, atleast it would be disabled before 09 if the alarm already went off some time before then and you've already stopped it.

You say the system log is full of trigger not invoked, but i assume you mean that it was like that during the day, before you made the 2nd macro? Surely it doesn't go off that many times while you are sleeping? So maybe the battery drain is not as severe as you think..

 

[tanutanu]

Proximity sensor itself is working continuously when you turn on the screen basically, whether MD use it or not.
Even on lock screen, it is available to detect closing head for calling, or face recognition and antifake touch mode when you use the features.
Don't be so sensitive I think some monitoring tool apps wastes the battery left rather than the sensor as is.

 

[MacroDroidDev]

As @tanutanu says the proximity sensor trigger will only work when the screen is on and it us used by the system in any case. If there is any additional drain caused by MacroDroid then it should be negligible.

 

[R083R70]

The alarm clock rings always at the sime time in the working days, I just set such a time interval to be sure not to have to modify the macro when I set a different alarm.
But If you say that the proximity sensor is working continously despite MD macros and triggers, I'll keep the second macro just to have a cleaner system log.
I modified the first macro with a "waiting action: 20 minutes" and then "disable macro action: this macro" so I can postpone the alarm a couple of times and have the macro still working.

Is it the same thing about system usage and MD battery usage for activity recognition trigger?
I have a macro that starts when MD recognizes I'm in the car. Is it convenient to limit the working time of this macro enabling it only in the period of time that I suppose to take the car? And in this case, is it better (for battery saving) to limt it disabling the macro by another macro, or applying constraint to the trigger or applying constraint to the whole macro?

Thank you for all the clarification, it's very intersting to learn these things

 

[tanutanu]

The alarm clock rings always at the sime time in the working days, I just set such a time interval to be sure not to have to modify the macro when I set a different alarm.
But If you say that the proximity sensor is working continously despite MD macros and triggers, I'll keep the second macro just to have a cleaner system log.
I modified the first macro with a "waiting action: 20 minutes" and then "disable macro action: this macro" so I can postpone the alarm a couple of times and have the macro still working.

Is it the same thing about system usage and MD battery usage for activity recognition trigger?
I have a macro that starts when MD recognizes I'm in the car. Is it convenient to limit the working time of this macro enabling it only in the period of time that I suppose to take the car? And in this case, is it better (for battery saving) to limt it disabling the macro by another macro, or applying constraint to the trigger or applying constraint to the whole macro?

Thank you for all the clarification, it's very intersting to learn these things

Activity is recognised depending on gyro accelerometer and/or geomagnetic sensor. If you use a map app, it use them as one of the data sources to determine your location and movement as well.
So in this case, the battery consumption is not increase. If you surely doesn't use any other sensor based app, including any location based apps, it would be increasing while your sensor base macro. However you are in the car, so you can charge the battery anytime fortunately
Different than legacy Ni-Cd, the modern Li-ion battery can accepts additional change anytime without damaging. The monitor inside the battery detects full and cut the supply off before overcharged.

EDITED: The gryo sensor might be working all time to detect the device is using or not combined with proximity sensor. And gryo tend to be emulated as a combination of accelerometer and geomagnetic sensor even when cheap devices. So the sensor unit might not cause too much battery usage. I would like to suggest you to take it easy a little bit, don't be too sensitive. Increasing the battery consumption means your activity is meaningful and you make the device helpful for your daily life. That is a trade-off.

 

[R083R70]

Of course in the car I can charge the phone, but I'm asking not only for battery saving (I'm not a battery maniac) but also to understand the working principles of system and macros and to have an efficient system, that doesn't work when it is completely useless

 

[tanutanu]

Of course in the car I can charge the phone, but I'm asking not only for battery saving (I'm not a battery maniac) but also to understand the working principles of system and macros and to have an efficient system, that doesn't work when it is completely useless

As Jamie's frequent comments, I understand he would always like to write natural codes, just following OS API, not own tricky implementation. It seems to be the best practice for individual developers.
It might be interesting for you to read Google's documents for developers.

Motion sensors | Sensors and location | Android Developers

developer.android.com

 

[tanutanu]

@R083R70, best practice for MD users as macro developers is a reasonable benchmarking.
It is very generic and a standard theory but most people tend to say just as they feel or as they read some stores, written by non professional writers on the blog sites. Even experienced app developers, sometimes they modify their own code to "improve" as a wild guess instead of reasonable profiling.
Some historical reasons, some were true, but just rumors and/or "urban myths" now as my understanding

 

[MacroDroidDev]

The activity recognition trigger is essentially a black box provided by Google Play Service that spits out what activities it thinks you are doing periodically which MacroDroid subscribes to and triggers as appropriate. It's impossible to say with any certainty what the impact on battery life will be as it is likely that at least some of this functionality may happen regardless of MacroDroid being subscribed or not. It is certainly possible that subscribing via MacroDroid can increase battery drain slightly but it will be on a case by case basis and only you will be able to determine this on your device I'm afraid.

 

[gisselletdean]

It's an old thread but I want to tell you that I feel ya the struggle of optimizing macros and battery life. Ain't nobody got time for their phone dying in the middle of the day, amirite?
I think you might try to hire app developers to help optimize your macros and make them more efficient? They might be able to come up with some dope code to solve your issue.
As for your idea of disabling the first macro after one occurrence and then turning it back on the next day, that could be a smart move. I'm not sure how to write it either, but maybe some of the more experienced forum members can chime in and help us out.