First post and I’m a 67 year old newbie so please be gentle with me.
Usage case
Our hallway can be very dark on an overcast day. We have a display cabinet with lights which are switched via a smart plug. I have bought and fitted a light level sensor and determined that I would like the cabinet lights to come on if the light level goes below 10 and, (to introduce some hysteresis) go off when the light level is above 11. All this to happen only between sunrise and sunset.
But, it’s not working. Currently, the light level is showing as 240, and it’s between the hours of sunrise and sunset, so the cabinet light ought to be off , but it’s on. No doubt, I have done something stupid but I’m unable to see what that stupid thing is.
Here is the code for the automation for turning the light off.
Fires when the numeric value of an entity’s state (or attribute’s value if using the attribute property) crosses a given threshold. On state change of a specified entity, attempts to parse the state as a number and fires if the value is changing from above to below or from below to above the given threshold.
So this will only trigger if the value changes from 11 to above, not if it’s aleady above 11.
Maybe try a Time pattern trigger that runs every minute und use the light level as a condition.
Did you try to write the condition like this (not sure that the way you wrote it is true at some point of time) ?
condition:
condition: state # from sunset until sunrise
entity_id: sun.sun
state: 'below_horizon'
Here is an extract of the documentation:
Note that if only before key is used, the condition will be truefrom midnight until sunrise/sunset. If only after key is used, the condition will be true from sunset/sunrise until midnight . Therefore, to cover time between sunset and sunrise one need to use after: sunset and before: sunrise as 2 separate conditions and combine them using or .
I was using the GUI to generate the code - I only switched to yaml so that I could paste the output as I don’t consider ,myself to be proficient enough the write the code in yaml.
I think @VDRainer has explained why it isn’t working as I had hoped - i.e the trigger is when the value crosses a threshold and not just HA “polling the value” as I assumed would be the case. The cabinet light is also triggered by other automations so it is likely that this could change the state of the light which would then remain on (or off) until the light level crosses a threshold again. So I’ll try the time pattern trigger to force HA to poll the sensor at (say) 1 minute intervals and switch the light depending on the lux level at that time.
Or trigger on any change in light level and move the light level constraints to the conditions. This would reduce the number of triggers (even though it doesn’t matter performance wise).
@deckingman
Your condition doesn’t work. Read this part of the docs, there they show exactly your code as an example that doesn’t work. You need to either split it in two conditions or use the elevation as suggested by @browetd.
I’ve read that part of the docs several times. I guess it makes some sort of perverse sense to someone who writes code, but to a mere mortal like me, it does not make sense. Presumable then, I can’t use a fixed time with that format either e.g
condition:
condition: time
after: 07:00
before: 16:00
Applying the same sunrise/sunset logic, this would always evaluate as false yes? And so I must always use two conditions to set anything which is between two values yes?
That being the case, might it be possible to have the UI altered to prevent one from entering such erroneous parameters? As things stand, after selecting condition type as “Sun”, the UI allows one to select both before sunset and after sunrise so one’s natural “common sense” would lead one to think that means between those lower and upper values. Yet the yaml code generated from the UI does not have a “condition - or” and from what has been posted here, that will always evaluate as false.
I’ve taken out all time conditions so all I have left is the lux level and I’ve set a time pattern trigger for 1 minute intervals, but still I can’t get this to work. Currently the sensor is showing a lux level of 2.0 but the cabinet lights won’t come on. They do however come on if I ignore the lux sensor and simply use time as a trigger or I can turn them “manually” by using the slider in the UI to toggle the switch. So the smart switch s working and the lux sensor seems to be working too.
Here is my latest attempt which does not work - the lux level is shown as being at 2.0.
description: Turns on cabinet light during the day if light level is low
trigger:
- platform: time_pattern
minutes: '1'
condition:
- condition: numeric_state
entity_id: sensor.lumi_lumi_sen_ill_mgl01_illuminance
attribute: unit_of_measurement
below: '10'
action:
- type: turn_on
device_id: f6f28f43e390cbcd3e422478a1d1e1a6
entity_id: switch.cabinet_light
domain: switch
mode: single
I’d be grateful for any advice on how I can resolve this.
Going back to the sunrise/sunset condition which you say I have wrong, the documentation states quote …" When both keys are used, the result is a logical and of separate conditions.".
So if I have before sunset AND after sunrise, then why is that wrong? The documentation goes on to say quote …
" Note that if only before key is used, the condition will be truefrom midnight until sunrise/sunset. If only after key is used, the condition will be true from sunset/sunrise until midnight . Therefore, to cover time between sunset and sunrise one need to use after: sunset and before: sunrise as 2 separate conditions and combine them using or ."
That makes sense because the time period between sunset and sunrise spans midnight. But I’m not doing that. I’m trying to use the time period between sunrise and sunset (not the time period between sunset and sunrise) as a condition which does NOT span midnight. Surely it should be before sunset AND after sunrise should it not? So why do you say that I have to use two separate conditions with an “or” statement? Surely any time after midnight would be before sunset so then using an “OR” would mean the condition would be true at (say) 1 minute past midnight regardless of the fact that sunrise has not yet happened because that would be another “OR” condition.
Please explain how using before sunset ORafter sunrise will limit the condition to be true only between sunrise and sunset which is the condition parameters that I’m trying to achieve. It seems to me that any time after midnight but before sunset will be true. Or any time after sunrise until midnight will also be true. Therefore one or the other will always be true and so the condition(s) evaluated as “OR” will always be true which does not limit the time period to anything at all.
That means the Numeric State Trigger should not monitor the sensor’s state for changes but one of its attributes called unit_of_measurement. That’s a bizarre choice (an error really) because that attribute doesn’t report the illuminance level; it simply indicates the units used to represent the level, typically lux for illuminance. Once set, it never changes (and isn’t a numeric value) so this trigger will never activate.
Sorry to add to any confusion here but due to the threshold cases ie if its already luminence 8 (what are these units ? if it’s lux that VERY dark) then it wont ever trigger as below 10
So what I’d do is set up a binary sensor with all your conditions.
Well my conditions would be : -
sun above the horizon and rising
OR time before 22:00 AND the sun is falling, so I can admire it as I go to lock the front door (as the sun set at 15:55 today )
AND Lux below given threshold ie lux <= 12 (ie an absolute state, not a trigger)
Then just have the light follow the status of the sensor
I also assume your light sensor is nowhere near the light as otherwise the light comes on the sensor sees it and the lights goes off straight away, ony to find it’s now dark so …
@123. Thanks. I copied your code exactly and that seems to have fixed it. Ref the “attribute thing” - that was me being a stupid newbie. Not knowing anything about yaml, I was using the UI editor and saw that attribute was optional, just as description is optional. So I didn’t realise that that it would have any effect on the operation of the device and just assumed that it would purely descriptive.
For info, after taking the attribute out, my code still did not work using numeric value but your code using state - entity id - then the condition in curly braces, did work. Also for info, after saving the automation then going back into the editor, I noticed that the yaml code got changed. In stead of the first condition being simply trigger state in curly braces, it got changed to being state:template, then value_template with the code in curly braces.
For completeness sake, here is the yaml code that I ended up with
alias: Cabinet Lights Daytime Off
description: Turns off cabinet light during the day if light level is low
trigger:
- platform: state
entity_id: sensor.lumi_lumi_sen_ill_mgl01_illuminance
condition:
- condition: template
value_template: '{{ trigger.to_state.state | int >11 }}'
- condition: state
entity_id: sun.sun
state: above_horizon
action:
- service: switch.turn_off
entity_id: switch.cabinet_light
mode: single
And of course, I have another automation which turns the light on if the luminance is<10
@Mutt To “un muddy” the waters, I did spend quite some time finding an appropriate position to place the sensor such that it wouldn’t be affect by any light sources other than the ambient light level from the sun. I also spent some time monitoring the values that it was reporting, before setting up the automation. A value of <10 is indeed what the sensor reports on a very overcast day - hence the desire to have the light come on. After sunset, the value drops to 2 or less. Of course, there is no guarantee that such a cheap cheap sensor is in any way truly accurate in terms of actual lux levels, but those are the numbers that it reports.
Also, I have other automations which will control the light. One will turn on the light at sunset until 22:30 and another will turn on the light after 22:30 if movement is detected. So the cabinet is always lit between sunset and bedtime and again, if anyone walks though the hall or up and down stairs during the night (as a sort of night light).
Excellent,
Given the choice between accuracy and repeatability, I’d go for repeatability every time.
It’s good that you’ve thought about the additional times required on and that it works for you is good.
I spent some time going through my automations and streamlining the actions, I reduced (for the same functionality) my automations by about a third, changed some scripts (number remained about the same) binary_sensors nearly doubled but my processor usage dropped by 50%
So as you’ve found a bit of planning and re-evaluation (monitoring the results) pays dividends.
Good luck with your journey
@Mutt. Thanks. I’m a mechanical engineer (retired) by training, so writing and understanding code is not my forte, but a methodical approach to diagnostics is. My main interest is 3D printing - specifically the design and construction of machines so if you are interested in that field, you might come across the user name “deckingman” on various forums or you might even stumble upon my blog or YouTube channel. Home automation is something fairly new although in the past, I have built few arduino based devices to do certain tasks. I’m still deciding between Google home, Amazon Alexa and Home assistant (I have all 3 platforms). I’m leaning towards using Home assistant exclusively but I’m as yet undecided. It depends on how reliable it is. I do a have a problem with some TP link Kasa plugs which Home Assistant keeps marking as “unavailable” yet they work fine with the Kasa app or with Google/Alexa. This seems to be an ongoing problem with HA so I may have to abandon it. But then I probably wouldn’t be able to use things such as light sensor to act as triggers. So…
The Automation Editor changed the Template Condition from shorthand notation to the traditional (more verbose) format. They’re functionally equivalent.
FWIW, I don’t use the Automation Editor because it has limitations and some undesirable behaviors (undoing shorthand notation is one example, stripping out comments is another).