Okay, There’s a LOT to answer here. The ‘forum software’ doesn’t particularly like ‘multiple answers’ to a single post so I’ll probably reply once and edit it (as you’ve seen) as each step comes up and I address it (so keep checking the thread as you may not get notifications)
Single Parent Dad, Two Girls, Lockdown Project (an interesting / biology / engineering / photographic lockdown project (Proper STEM - I approve) ) = ‘hero’ in my book (but I have low standards 
) (the equal of the hamster odometer project I’ve seen here too ! )
I’m in the UK but that doesn;t really matter, we have a LOT of excellent members from Oz (to name but a few : tom_l , kanga_who and DavidFW1960 + many others )
One of the biggest obstacles in helping people with automations is overcoming their premise’s (that’s not saying that I don’t have any myself) but about 1/3 of my career has been spent thus, discarding what “they think they want” to get them “what they need” so I generally ask a lot of “Why ?” questions (seeking forgiveness in advance)
Using quotes takes up a lot of space, so I’ll just copy : -
- “vegetative / flowering” - Okay, Why is that not : - “Flowering 12hr” and “Vegetative 18hr” just to make it crystal clear ?
- “The girls will set the light time” - is that related to 1. ? I mean how do you set the light ‘start’ time ? Do you really want a start time or is it at ‘sunrise’ or do you want the middle of the ‘on’ time to be ‘solar noon’ - how do you wish to proceed ? I see that you’ve set 14:00 and 20:00 as the output so working back you normally have 02:00 as the start time for both. Is there a reason for that ? Don’t you get any natural light ‘spill’ in that location that can then be topped up by the light ? or are you being ‘green’ in trying to use ‘low demand periods’ and therefore reduce generation/distribution demands ? Do the girls not check up on the plants ? When is that likely to be ? Do the lights need to be on at that time ? (you don’t need to answer any of the last. I just need you to consider them). - so (reconsider) start time ???
- “sensors have terrible ‘entity’ names” - Yeah ! making the names identifiable makes coding a LOT easier. (see later when I discuss VSC)
- A - Okay, B - Okay, C - Excellent D - In which case you are a star ! (Though I think the point of most home automation is not having to deal with it, let it get on with it and interact with it minimally (so tinkering with automations/scripts takes up ALL of your time rather than playing with the interface which then just becomes a universal remote control - For ‘me’ the interface is secondary (my opinion is all - a LOT disagree, as they like to ‘show off’ their fancy remote control )
- Okay I more or less processed as reading, so I just came across the 02:00 which I’d surmised above
So : -
Changing names - It’s easy with VSC, assuming we are using ‘sensor.temperature_158d0003928807’ as an example, Click on the entity anywhere in the UI, click on the ‘cog’, Open VSC and have it look at your ‘config’ folder via Samba (or however you use it, it should already be pointed there), copy the entiy_id (‘sensor.temperature_158d0003928807’), In VSC got to ‘Edit’ - ‘Replace in Files’, paste sensor.temperature_158d0003928807 into the ‘Search’ box and what you want to rename it as, in the ‘Replace’ box, Hit the ‘Replace All’ button, Copy what you typed into the ‘Replace’ box, Paste that into the entity_id in the browser box you should still have open, Save - Done !
It gets more complicated when you are changing ‘created’ entities as you ‘may’ need to (for example) Search for “temperature_158d0003928807” and replace. but be careful as I have entities such as input_datetime.id_heat_boiler_last_on_time and sensor.s_heat_boiler_last_on_time ie. pretty much the same name. The ‘id_’ denotes input_datetime and ‘s_’ denotes sensor to help differentiate (the ‘heat_’ denotes that the entity is configured in my ‘heat’ package, packages allow ALL items concerned with a particular ‘thing’ (your choice, room, occupancy, heating, etc. ‘as you think best’) to live in a ‘thing’ file so bed1.yaml or climate.yaml or media.yaml etc. within a package everything specific to that ‘thing’ is set - automations, scripts, input_booleans, binary_sensors etc. So I could send you an alarm_clock.yaml and providing you have the necessary dependencies set, eg sensor.time in that case, you have a working alarm clock. I could also send a lovelace card snipet so you can interact with it (editing that to match your needs)
The s_heat_, id_bed1_ etc. helps you identify things, find things and sort things (alphabetically) so I’ll use these conventions, edit as you see fit.
Your ‘sensor’, inherently this is ‘awkward’ to deal with as it’s not ‘standard’ (standard in this case means common UI elements with accepted means of conversion which is the bread and butter of the forum so lots of examples exist to copy from and adapt), so rather than : -
- platform: template
sensors:
time_grow_lamp_off:
friendly_name: "Grow lamp turn off time"
# unit of measurement: 'time'
value_template: >-
{% if is_state("input_select.growth_cycle", "Vegetative") -%}
20:00
{%- else -%}
14:00
{%- endif -%}
if you use an automation instead (with two input_datetime 's ) : -
- id: au_project_plant_growth_lamp_set
alias: Plant Growth Lamp Set
description: 'What it says on the Tin'
trigger:
- platform: state
entity_id: input_select.is_project_growth_cycle
- platform: state
entity_id: input_datetime.id_project_lamp_start
- platform: state
entity_id: input_datetime.id_project_lamp_finish
action:
- service: input_datetime.set_datetime
entity_id: input_datetime.id_project_lamp_finish
data_template: >
{# This is a comment #}
{# This template assumes '02:00' as the start time set from input_datetime.id_project_lamp_start #}
{# This will set input_datetime.id_project_lamp_finish, which will be manually editable but we could ... #}
{# ... just add another trigger, if that happens, to 'reset' the input_datetime.id_project_lamp_finish ... #}
{# ... back again, so it won't matter and it appears that it is 'fixed'. See trigger above #}
{% set strt = states('input_datetime.id_project_lamp_start') %}
{% set tsstrt = as_timestamp(now().strftime('%Y-%m-%d ' ~ strt)) %}
{% set drtn = 12 if is_state('input_select.is_project_growth_cycle', 'Flowering') else 18 %}
{% set tsfnsh = tsstrt + (drtn * 60 * 60) %}
{{ tsfnsh | timestamp_custom('%H:%M:00') }}
This is quite advanced, above introduces template comments, note that we convert the start time (anyday) to a specific instant so that we can get a specific instant in the future of that time, then convert it back to an ‘anyday’ value.
This will give you an ‘odd’ error going through DST changes, but you’d have that anyway and it wouldn’t go through that either in the duration 01:01 to 23:59 regardless.
The automation for then switching the lamp ‘on’ becomes : -
- id: au_project_plant_growth_lamp_on
alias: Plant Growth Lamp
description: 'What it says on the Tin'
trigger:
- platform: template
value_template: "{{ states('sensor.time') == states('input_datetime.id_project_lamp_start') [0:5] }}"
action:
- service: light.turn_on
entity_id: light.plant_growth_lamp
Your homework is to do the switch ‘off’ 
Note that if HA goes down at any switching point the light will remain in it’s previous state. There are ways of dealing with that (I’m also quite lazy). But if you restart because of a config change I used to just check if I’d missed anything and switch it manually.
Phew, that was a long one, I’ll let someone else get on the soap box.
“Oooops !” - Forgot to say, the automation (for setting the finish time) will trigger twice (as it sets ‘A’ then is triggered by ‘A’ ) but thereon ‘A’ doesn’t change so it won’t re-trigger. If you trust your ‘users’ not to mess with the finish time you could remove that trigger.
Oooops2 - VSC also can use ‘rainbow spacing’ and ‘rainbow brackets’ I really recommend the first (for yaml) and I find the second is pretty useful too.
Oooops3 - Again I don’t have these entities - so not tested in anger, but it passes config check and I’ve tested the template in the ‘Developer Tools’ - ‘Template’ section of HA (This is a godsend and should be used a LOT more by everybody) - get back with problems
)
. Then I use the service template to decide what to do with the heater. I much prefer how you managed to get ALL the logic for day and night bands AND heater control in the service template - and that’s where I’d like to end up!
)