This could read ‘newbies’ vs ‘old-farts’ (with myself in the ‘old fart’ category) but this does not sum up the two camps.
Decide for yourself. (note there was some heavy editing to acheive this from my system, there ‘may’ be mistakes 
which I shall try to correct).
I belong to the group who believe that the GUI AE (Automation Editor / Device Editor - whatever the official term) is a tool to allow people who do not want to ‘get too involved’ in the ,nitty gritty, to set up simple automations etc. – turn this light on at this time, turn this on at sunset, turn this off two hours before dawn etc.
From this it will generate code that the user looks at, so that when their needs become greater they can work out what ‘could’ be the possible ways of achieving that. (This assumes they look). And that by learning in this way they read other people’s examples and ‘extend’ into more complex arrangements (in line with their growing need for it)
I apologise to Mobisat for using him as an example of the ‘newbie effect’ but his recent thread crystallised my thoughts and was the trigger for this topic.
He has grown since he first appeared and is less adversarial to the ‘traditional coding methods’ but I still feel that he comes across as affronted / frustrated / resentful that he can’t do what he wants to do and that we are pushing him down a path that he does not want to adopt.
So my challenge is “Can any GUI Guru replicate the functionality he requires in that thread ?”
If not, it seems that we are acknowledging that the GUI Editor is a crutch to help newbies BUT they should be advised of such so they do not exclusively rely on it and actively learn how to support themselves. And also not annoy the people who are trying to help them. (i.e. – read Tinkerer’s Sticky).
So to restate the problem; he wants to know how to record when his boiler was last ‘on’ and also when it was last ‘off’ – further, he wants to display it a particular format.
So stealing from the work that Taras and I did on that thread : -
(I’m sure that these could probably be polished further (feel free to suggest any improvements 
) )
Capturing the event times -
input_datetime:
id_boiler_last_on:
name: Boiler Last On Time
has_date: true
has_time: true
id_boiler_last_off:
name: Boiler Last Off Time
has_date: true
has_time: true
automation:
- alias: 'Boiler state time'
trigger:
platform: state
entity_id: switch.boiler
action:
service: input_datetime.set_datetime
data_template:
entity_id: input_datetime.id_boiler_last_{{ trigger.to_state.state }}
datetime: "{{ now().strftime('%Y-%m-%d %H:%M:%S') }}"
The ‘times’ then appear as “2020-05-17 18:51:48” and will remain fixed until updated by the automation
Okay, this got the ‘times’ but it’s not very easy to work out how long ago each of those were so you ‘could’ set up a sensor to display that information, Along the lines of : -
sensor:
- platform: template
sensors:
s_boiler_last_on:
entity_id: sensor.time, input_datetime.id_boiler_last_on
friendly_name: Boiler Last On
value_template: >
{% set dif = as_timestamp(now()) - as_timestamp(states('input_datetime.id_heat_last_on')) %}
{% set ds = (dif // (24*60*60)) | int %}
{% set sdif = dif | timestamp_custom('%H:%M' ,false) %}
{{ ds ~ ' days ' ~ sdif }}
icon_template: "{{ 'mdi:clock' }}"
s_boiler_last_off:
entity_id: sensor.time, input_datetime.id_boiler_last_off
friendly_name: Boiler Last Off
value_template: >
{% set dif = as_timestamp(now()) - as_timestamp(states('input_datetime.id_heat_last_off')) %}
{% set ds = (dif // (24*60*60)) | int %}
{% set sdif = dif | timestamp_custom('%H:%M' ,false) %}
{{ ds ~ ' days ' ~ sdif }}
icon_template: "{{ 'mdi:clock-outline' }}"
These give you time since last on/off e.g. “2 days 14:06” and will update every minute to re-evaluate.
(I think, if I wrote this again I’d take the ‘year’ subtract 1970 and multiply by 365 and add %j -1 (not 100% sure though) - Edit: I changed it to accomodate years (i.e. allow days > 365, well, you never know ! ).
But Mobisat wanted a specific format so let’s go with that, either way we need to capture the result in some way, we used input_datetime’s above (but we ‘could’ have used input text’s and populated the result in there). So the sensors become : -
sensor:
- platform: template
sensors:
s_boiler_last_on:
entity_id: input_datetime.id_boiler_last_on
friendly_name: Boiler Last On
value_template: >
{% set tstmp = as_timestamp(states('input_datetime.id_boiler_last_on')) %}
{{ tstmp | timestamp_custom('%d-%m-%Y %H:%M') }}
s_boiler_last_off:
entity_id: input_datetime.id_boiler_last_off
friendly_name: Boiler Last Off
value_template: >
{% set tstmp = as_timestamp(states('input_datetime.id_boiler_last_off'))) %}
{{ tstmp | timestamp_custom('%d-%m-%Y %H:%M') }}
This gives you : “17-05-2020 17:51:13” and will remain fixed until updated by the automation
And for the input_text’s (with just minor adjustments to the original automation) becomes : -
input_text:
input_text:
it_boiler_last_on:
name: Boiler Last On Time
icon_template: "{{ 'mdi:clock' }}"
it_boiler_last_off:
name: Boiler Last Off Time
icon_template: "{{ 'mdi:clock-outline' }}"
automation:
- alias: 'Boiler state time'
trigger:
platform: state
entity_id: switch.boiler
action:
service: input_text.set_value
data_template:
entity_id: input_text.it_boiler_last_{{ trigger.to_state.state }}
value: "{{ as_timestamp(now()) | timestamp_custom('%d-%m-%Y %H:%M') }}"
This gives you : “17-05-2020 17:51:13” and will remain fixed until updated by the automation
Can Anyone Do Any Of That With The GUI ???
If you can (or maybe especially if you can’t) then point people at this thread and get them to understand that ‘hand written’ is sometimes the only way OR Prove Me Wrong (I like to be educated) (other than just by pasting these templates into gaps in the relevant box ! )
So learning templates gets you a LONG way. And the GUI editor is not a panacea.
AND the Template Editor is “your best friend”
Edit: Though finity’s EPIC time manipulation thread is A pretty damn good resource too
Though maybe could do with a follow up topic to simplyfy translating ‘this to that’ with HA entities and attributes.