Virtual Weather Station - Cloudiness

1

Christoph Krieger ●

Found here:

http://www.wunderground.com/weather/api/d/docs?d=resources/phrase-glossary#current_condition_phrases

I hope thats right.

2f2cc600e8ba247b3fb11df8aa809c4f

Reply URL

1

David Pritchard ●

Has anybody figured out a solution to this?

The "cloudcover" value appears to be useless, because weather stations don't fill it in. I can't see anything matching these numbers here. "weatherDesc" can't be used because Zipabox can't handle strings (and they've removed it from the UI).

All I have been able to come up with is having IFTTT send a notification when the weather turns cloudy, but that's a pretty poor substitute, since it doesn't have any gradations of cloudiness. For my purposes, almost any amount of sun is worthwhile in winter for solar gain, so I only want to close the blinds when it's completely overcast.

Reply URL

2

David Pritchard ●

I'm actually not sure it's the weather stations that don't fill in "cloudcover". I think it might be the Zipabox that doesn't read it properly. My local weather station definitely records cloud cover percentages.

I have a sort-of solution for this. I've installed Llamalabs' Automate on my mobile phone (an Android app) and created a flow which reads the cloudiness into a variable, and then POSTs it to the Zipabox with a HTTP request.

First, add a weather block to the Automate flow. Cloud cover is the 4th parameter in the weather block. You need to write "cloudiness" or some other variable name directly into the field so that the number is stored in that variable.

Second, you create a virtual meter in the Zipabox and grab the URL needed to send a value to it.

Third, you add a HTTP Request block and paste the URL into the URL box. Add {cloudiness} (or whatever your variable name is in curly braces) to the end. Choose POST as the Request Method and JSON as the Request Content Type.

Fourth, use a Delay block to wait a certain time after each update (say, 30 minutes, 1 hour...).

Set the flow running and you should get the cloud cover in your Zipabox virtual meter.

Reply URL

1

David Pritchard ●

Automate is one of the few apps out there that gives access to this fine-grained cloud information. I haven't had time yet to check whether it's accurate.

Reply URL

1

Michel CHEMLA ●

Hi,

I am sorry but I have not understand your explanations.

So, since you wrote this post, did you find a easier way to give the cloudcover?

I would like to open the shutters according to the cloud cover.

Thanks for yor answer.

Kind regards

Michel

Reply URL

1

David Pritchard ●

I have now several sources for cloud cover information, although I'm planning to install an Enocean light sensor which should be more reliable.

All the external cloud cover information is sent from external sources to virtual meters. The URLs of the virtual meter attributes allow you to update them from mobile phone apps, Google App Scripts, scripts running on your own web server, or whatever. If you look for Google App Scripts, weather or other keywords, you should find example code for Google App Scripts in some of my other posts. I currently send cloud cover information from DarkSky, Aeris and OpenWeatherMap to virtual meters via a Google App Script that runs every 10 minutes or so. You sign up for each API and then call it from your script, extract the information you want and send it to your virtual meters. Automate is a mobile phone app that allows you to create "flows", basically little programs, rather like Tasker. The flow that gets weather information runs in the background on my phone and sends updated info to a virtual meter every few minutes. I take an average of the cloud cover readings weighted by each sources reliability, calculated in a rule that also runs every 10 minutes. This is what I use to control my blinds. Complicated, yes, but it works. :-)

I can post a shot of the Automate flow if you like, and later if I have time maybe an updated Google App Script.

Reply URL

1

Michel CHEMLA ●

Hi,

Thanks for journée quick answer.

I understand yours words but not your sentences.

A long time ago, I wrote requests IFFT, but, right now, I have forgotten how to do it.

So, I'll do appreciate if you send me an example of a such script.

Kind regards

Michel

Reply URL

1

Jan ●

The icon of the Virtual Weather Station changes, depending on cloudiness. Is there no possibility to access that information via a rule? It would be so convenient...

Reply URL

2

Michel CHEMLA ●

Hi,

I use this capabilitie to manage my roller-shutter.

Here is an extract of this rule.

You will find the entire list of icons on the Weather Underground site

BR

Michel

