I have working automation that is turning the light when the motion sensor detects movement.
- alias: Turn on the light
trigger:
platform: state
entity_id: binary_sensor.move_corridor
to: 'on'
condition:
- condition: template
value_template: >
{% set n = now() %}
{% set n = (n.hour*60+n.minute)*60+n.second %}
{% set ts_from = state_attr('input_datetime.light_from_time', 'timestamp') %}
{% set ts_to = state_attr('input_datetime.light_to_time', 'timestamp') %}
{{ n > ts_from or n < ts_to }}
action:
- service: homeassistant.turn_on
entity_id: switch.light_corridor
Now Iād like to remove two input_datetime and use sun.
The idea is to turn on the light between sun setting and rising (and of course if the motion sensor detects the movement)
here is my current not working code:
{% set offset_rising = 30 %}
{% set offset_setting = -20 %}
{% set rising= as_timestamp(states.sun.sun.attributes.next_rising) + (offset_rising *60) %}
{% set setting= as_timestamp(states.sun.sun.attributes.next_setting) + (offset_setting *60) %}
{{(rising) | timestamp_custom('%H:%M:%S') }}
{{(setting) | timestamp_custom('%H:%M:%S') }}
{% set n = now() %}
{% set n = (n.hour*60+n.minute)*60+n.second %}
{{rising}}
{{setting}}
{{n}}
{{ n > rising or n < setting}}
the problem is that rising and setting have full date in them, I need to get only time to be able to calculate the timestamp from hours, minutes and seconds.
How can I remove date from states.sun.sun.attributes.next_rising and calculate timestamp only for time?
Mark I looked at this, but when using above_horizon and below_horizon I wonāt be able to add any offset.
For example, I want my motion sensor to work between setting -0,5 hour and rising +0,5 hour.
Iām trying to calculate timestamp from hours, minutes and seconds, but I canāt do that (donāt know how) from states.sun.sun.attributes.next_rising
Iām able to get hour property from n, but not from s.
According to the docs (https://www.home-assistant.io/integrations/sun/) next_rising and next_setting contain date and time in UTC.
How can I convert those values to local time and then get hours, minutes and seconds for them?
{% set setting = states.sun.sun.attributes.next_setting %}
{{setting}}
{% set setting = strptime(states.sun.sun.attributes.next_setting, '%Y-%m-%dT%H:%M:%S%z') %}
{{setting}}
{{setting.hour}} {{setting.minute}} {{setting.second}}
but it is very ugly - I must use strptime with specific format.
At first, I thought that states.sun.sun.attributes.next_setting will return date and time (as written in docs), but it is returning a string. This is really weird. I get a string, that I must convert to datetime.
Iām not sure if the value is in my current time zone, Iāll check that and get gack with fully working code.
That was the piece I had missing.
Now the full template looks like this:
{% set offset_rising = 20 %}
{% set offset_setting = -30 %}
{% set n = now() %}
{% set n = as_timestamp(n) | timestamp_custom('%H:%M:%S', true) %}
{% set rising = as_timestamp(states.sun.sun.attributes.next_rising) | timestamp_custom('%H:%M:%S', true) %}
{% set rising_offset = (as_timestamp(states.sun.sun.attributes.next_rising) + (offset_rising *60) ) | timestamp_custom('%H:%M:%S', true) %}
{% set setting = as_timestamp(states.sun.sun.attributes.next_setting) | timestamp_custom('%H:%M:%S', true) %}
{% set setting_offset = (as_timestamp(states.sun.sun.attributes.next_setting) + (offset_setting *60)) | timestamp_custom('%H:%M:%S', true) %}
now: {{n}}
rising: {{rising}}
rising+offset: {{rising_offset}}
setting: {{setting}}
setting+offset: {{setting_offset}}
active: {{ n < rising_offset or n > setting_offset}}
The idea is to have a motion sensor working from the sunset to sunrise, but with offsets, for example, start 30 minutes before sunset and end 20 minutes after sunrise. Those two offsets will be configurable from the UI, thatās why I had to use a template.
First, using adjustable offsets from sunrise and/or sunset typically implies youāre trying to compensate for the fact that it gets light/dark a different amount of time from sunrise/sunset during different times of the year. The usual way to solve that problem is to use the sunās elevation instead of offsets from sunrise/sunset. See the sun elevation condition.
Next, if you do want to use a template to calculate offsets from sunrise/sunset, youāll discover that the sunās next_rising and next_setting attributes are not consistent throughout the day. In fact, they donāt indicate todayās event, they indicate the next event. So in the beginning of the day next_rising, for example, will indicate when the sun next rises, which will be todayās sunrise. However, once that time passes (i.e., once the sun has risen) it will be tomorrowās sunrise. This often plays havoc with templates when used in automation triggers and/or conditions.
If you still want to calculate offsets from sunrise/sunset in templates, then you might be interested in my sun2 custom integration. It creates individual sensors for each sun related event of interest which change only at midnight and are therefore āstableā throughout the day. E.g., here is what the sunrise sensor looks like:
Youāll see that the sensorās state is todayās sunrise as an ISO formatted datetime string, and it has attributes for yesterday, today & tomorrow which are all Python datetime objects. So itās very easy to compare to the current time, e.g.:
If youāre just looking for light levels outside - you could either setup a sensor outside to measure the actual levels - or if not that route you could also use @pnbrucknerās illuminance sensor here: https://github.com/pnbruckner/ha-illuminance
Personally, I went the former route and setup a multi-sensor on the front porch. This has the added benefit of being able to turn on my front porch lights when thereās motion and the light level is below a certain threshold.
Anyhow, Iāve not use the illuminance sensor, but Phil might be better able to comment on it.
@pnbruckner I want to add offsets because I have motion sensors in two rooms. One has more natural light than the other. Thatās why I want to have an adjustment.
Iāll try your integration. the idea is to have a motion sensor working between todayās sun setting and tomorrowās rising. Your integration updates ad midnight so if I make a rule like so: now > today_sun_setting + adjustment && now < tommorow_sun_rising - adjustment
should work just fine especially that yours is returning DateTime!
@Markus99 I was thinking about illuminance sensor, but I have wires in a very shaded place, so I still would have to add adjustments and I am a bit afraid of the moisture.
Right now I use Wemos with waterproof DS18B20 to measure outside temperature. Wemos is in a waterproof case, only DS18B20 is outside. I can add BH1750 but it must be put outside of the box. Wonāt it damage the sensor and the Wemos? How do you secure the multisensor from moisture and bad weather conditions?
I have a covered front porch and was able to find a spot, completely out of the elements (wind/rain) to mount a ZWave Zooz Multi-Sensor. Itās still able to see motion at the front door and I just adjust the light levels (illiuminance) to compensate for it being under cover. FWIW, I also have an ZWave Aeotec MultiSensor 6 that I used inside the house - and both perform well. Hope this helps!
That Zooz sensor looks great, but I have no experience with ZWave, so I prefer WIFi and MQTT for now.
Iām building sensors on my own (low budget), but Iāll write those names down, so when I decide to give ZWave a try Iāll order them. What USB Dongle do You use?
That is, now is either after sunset (and before midnight), or now is (after midnight and) before sunrise. A positive offset means after the event, and a negative offset means before the event.
Interesting. I have exactly the same setup, except I have my Zooz inside and my Aeotec outside. I bought the Zooz first and tried using that outside, but discovered it has a very limited dynamic range. It would saturate at 100 when the light level was still very low. So then I bought the Aeotec and found it works much better outside. It has a much larger dynamic range and almost never saturates, while still giving useful readings at very low light levels, too. Turns out the Zooz works pretty well for me inside. It still saturates often, but the limited dynamic range seems to be much better suited to the range of light levels inside.
Oh, and I had a similar issue with the PIR sensor. The Zooz was way too sensitive. It kept picking up cars driving by, even when I had it almost pointed at the ground, whereas the Aeotec works much better for this, too. Again, Zooz seems to work better inside and the Aeotec seems to handle the outside conditions better (although Iām sure it would work well inside, too.)
I am currently using a SmartThing hub for my ZWave / Zigbee network. This isnāt ideally how Iād like to be doing it - but I like the fact itās not rebooting my ZWave network everytime HA has to reboot. Some will say this isnāt a big deal, so itās just my personal preference I suppose.
I do also have an Aeon Labs ZWave Stick plugged into my NUC which has only a single device connected. I used this to reboot my home router when the modem <-> router loses its gigabit connection. I just havenāt bothered to move all my ZWve devices (30+) onto the NUC. More for lack of time, preference to not reset the ZWave network constantly than anything else - oh and I have a handful of Zigbee devices that Iād have to leave on SmartThings at that + a large dose of āif it aināt broke donāt fix itā.
@pnbruckner I installed my Aeotec sensor in our master bath first and have it mounted where I have a USB cable powering it to never worry about battery issues (toggles bath fan depending on humidity mostly). Found a great deal on the Zooz somewhere so bought it for kicks and ended up throwing it outside to do the front porch lights - but donāt do much else with it (and havenāt had the time to compare them - but love your thoughts on each).
@pnbruckner I know that this issue is a bit old, but somehow this does not give me peace.
Iāve recently found your two PR (24912, 24810). Both add template support.
I started wondering: would it be possible to add after_offset_template and before_offset_template to sun integration. Or add support for templates in those two properties (without adding two extra properties)
What do You think?
Also maybe it would be useful to allow specifying hours, minutes and seconds in offset properties. So my automation would look like this:
- alias: Turn on the light
trigger:
platform: state
entity_id: binary_sensor.move_corridor
to: 'on'
condition:
- condition: sun
after: sunset
after_offset:
- minutes: "{{ states('input_number.minutes_offset')|int }}"
action:
- service: homeassistant.turn_on
entity_id: switch.light_corridor
I can try implementing this (if this is even possible ) but Iād like to know the opinion of someone who added similar functionality in other places.
I think adding template support to the before_offset and after_offset parameters of the sun condition would be reasonable and not difficult to implement. Though the problem would arise, I suspect, that people would then expect/want the same for the sun trigger, and that is more problematic.
The question becomes, why would you want to change the offsets? If it is because they need to change as the sunās route changes throughout the year, then you get into the old argument that using the sunās elevation (and maybe azimuth) make more sense than sunrise/sunset with variable offsets.
especially that yours is returning DateTime!
) but Iād like to know the opinion of someone who added similar functionality in other places.