Cloudiness as condition

Hey there,

I'm trying to use cloudiness as a trigger for a rule. The basic rule, is that several lights in my living room turn off 30 minutes after sunrise, which works like a charm. The problem I have is when there is bad weather. In that case the outside is to dark I'm left sitting in a dim room. I tried to use my weather-tile (openweathermap-api) for the additional condition. What I tried, was that the lights only turn off, when a cloudiness of under 45% is reported. Right now I can only choose an exact value. Is there any other possibility, except of a luminescence-sensor?

1 Like

Yeah, I used to do something similar using the Openweather device. There is a lux option I used rather than cloudcover. But it didn't always really reflect the actual light condition where I am. For example there could be bad weather during the day and I wanted my lights to come on with motion but the lux setting in Openweather hadn't fallen enough.

Now I just use a couple of the Xiaomi luminance sensors, one at each end of my house, and average the reading. They are cheap as chips and work brilliantly. No disconnections thus far in my set up (Ikea repeaters), after a year or so of use.

1 Like

Personally, I use two multi-sensors with lux reporting capability. I have them placed in the window on the front and back of my home. I have them mounted in a small jewelry/craft box that doesn't draw much attention but prevents them from catching too much interior light.

I use the average lux level of both sensors to control my mode changes. Unless you have some sort of external lux sensor I don't see how any weather source is going to give you accurate enough information to use as a value for lux level.

Pro-Tip: When choosing a "lux" sensing device make sure it has the ability to report on an interval instead of a change in level. I've found that change in level generates way too many events which I always try to avoid to keep the rest of the hub's mesh snappy.

Edit: Also, make sure that the sensor of choice doesn't limit it's lux reports to when it's detecting a secondary trigger (motion, temperature, etc) as this might make the lux reports lag behind the actual level depending on mounting location.

Bummer, but I somehow expected that... :frowning:

Ok, that's cool. How can you generate the average reading as value for HE?

Thank you, for the tip. :slight_smile:

I have a little rule that triggers on either of them changing. Just adds their values together and divides by two. Simples!

Very cool, thank you. :smiley:

1 Like

There is also a user app called "Averaging Plus" written by BPTWORLD which I use. It creates a Virtual device and you can add as many devices into this to get an average. I then use the virtual devices reading. It is in the package manager just search "Averaging"

1 Like

Yeah, but I always like to build my own (where feasible and it's not something that needs to be optimised for speed) so that I know exactly what's going on and have full control. Plus I love the challenge :smiley:

These? Is there a Hubitat driver to use without a Mi gateway? The price looks good!

Yes, they work nicely direct to the HE using Markus' driver "Zigbee - Xiaomi Mijia Smart Light Sensor (Zigbee 3.0)". It's perfect.

By the way, I actually use them outdoors on protected ledges to two windows, but it's Thaiand so they may get hot/humid, but don't get wet (because they are under wide ledges), and never get cold :slight_smile:

1 Like

Have you investigated how often your rule triggers during the day? I also use those sensors for the same purpose and found them triggering alot, sometimes more than once a second.

To lighten the load on the hub I use a repeat every 5 minutes to sample the lux and then average. Orders of magnitude less processor load. Also this loop only runs during the day.

I find this works magnificently.

Hasn't been an issue this far. They trigger on change so at night no signals (apart from the hourly battery ping) and during the day, yeah regular updates if the lux changes but havn't caused any noticeably extreme load issues so far and I've been running them like this for a year or so now.

That's because there's a bug in the way the driver takes the current weather conditions into account when estimating lux. I'm running my own fork of openweather with this bug fixed for this exact use case, and it works great.

Would you be so kind and share your driver? :grin:

No, it's because no weather forecasting system can get to the level of granularity required to see if a cloud is actually over my house (especially given that house is in Thailand) :joy:

This is also true. But I've found that it's good enough once the bug is fixed.

OK, then.

Who's going to point a camera at the sky and write some cloud recognition AI?

Go!

Wait, I think there is actually a driver for this! It should be right here :smiley:

1 Like

I'm infrequently able to determine behavior like this BEFORE a purchase. These vendors can have a whole paragraph on how great their device is, but one line or two lines in the specs about reporting frequency is hard to find. Relying on what others have discovered seems the best way.