Files:

Reply URL

1

Jan ●

Excellent! Thank you.

BTW: Link to Underground site: https://www.wunderground.com/weather/api/d/docs?d=resources/phrase-glossary

URL

1

David Pritchard ●

You can do string comparisons now??! Since when?!

I swear that didn't used to work!

URL

2

Michel CHEMLA ●

I can just tell you that I use this rule since 2 months and it works fine. So, I swear that do work now.

My roller-shutter open and close depending the sunrise and sunset and cloudiness.

I'll probably add this summer a condition linked to the temperature.

BR

URL

1

Michel CHEMLA ●

BTW, here is my rule as a whole including the temperature parameter.

Files:

URL

1

Michel CHEMLA ●

For details, here are the explanations:

If I am between sunrise et sunset and the temperature lower than 28°C

If the cloudiness is sunny, clear, partlycloudy, mostlycloudy, partlysunny or mostlysunny I open the roller. Else, I close it.

The only thing I can't do is to differate the operations 2 hours after the sunrise et before the sunset.

If you have any idea, I'll appreciate your help.

BR

Reply URL

1

Michel CHEMLA ●

Last point, it will be more simple to have the "select case" instruction.

Reply URL

1

Attila Hajdu ●

Michel, Can you re-phrase what you cannot do? There is (nearly) always a way.

Reply URL

1

Michel CHEMLA ●

The only thing I can't do is to schedule the automation of the roller-shutter at a time range between 2 hours after sunrise and 2 hours before sunrise.

Is this more understandable?

Reply URL

1

Attila Hajdu ●

yes, it makes sense. the current scheduler is running at a repeat intervals?

Not sure if you are aware, but the scheduler can be set as Astro with offset of 2 hours. i guess your problem is that the above rule runs every let say 5 minutes. and you need another way to definitely trigger the rollers at -2 sunrise and +2 sunset.

the easiest approach is to duplicate the rule and use an astro triggered scheduler.

I also have seen another post where now the guys were using 2-3 schedulers in the when block combined with "Or" puzzle. you can try that as well.

Reply URL

1

Michel CHEMLA ●

I modified the rule using 2 schedulers in the when block combined with an AND.

For each scheduler, the trigger is 1/2h with an Astro offset. The first one 2h after sunrise, the second one 1h30 before sunset.

It doesn't work.

It's not logical to use an OR because the condition will be always TRUE. Each 1/2h, it will be always between sunrise or sunset.

The other way, duplicate the rule whith 2 different triggers, is no so smart. I'd prefer to have just one rule.

If you have an idea to help me, thank you.

Reply URL

1

David Pritchard ●

Here are two rule snippets. Sunset.jpg runs every 10 minutes. Sunset2.jpg runs every minute.

This gives me fine control over any actions that need to be performed around sunrise/sunset.

Files:

URL

1

Attila Hajdu ●

Hi Michel, just thinking about it it is wrong to assume that OR will not be good and it makes sense that with AND it will not work. With AND the rule will only trigger if both schedulers condition is met which will not happen. With OR the condition should trigger with either one OR the other scheduler.

Can you retest using OR

URL

1

Michel CHEMLA ●

In fact, I think it is not possible to use the Astro parameter with an 1/2 hour trigger.

The Astro parameter is itself a daily parameter, it can only be used with daily trigger.

By the way, as soon as Astro is used, the time and minute triggers disappear from the possible choices.

URL

1

Michel CHEMLA ●

@Dave

Thanks for your examples.

I follow it to write a test you will find hereafter and it does'nt work.

My goal was to have a time range between 2 hours after sunrise and 2 hours before sunrise.

Do you know why?

Files:

URL

1

David Pritchard ●

@Michel

Because you can't do that :-)

The time value of sunset/sunrise (like any "time of" value) is basically a number representing the number of milliseconds since midnight according to GMT.

I stored the following times in variables and sent them to myself in an email:

13:00: 43200000

15:00: 50400000

If you work it out, they correspond to 12:00 and 14:00 (i.e. GMT), expressed as milliseconds since midnight.

