Customize the log

Post your feature requets for new triggers, conditions, actions and other improvements.

Moderator: Martin

User avatar
Desmanto
Posts: 2709
Joined: 21 Jul 2017 17:50

Customize the log

Post by Desmanto » 04 Jul 2018 18:00

Hi Martin,

When troubleshooting something using the flow log, I found something like this.

======================
05.07.2018 00:15:41.953 [Windows Recognizer] Starting to execute flow 'Windows Recognizer' with Context{global{global_clipboard=[,.....
......
a
bunch
of
global
variable
value
.......
05.07.2018 00:15:41.954 [Windows Recognizer] Start executing condition 'Expression: containsElement(newList( "ch.gridvision.ppam.androidautomagic", "com.teslacoilsw.launcher" ), package_name)'
05.07.2018 00:15:41.958 [Windows Recognizer] End executing condition 'Expression: containsElement(newList( "ch.gridvision.ppam.androidautomagic", "com.teslacoilsw.launcher" ), package_name)' with return value true
05.07.2018 00:15:41.958 [Windows Recognizer] Flow continues executing with the next step.
05.07.2018 00:15:41.958 [Windows Recognizer] Start executing action 'Sleep: 5s (keep device awake)'
05.07.2018 00:15:41.958 [Windows Recognizer] Action 'Sleep: 5s (keep device awake)' Sleeping for 5s (keep device awake)
05.07.2018 00:15:42.998 [Windows Recognizer] Stopping execution due to stop-execution policy
05.07.2018 00:15:43.001 [Windows Recognizer] Action 'Sleep: 5s (keep device awake)' sleep interrupted
05.07.2018 00:15:43.001 [Windows Recognizer] End executing action 'Sleep: 5s (keep device awake)'

==================

Everytime the flow execute, the first line always tell that the flow execute with the Context{global...... And I have a bunch of glovar there, most of them are map/list, so very long. They will show up and always makes the log harder to read, especially to spot the beginning of the execution. I wish there is a way I can uncheck an option and supress the glovar message. I know it will be harder to spot what's going wrong when glovar is involved inside the flow. But We have debug dialog for that purpose already. So I think the glovar can be hidden from the log, of course it is should toggleable in case we need to it again.

Then the whole long value of the date, time down to miliseconds, including the flow name.
05.07.2018 00:15:41.953 [Windows Recognizer]
I think those should be customizeable too. It is too long and eating half of the log windows already, while most them are similar. Flow name always stays the same already when we view the log inside a flow, shouldn't be needed anymore. For date time, most of our flow execution 98% of the time finished within seconds, so the date should be unnecessary. Even the hour and minute, most of the time is not used. So It would be nice if we can specified what information we can show there.

Maybe using some pattern character. the default pattern is

Code: Select all

dd.MM.yyyy HH:mm:ss.SSS {flow_name} {log}
Which shows up as the first one above.

We can then specify something like

Code: Select all

ss.SSS {log}
it will show up as
41.954 Start executing condition 'Expression: containsElement(newList( "ch.gridvision.ppam.androidautomagic", "com.teslacoilsw.launcher" ), package_name)'
41.958 End executing condition 'Expression: containsElement(newList( "ch.gridvision.ppam.androidautomagic", "com.teslacoilsw.launcher" ), package_name)' with return value true
41.958 Flow continues executing with the next step.
41.958 Start executing action 'Sleep: 5s (keep device awake)'
41.958 Action 'Sleep: 5s (keep device awake)' Sleeping for 5s (keep device awake)
42.998 Stopping execution due to stop-execution policy
43.001 Action 'Sleep: 5s (keep device awake)' sleep interrupted
43.001 End executing action 'Sleep: 5s (keep device awake)'


This makes the flow much shorter and easily to spot the problem and flow execution.

Or much better, if there is another extra option to automatically deduct the rest of the time for the trigger time. In most cases, we only need to know how fast or how long it takes for the flow to finish. I sometimes try and see which script finished faster, especially when dealing with looping with more than hundreds of elements. Nested looping usually takes longer, but need to be crosschecked with the time taken. The original log won't be override, only the currrent flow log view is modified. When this "anchor triggertime" option turned on, all flow execution will be measured starting from 00.000. so the above will be

00.000 Start executing condition 'Expression: containsElement(newList( "ch.gridvision.ppam.androidautomagic", "com.teslacoilsw.launcher" ), package_name)'
00.004 End executing condition 'Expression: containsElement(newList( "ch.gridvision.ppam.androidautomagic", "com.teslacoilsw.launcher" ), package_name)' with return value true
00.004 Flow continues executing with the next step.
00.004 Start executing action 'Sleep: 5s (keep device awake)'
00.004 Action 'Sleep: 5s (keep device awake)' Sleeping for 5s (keep device awake)
01.044 Stopping execution due to stop-execution policy
01.047 Action 'Sleep: 5s (keep device awake)' sleep interrupted
01.047 End executing action 'Sleep: 5s (keep device awake)'


I can see easily see now that the expression took 4 ms to complete and continue to next element execution, much easier to troubleshoot and to determine if the script/element is running at its best perfomance. When new trigger occured, the first execution will be 00.000 again. But the real log still show the real time, the 00.000 only shows up in this flow's log view only.

Proceeding to the next customization is the coloring. Probably we can have some coloring for certain logic. Example, when the flow continue with true, next line will be green, while false will be red. New starting execution will be light blue. Stopped execution will be orange. Error will shown in gray. But i am afraid this will affect the log perfomance, so if should be toggleable if it is implemented.

Last one is to supress the error exception. When encounter exception, usually there will be about a dozen of error lines, most of the time those error are meaningless to us. While the real error is already shown in the first line. So if we can supress those exception lines, we can spot the real error much easier.


Summary
To summarize, the whole customization of the log are :
1. Option to supress the Global variable context
2. Customize the date time and whether to show flow name in the log
3. option to use triggertime as 00.000 in the log view
4. Coloring the log based on the logic
5. Supress the error exception.

These should be toggleable or customizeable option located in the setting > logging.

I am sorry if i request too many at once. But I thought they all fall into the same topic, so it is better to customize all at once rather than requesting one by one, making the planning of the big picture much more complicated.

Thank & Regards,
Desmanto
Index of Automagic useful thread List of my other useful posts (and others')
Xiaomi Redmi Note 5 (whyred), AOSP Extended v6.7 build 20200310 Official, Android Pie 9.0, Rooted.

Miller777
Posts: 1
Joined: 28 May 2018 21:41

Re: Customize the log

Post by Miller777 » 11 Sep 2018 23:05

Hi Martin!


I join the feature request of Desmanto.

Is it possible to make a line break while browsing the log so that there is no horizontal scroll?

vertigo
Posts: 147
Joined: 28 Oct 2018 00:28

Re: Customize the log

Post by vertigo » 12 May 2020 04:44

I'd also like to +1 this, and to add to the ideas already presented, here are some of my ideas of possible changes:

- Make glovars show as a link that can be tapped to show/hide them
- Hide glovars in the log but show them in the log file
- Coloring: already covered quite well, but I would just add that minimally I think the trigger and the end executing action lines, especially action name and return value, should be highlighted, and that red/orange might be too difficult to differentiate, and maybe errors should be red and false in gray or yellow (of course, allowing customization of the colors would be best)
- Word wrap, as suggested by @Miller777, is an excellent idea
- Spacing or separators between flow executions so they don't run together
- This might be too complicated, but I think it could be tremendously helpful: add a feature where points in the flowchart can be marked and those points will also be marked in the log, to make it easier to track the progress through the flow in the log

User avatar
Hit
Posts: 91
Joined: 20 Jan 2020 11:31

Re: Customize the log

Post by Hit » 12 May 2020 07:15

Hi Martin and everyone. I suggest option to disable the log (optional ON/OFF). Thank you!

vertigo
Posts: 147
Joined: 28 Oct 2018 00:28

Re: Customize the log

Post by vertigo » 12 May 2020 08:19

Hit wrote:
12 May 2020 07:15
Hi Martin and everyone. I suggest option to disable the log (optional ON/OFF). Thank you!
Why would you want to disable it? If you don't need it, you don't have to use it, so what benefit would there be to disabling it entirely?

User avatar
Hit
Posts: 91
Joined: 20 Jan 2020 11:31

Re: Customize the log

Post by Hit » 12 May 2020 08:30

vertigo wrote:
12 May 2020 08:19
Hit wrote:
12 May 2020 07:15
Hi Martin and everyone. I suggest option to disable the log (optional ON/OFF). Thank you!
Why would you want to disable it? If you don't need it, you don't have to use it, so what benefit would there be to disabling it entirely?
:) May be someone known (:

User avatar
Hit
Posts: 91
Joined: 20 Jan 2020 11:31

Re: Customize the log

Post by Hit » 12 May 2020 08:58

vertigo wrote:
12 May 2020 08:19
Hit wrote:
12 May 2020 07:15
Hi Martin and everyone. I suggest option to disable the log (optional ON/OFF). Thank you!
Why would you want to disable it? If you don't need it, you don't have to use it, so what benefit would there be to disabling it entirely?
Or may be just like: Toggle => Auto logging off

Now in script you still can use log("something") function to log() what you want only and some things else

That could be a good idea but I just want a setting to turn Auto logging off

vertigo
Posts: 147
Joined: 28 Oct 2018 00:28

Re: Customize the log

Post by vertigo » 12 May 2020 18:37

That sounds similar to my last idea. So in addition to adding logging "marker actions" to add to the flow which would be highlighted somehow in the log, they could also be used to turn logging on and off between them, so logging could be disabled except between a "Start Logging" and "Stop Logging" action, or it could be enabled and have "Log marker" actions with color options, which would draw a line of the selected color in the log at that point, or something like that.

And actually, I think the best way to implement this would be not with a new action, which could be problematic to add after the flow is already largely built, but as an option when selecting lines between components. So instead of just a pencil and trash icon, there could be a log icon as well, which would provide the options for enabling, disabling, or marking the log at that point. That sounds like it would work really well.

User avatar
Hit
Posts: 91
Joined: 20 Jan 2020 11:31

Re: Customize the log

Post by Hit » 13 May 2020 01:26

I think you misunderstood what I want. I just want a clean log! Yes, I call it the void for example.

I don't known if how many change available in the next update but minimal change can be achieved.

So let say I want a button in the log to disable and enable log or Auto log.
May be script log still work or not I don't really mind, I think it's about the developer, he know what good or bad.

That's all for now. I didn't think any further

vertigo
Posts: 147
Joined: 28 Oct 2018 00:28

Re: Customize the log

Post by vertigo » 13 May 2020 02:07

I didn't miss that, though, admittedly, I still don't understand why you'd want no log at all, since if you don't want to see it, you simply have to not open it. I'm not saying I'm against it, just that I don't understand the need. And Martin will likely want to know the reasoning before implementing it.

My point was that your comment
Now in script you still can use log("something") function to log() what you want only and some things else
sounded similar to what I had suggested, only combined with the ability to disable logging (and the only reason I can see for disabling it). My idea was to add the ability to mark connections to show more prominently in the log, which would still contain everything else, and your comment at least sounded like doing essentially the same thing, but showing only the parts of the flow between start and stop logging markers. In other words, the user would have two additional options: show everything, but highlight specified portions, or show nothing except specified portions.

Locked