Creating a rule using Sunset/Sunrise for outdoor lights
Hi all
Im trying to create a rule based on sunrise and sunset for my outdoor lights. I´ve been using Tellstick for this mission, but i want to get this function over to my Zipato controller. In the Tellstick UI, this is a simple task to get up and running.
This function will adjust the clock according to the sunrise and sunset times all year automatically. I don´t need to adjust anything.
I want the same function on my rule in zipato. The sunrise and sunset times should update it self and trigger the lights. Im a total newbie to this rule creation at zipato, but I'm trying to understand it. In the picture, you can see what i have tried to do. Can anyone give me some pointers if I'm totally off or am i going in the right direction?
Im happy to answer any question or give more details about the rule. It would be great to have this figured out once and for all :-)
The same question
I´ve been told they still work on sunset and sunrise as metering functions (and adviced me not to use it as a metering function)
So its easier to just use a planer to start something on sunset or sunrise (upper examples) or just use a variable, based on sunset or sunrise. With the pure weather function you also have no astro-offset. I use a variable (example below) which becomes 1 between 30 min past sunrise and 30 min before sunset (much better inside a home because at sunrise / sunset it is still dark in the house. That variable can be used in all of the other rules.
I´ve been told they still work on sunset and sunrise as metering functions (and adviced me not to use it as a metering function)
So its easier to just use a planer to start something on sunset or sunrise (upper examples) or just use a variable, based on sunset or sunrise. With the pure weather function you also have no astro-offset. I use a variable (example below) which becomes 1 between 30 min past sunrise and 30 min before sunset (much better inside a home because at sunrise / sunset it is still dark in the house. That variable can be used in all of the other rules.
Even if it has been fixed I would recommend a variable (because of the astro-offset) and its just a guess but I would rather use sunset and sunrise as shown in the attached picture because I wouldn´t expect your rule to work. I think sunset and sunrise can´t set themselves. But thats just my understanding of those metering functions. Perhaps someone here has a clue?
Even if it has been fixed I would recommend a variable (because of the astro-offset) and its just a guess but I would rather use sunset and sunrise as shown in the attached picture because I wouldn´t expect your rule to work. I think sunset and sunrise can´t set themselves. But thats just my understanding of those metering functions. Perhaps someone here has a clue?
Ups I think I´ve forgotten the "time of" tile. Can´t try it out right now, but I think thats the problem.
Ups I think I´ve forgotten the "time of" tile. Can´t try it out right now, but I think thats the problem.
Hey,
I am using a virtual switch "Tageslicht" (daylight) which is set to on in the morning by a scheduler with astro option and and in the evening to off with an other rule (also scheduler with astro). It works fine since a long time. I use this switch in a lot of rules to test for daylight. You can use it in your rule
when motion on
join
if daylight off
.....
else
....
is much easyer.....and easy to read
Hey,
I am using a virtual switch "Tageslicht" (daylight) which is set to on in the morning by a scheduler with astro option and and in the evening to off with an other rule (also scheduler with astro). It works fine since a long time. I use this switch in a lot of rules to test for daylight. You can use it in your rule
when motion on
join
if daylight off
.....
else
....
is much easyer.....and easy to read
I´m using the astro offset in scheduler config to create a virtual switch with sunrise in a rule, and one rule to create sunset.
This virtual switch is used in other rules.
I´m using the astro offset in scheduler config to create a virtual switch with sunrise in a rule, and one rule to create sunset.
This virtual switch is used in other rules.
hey guys, the best solution is as helle, andreas and klaus suggest, is to create a rule that makes a variable or virtual switch or virtual sensor that is based on a scheduler rule for sunset and sunrise. Then this variable/switch/sensor can be used in multiple rules without having to add in scheduler puzzles all the time. Also I do not think you can get a time between sunset and sunrise with Zipato rules. I think the sunrise and sunset just act as a point of time, not a type of meter.
If you need help configuring the astro and scheduler for a virtual sensor let us know.
hey guys, the best solution is as helle, andreas and klaus suggest, is to create a rule that makes a variable or virtual switch or virtual sensor that is based on a scheduler rule for sunset and sunrise. Then this variable/switch/sensor can be used in multiple rules without having to add in scheduler puzzles all the time. Also I do not think you can get a time between sunset and sunrise with Zipato rules. I think the sunrise and sunset just act as a point of time, not a type of meter.
If you need help configuring the astro and scheduler for a virtual sensor let us know.
Have a look at my comments on this topic for a possible way to make sunrise and sunset times into more usable variables.
https://community.zipato.com/topic/need-a-way-to-store-and-compare-datestimes#comment-26273
Have a look at my comments on this topic for a possible way to make sunrise and sunset times into more usable variables.
https://community.zipato.com/topic/need-a-way-to-store-and-compare-datestimes#comment-26273
I don't know what everyone else has found, but the "sunrise" and "sunset" values in the Zipato weather station seem, in fact, to be strings. If I copy those values to a virtual meter and try to compare them to other date values, they always behave as 0. If I send them to an email, the reason becomes clear. This is what I see (the description in brackets were added by me).
19:36 (Sunset)
08:25 (Sunrise)
They're not numerical time values at all.
I don't know what everyone else has found, but the "sunrise" and "sunset" values in the Zipato weather station seem, in fact, to be strings. If I copy those values to a virtual meter and try to compare them to other date values, they always behave as 0. If I send them to an email, the reason becomes clear. This is what I see (the description in brackets were added by me).
19:36 (Sunset)
08:25 (Sunrise)
They're not numerical time values at all.
Dave, what does it mean? In common language not programming...
Dave, what does it mean? In common language not programming...
It means that the raw "sunset" and "sunrise" values can't be used in any kind of comparison with times.
However, it turns out that "hour of (sunset)" converts it into a valid time value, and now (as of firmware 1.0.17) the comparison does work properly.
It means that the raw "sunset" and "sunrise" values can't be used in any kind of comparison with times.
However, it turns out that "hour of (sunset)" converts it into a valid time value, and now (as of firmware 1.0.17) the comparison does work properly.
Actually I've just discovered a way to exploit this. You can make comparisons with fixed times using the "time" piece, but it only allows 15-minute intervals. What if you wanted to ask something more precise like
time > 19:01
?
Well you can exploit the fact that time of () casts a string into a time value, and just write the time in yourself. I didn't know that. (Perhaps you did!)
Actually I've just discovered a way to exploit this. You can make comparisons with fixed times using the "time" piece, but it only allows 15-minute intervals. What if you wanted to ask something more precise like
time > 19:01
?
Well you can exploit the fact that time of () casts a string into a time value, and just write the time in yourself. I didn't know that. (Perhaps you did!)
I guess Arild should have solved his problem by now by using the scheduler or weather "device".
I had a problem with a rule to check if sunset is over by "NOW". After many trials I found out that the TIME() function creates the number which counts the seconds from midnight times 1000 (or 36000000 per hour). However your time is converted into UTC. Example for times(15:00) - CET:
15h CET is 14h UTC . 14 * 36 000 000 = 50 400 000
That is for (CET): times(14:00)=50400000
Now I can use comparison in rules and I can use also weather input to use in calculations.
I guess Arild should have solved his problem by now by using the scheduler or weather "device".
I had a problem with a rule to check if sunset is over by "NOW". After many trials I found out that the TIME() function creates the number which counts the seconds from midnight times 1000 (or 36000000 per hour). However your time is converted into UTC. Example for times(15:00) - CET:
15h CET is 14h UTC . 14 * 36 000 000 = 50 400 000
That is for (CET): times(14:00)=50400000
Now I can use comparison in rules and I can use also weather input to use in calculations.
Arild,
Take a look at this file, you can create a daylight sensor and use it across many rules.
Arild,
Take a look at this file, you can create a daylight sensor and use it across many rules.
Just to share my setup for our garden lights based on the build-in weather station sunrise/sunset capabilities. Based on the scheduler I set a variable and a virtual switch. I have also included a manual override switch for the occasional glitch in case the Zipabox was unable to determine the sunset/sunrise times.
I created the rule around the following requirement: 'turn on garden lights when it gets dark in the evening and turn them off when it is 00:30. In the morning, turn on garden lights when still dark at 07:00 (first one leaves the house around 07:15) and turn them off at sunrise.'
To clarify some of the Dutch words used in my rules:
PS I use a 'proxy' switch for the garden lights because I experienced some connectivity issue with my z-wave wall plug and by using a proxy I did not have to fix all my rules that include the garden lights when I had to remove and pair the wall plug.
Just to share my setup for our garden lights based on the build-in weather station sunrise/sunset capabilities. Based on the scheduler I set a variable and a virtual switch. I have also included a manual override switch for the occasional glitch in case the Zipabox was unable to determine the sunset/sunrise times.
I created the rule around the following requirement: 'turn on garden lights when it gets dark in the evening and turn them off when it is 00:30. In the morning, turn on garden lights when still dark at 07:00 (first one leaves the house around 07:15) and turn them off at sunrise.'
To clarify some of the Dutch words used in my rules:
PS I use a 'proxy' switch for the garden lights because I experienced some connectivity issue with my z-wave wall plug and by using a proxy I did not have to fix all my rules that include the garden lights when I had to remove and pair the wall plug.
Replies have been locked on this page!