This object is in archive! 

Problem with rule using sunset and sunrise

Jean-Louis PERSAT shared this idea 8 years ago
Under Consideration

Could someone tell me what's wrong with this ?

When I take a look at the API, the weather sunrise valie is like 11:00 so something is wrong in my rule


a0520788e1c48262d4bc940a52e88833

Replies (34)

photo
1

I'm a bit new to Zipato and rules creator so maybe I'm wrong but isn't better to use the scheduler for sunrise and sunset? Where is your "when" block?

photo
1

I also had some problems and I was told by the helpdesk not to use sunrise or sunset in metering funktions. Better use a scheduler with a decicated variable as Thomas suggested. There are some other advantages of the scheduler with a variable. You can use it for all rules and e.g. you can set the scheduler to sunrise +30 min and one to sunset -30 because in a house it can be quite dark at sunset.

photo
1

This is not a rule triggered by sunset or sunrise, so no way to do it like you do. It is triggered by a motion detector and I have to check if we are during day or night.

photo
1

And using sunset or sunrise as trigger is a bad point as box can reboot so it wont work as expected

photo
1

Well you need to post the full rule as this is only part of the rule. It would be best for you to describe what you want to achieve. Then we can help.

photo
1

I don't think that will help a lot, my main problem is that there is no documentation about the format returned by the Weather sunrise/sunset sensor

photo
1

What I get requesting the API is :

"astronomy": {

"response": {

"version": "0.1",

"features": {

"astronomy": 1

},

"error": null

},

"moonPercent": 83,

"moonAge": 19,

"sunset": "21:34",

"sunrise": "05:51",

"moonPhaseName": "Waning Gibbous",

"moon_phase": {

"percentIlluminated": 83,

"ageOfMoon": 19,

"current_time": {

"hour": 14,

"minute": 31

},

"phaseofMoon": "Waning Gibbous"

},...

photo
1

According the above the sunrise and sunset is accurate. Not sure what you need help with. Pls describe again.

photo
1

the <hour NOW between hour WEATHER SUNSET and hour WEATHER SUNRISE> doesn't work

I think there is a problem with hour WEATHER SUNSET/SUNRISE sending a format that differ from the hour NOW

like <hour [12:16:35] between hour [5h45] and hour [21h32]>

photo
1

Hi Jean. So far I had no detailed information what you are trying to achieve. The printscreen is not a valid rule. Not sure if you getting this if I get no usable responce on your request.


Lets start again from the beginning.


Surely rule with sunrise and sunset is working, so please firstly describe what you want the rule to do. This will heps us the others to give you rules that can be used.

photo
1

My goal is to open blinds when somebody get back home. I have a motion detector for this. If motion is detected, alarm is disarmed and current time is between sunrise and sunset then it will open the blinds

photo
1

Hi Attila,


are you sure, sunrise and sunset are working properly as metering functions by now? I´ve been told by the support three days ago that I better should use the scheduler to set a variable (I call it daylight). I had awful problems with the same rule (ok, I used Sunset to Sunrise instead of Sunrise to Sunset for my needs) and now everything is fine (and I use the variable, which can be defined with an astro offset, in quite some rules). The only problem is a reboot.


By the way: Wouldn´t it be good to have a tile which starts after a reboot to have a chance to set variables accordingly? So in my example it meight take half a day after a reboot until the daylight variable is set correctly.

photo
1

Hi, I also use variables to set the night/day accordingly. So have a main rule that runs based on astro offset and sets a variable "Sunset"to 100 when it is night and to 50 when it is day. from there any rules that require sunset or sunrise condition, the variable is used. If you are refferring to this approach that u use, than it is fine. Other approach is to use virtual switches instead of variables. Their state should nowadays be preserved regardless of the box reboot. perhaps try that and give me your thoughts.


As to the motion activated disarm and opening blinds in daytime. here is a sample rule. The bigger rule is the one that does the actions. In there the variable is set to ensure rule only runs in the night. You can reverse this in the small rule. The small rule runs every day and depending on the added virtual location it is set at sunset (or for your case sunrise) to 100.


Hope this makes sense.

photo
1

This is what I've done so far, and sad to say but it has never worked after a reboot. I'm using variables and many virtual switches in my rules and reboot is always a problem, persitence is not 100% working. Switch remains in good position but it's value not. That's why I've done a rule to be notified after a reboot, so activate virtual switches to set them correctly. Today I can say that my box is more stable than it was in the past years (since 2012) but it remains few problems like this one.

photo
1

I* guess you have but anyway I ask. Have you tried it this way? If yes, raise a ticket with support.5a26bda113e3cbd1fc93aabd3ec932da

photo
1

It says "date expected"

photo
1

Try like this. I used the time now as I whowed above and also had the same "Date expected". So i switched the puzzle to "between, and" in the operator section and inserted a time of now from the variable. Now without error message.e77e224dceffd07311ed643c0a5dae72

photo
1

but does the rule work. It can be valid but that's not make it working

photo
1

Ok tested and not working even if rule is valid

photo
1

did you tested yours or just said it's ok because it's valid ?

photo
1

Hi, I have not tested the rule as Im not home at the moment. I guess the best is to get in touch with Zipato via support.zipato.com and ask them for a resolution.

photo
1

Try this.

The scheduler runs every minute or every 5 minutes.07af60c5bc1207709e63804407bd5344


regards Maik

photo
1

Ok, I've found a solution using comparators instead of between

photo
1

Can you post your rule that works?

photo
1

dbb7f11041a41b202287e89c23620c05

I'll confirm you tonight if that works

photo
1

Damn, it doesn't work

photo
1

In my particular case, the Sunset and Sunrise values are always zero! Have you tried inspecting the values? Even if you get valid values in sunrise/sunset, it appears to be impossible to work with them in the Zipabox. For example, if I store time of (now) in a variable, and then compare it later to the current time, it will always behave as if it's 0, even though, when you send the value to yourself in an email, it's not 0. Very strange. I reported this bug in a ticket and it's been acknowledged, so I hope it'll be fixed sometime soon.


On this post I detail a way to import sunrise/sunset times from OpenWeatherMap (there are other sources too) and use them to calculate whatever I need. Relevant in this case would be the daytime variable, which is refreshed to a 0 or 1 state each time the sunrise/sunset info is received by the Zipabox (every 10 mins or so). Note that I import the hour and minute values separately, because of the date/time bug explained above.


It's a way to keep key variables always refreshed so that disconnections or reboots don't throw your whole system into chaos by resetting all the values :-)