Now, I don't know whether you could add 3600000 (2 hours in ms) to sunrise/sunset and compare that to a given time. MAYBE. I would try time of (sunset) + 3600000. That's an interesting experiment. The sunset/sunrise values in the weather station are strings, I think, like 19:30. The time of () value is a number. That's why you can do: time of (14:05) and it will work.

But what my rule does is extract the minutes and do all the calculations with those.

URL

2

David Pritchard ●

I've just tried it out and it doesn't work. The Zipabox doesn't currently support "casting" from a number value to a date/time value. Only from string (19:00) to date/time. So you can extract numbers from date/time values, but that's it, you have to stick to numbers. There's no way to get back to date/time.

Here's a suggestion. Create a date-time meter to store the total number of minutes since midnight. Have a rule run every minute or 10 minutes to calculate the value (by extracting the hours and minutes using "part of"). Also have the rule store the same value for sunset and sunrise in that date-time meter, using the same method. Then you have two values which you can compare.

I like this method so much, I may use it myself!

Files:

URL

1

David Pritchard ●

You can do something similar with the date-time, but it's more complicated. The function to work out the number of seconds since 1/1/1970 would be rather complex. What I do is have a Google App Script take the Unix date value as a number and send it to a virtual meter in the Zipabox. It runs every ten minutes. Another complication is that the meter values don't have the precision to hold such large numbers, so you have to express it in hours.

I have a post on this somewhere!

URL

1

Michel CHEMLA ●

What do you think of a such rule? I don't know if it's work but it's more simple.

As I have not a PRO licence, I can't send me the values through a mail.

Files:

URL

1

Michel CHEMLA ●

Finally, I followed your advice and wrote 2 rules.

First, to initialize the time variables.

The second one, which manages rolling shutters.

Unfortunately, it does'nt work.

Do you have any idea why it does'nt work?

Files:

URL

1

David Pritchard ●

Michel, you need a couple of changes. First, do the same with the sunset/sunrise values as with the time, i.e.

set value1 = part hour of (time of (sunset)) * 60 etc etc

Then what you have are three values which are minutes. So all you need to do to add or subtract, say, 1 hour, is add 60 or subtract 60 (not the larger numbers, which were milliseconds).

URL

1

David Pritchard ●

Also, for tidiness, and to reduce resource use, you could put all the values into one meter, rather than using a separate meter for each one. Just rename the attributes of the meter.

URL

1

Michel CHEMLA ●

Good evening,

I changed my rules according to your recommendations.

It seems that it works at least to close the shutters roller tonight.

I would see how it works tomorrow. If there is a problem, I would like to contact you.

In the meantime, thank you for your help.

I enclose the rewritten rules

BR

Files:

URL

1

David Pritchard ●

Looks good! Excellent.

Sure, no problem.

URL

1

Michel CHEMLA ●

@David

Hi,

This morning, with these new rules, my rolling shutters opened normally.

It seems to me that it works.

I find this source coding very clever and very convenient.

Again, thank you for your help.

BR

URL

1

Michel CHEMLA ●

Hi,

To close this conversation, I have improved the rules because it was ridiculous to modify the variables each 5 mn.

In fact, I initialize the variables sunset et sunrise once a day, and the variable timecounter each time I execute the rule wich verify if I have to open or close the shutter-roller.

I join the rules to this post.

br

Files:

URL

1

David Pritchard ●

@Michel

Excellent.

I'm not sure whether virtual meters now maintain their values when the box disconnects from the internet (I suppose so). There's also the problem of restarts (mine restarts for some reason every day at least once, usually).

URL

1

Michel CHEMLA ●

You're right. I had not thought to the reboot.

Is there a trigger to launch a rule when the box start

URL

1

Michel CHEMLA ●

Sorry

URL

1

Michel CHEMLA ●

Finally, I fix this problem by creating only one rule. It is less clever but more effective.

URL

1

Michel CHEMLA ●

With the rule

Files:

URL

1

David Pritchard ●

That looks like it should work! An auto-correcting rule, as it were.

URL

Virtual Weather Station - Cloudiness

Merged Objects

Values for virtual weather station

Values used for cloud covers ?

Replies (15)