https://community.zipato.com/topic/need-a-way-to-store-and-compare-datestimes

photo
2

I have the same thing for my blinds. What I do is using a virtual sensor which is turned ON and OFF with two rules using schedulers with Sunrise / Sunset option.


Then I use this sensor in any other rules, this works pretty good. I know this is an issue (not able to use metering function for Virtual Weather Station) but at least there is a way around. If you are interested in this approach let me know and I will post my rules.


Regards.

photo
1

After investigating further I think the "sunrise" and "sunset" values in the Zipato weather station are, in fact, strings. If I copy those values to a virtual meter and try to compare them to other date values, they always behave as 0 (just as happened with your original rule). 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.


In contrast, time and date values are large numerical values. So the two can never be compared.

photo
1

Makes sense David, thanks for sharing.

photo
1

Apologies, I have been misinforming you. When you use the sunset/sunrise values (which are strings) with the "hour of" piece, it appears to cast them to a valid time value - and it does seem to work. I had tried them without "hour of".


However, it seems that something regarding sunset and sunrise in rules was fixed in firmware 1.0.17, so maybe that's the problem you were all encountering. I just tried:


time(now) between time of (sunrise) and time of (sunset)


and it's working.

photo
1

David,


Indeed the log shows fixes on 1.0.17... no problem, I use a virtual sensor for sunset/sunrise so it wasn't really bothering me, thanks for the update.

photo
2

Ok that works now

photo
1

Bonjour Jean-Louis,

Votre règle m'intéresse, pourriez-vous m'envoyer une copie d'écran ?

y-a-t-il une ou plusieurs règles?

le QUAND (WHEN) est-il basé sur un schedule de 1-5 minutes? ou bien sur autre chose?

est-ce que la règle est : SI l'heure de maintenant EST supérieure (ou égale) à l'heure du sunrise ET inférieure à l'heure du sunset ALORS j'ouvre les volet, SINON je les ferme?


merci.

William


ma règle ne fonctionne pas.

j'ai deux autres règles qui changent la valeur de la variable SUNSETRISE + un switch virtuel (Volet Roulant Auto) pour désactiver ou non la règle.

/0yeBsVz+YMPAAAAAElFTkSuQmCC

Leave a Comment
 
Attach a file