Reliable LUX for Piston Execution


Thought this was quite simple but wanted to share. I have been looking for a way to get a reliable LUX reading. I utilize LUX throughout all of my motion based lighting pistons. I have tried Weather Station and even have created my own ST_Anywhere LUX sensor. Ultimately though this seems to be the most stable and reliable. I use the solar radiation as another WebCoRE user has done as my findings were similar that the solar radiation was more reliable for accurate and up-to-date readings than the standard illumenation api. Updates occur from Weather Underground every 5 minutes which updates accordingly (all of my motion sensor wait times are 5 minutes or higher). I use (2) global variables for my pistons. @weatherlux which is derived from this piston. And LUXsetting which is my global “if less than this then turn on lights xyz.”

**Edit: Added the check for occurrences, created a Fuel Stream for tracking and also enabled quick Piston State glances.


I would recommend adding the accuweather “device”. That exposes UV Index. Much easier and won’t tie up bandwidth setting a variable every 5 minutes.


Interesting. Does the accuweather refresh itself? I tried Smart Weather previously and it did not update automatically.

Also… how does UV Index translate to real world scenarios. Looks like it’s on a scale of 1-9 or so? Just curious what values would indicate night, dusk/dawn, partly cloudy, fully overcast, full sun, etc.


Yup, the accuweather “device” updates itself automatically.

No, it’s actually on an unending scale. It’s not uncommon to get UV indexes in the teens in tropics at mid-day in the summer on a clear day. I have seen uv indexes of about 4 in the past few days here in western New York State, USA. An index of 0 is night. More info here:


Which device might that be? In ST?



Yes I did use that as well. There is a limitation on the amount of connections ST can provide. Many instances of incorrect data being provided through ST. Using UG directly and calling the API every 5 minutes for the UV number seems to be the most stable. Just my experience. As I said before I even created my own lux device but found that to be limiting too.


Gotcha. Thanks!


Do you need to install or connect Weather Underground to SmartThings for this to work? Or is it built into webCoRE? Glad to know it’s reliable, I have been having issues with Smart Weather. Seems like either yours or Ryan780’s UV Index approach will work better than what I’ve been doing.


Built into WebCoRE. If you create a piston with the backup code above you should be good. Just need to create your global variables accordingly. Also I don’t do all of the morning, afternoon, dusk, evening for lights. I just use the UV to either turn lights on/off based on motion. Looks like 68 is the number I like at my home. :slight_smile:


I thought I would copy your code above.
I then did a fuel Stream to monitor it to see how it performs.
Today it has dropped to zero a few times during normal daylight hours.
Do you get the same thing?


Yes I have seen this today as well. Very odd. Past month I have had no issues.


I went ahead and created an exception for this weird occurance.


Are you in the UK? I am and was wondering if it’s all the snow we are having and somehow covering the weather station sensor. Don’t know but just a thought.
I like your work round though. :slight_smile:


Nope I am here in the states. I just noticed that my lights were coming on today. So WU could be having a hiccup but now with the work around I won’t have issues with the “0” occurrence that can happen every so often. :slight_smile:


Just thought I’d put a note on here about using this method.
I’ve been using this for 5 days and it’s working brilliantly.
This allows me to do away with using a lux sensor in my home for triggering lights etc.
I now have a Fibaro motion sensor that I can use for motion and also not worry about it ‘freezing’ and locking up my pistons.

Great job. Thanks again for this.


Ok, I’ve tried adding this to a piston I use to set all my global variables, and I am continually getting “error with wu - keeping LUX at 0”

Is there something I am missing the only thing I changed was adding a fuelstream write after the initial setting of ‘weathertemp’ and moved the timeframe from 45min to 60min +/- sunset/rise


I get the same issue. Looking into it now but it seems that WU just doesn’t support that query for my location. Other queries work but not this. Maybe the WU station I have been mapped to just doesn’t report this.


John are you using a global variable for your other pistons?

What I use is a global variable called LUXSetting (@LUXSetting) that is my static for all pistons to reference. That way I was able to hone in on the correct LUX setting for my home and also regional LUX lighting. So mine currently is set to 71.

The global variable weatherlux (@weatherlux) is what my piston sets every 5 minutes or so. You need to ensure you convert over to an integer or you can’t read the returned results or compare correctly. Finally it should work anywhere as WU is a global weather station.

Also can you share you FULL logs?


So … I think I see the issue

I run my own PWS that doesnt have SolarRad sensors, and I have mapped my weather to my PWS… In the eval console I ran $weather.conditions for giggles and here is what returns:

[response:[features:[conditions:1], termsofService:, version:0.1], current_observation:[wind_gust_mph:6.0, precip_1hr_metric: 0, precip_today_metric:0, pressure_trend:-, forecast_url:, history_url:, estimated:[:], weather:Partly Cloudy, windchill_string:29 F (-2 C), station_id:KPAALBRI11, UV:0, observation_epoch:1520289668, wind_gust_kph:9.7, precip_1hr_in:0.00, observation_time:Last Updated on March 5, 5:41 PM EST, feelslike_string:29 F (-2 C), temp_f:28.6, local_tz_long:America/New_York, relative_humidity:81%, temp_c:-1.9, image:[title:Weather Underground, link:, url:], solarradiation:--, visibility_mi:0.8, observation_location:[full:Indian Mountain Lakes - Carbon County, Albrightsville, Pennsylvania, elevation:1808 ft, state:Pennsylvania, longitude:-75.536423, latitude:41.008137, country_iso3166:US, country:US, city:Indian Mountain Lakes - Carbon County, Albrightsville], wind_mph:2.0, heat_index_c:NA, precip_today_string:0.00 in (0 mm), observation_time_rfc822:Mon, 05 Mar 2018 17:41:08 -0500, feelslike_f:29, heat_index_f:NA, feelslike_c:-2, heat_index_string:NA, ob_url:,-75.536423, dewpoint_string:24 F (-5 C), local_tz_offset:-0500, wind_kph:3.2, windchill_f:29, windchill_c:-2, wind_degrees:355, pressure_in:29.79, dewpoint_c:-5, pressure_mb:1009, icon:partlycloudy, local_time_rfc822:Mon, 05 Mar 2018 17:41:10 -0500, precip_1hr_string:0.00 in ( 0 mm), icon_url:, wind_dir:North, dewpoint_f:24, nowcast:, display_location:[zip:18210, magic:1, full:Albrightsville, PA, elevation:516.3, state:PA, wmo:99999, longitude:-75.52999878, latitude:41.00000000, state_name:Pennsylvania, country_iso3166:US, country:US, city:Albrightsville], visibility_km:1.2, temperature_string:28.6 F (-1.9 C), local_tz_short:EST, local_epoch:1520289670, wind_string:From the North at 2.0 MPH Gusting to 6.0 MPH, precip_today_in:0.00]]

solarradiation is returning “–” as the value for the PWS - I’m going to play around to see if there is a way to pull from something else close by but I’m in the sticks and its unlikely … may have to just install the solarrad sensor and be done with it :slight_smile:

Here are the logs …

3/5/2018, 6:12:15 PM +543ms
+1ms ╔Received event [Home].time = 1520291535851 with a delay of -308ms
+201ms ║RunTime Analysis CS > 19ms > PS > 66ms > PE > 116ms > CE
+205ms ║Runtime (49584 bytes) successfully initialized in 66ms (v0.3.000.20180224) (203ms)
+207ms ║╔Execution stage started
+249ms ║║Cancelling statement #20’s schedules…
+421ms ║║Executed virtual command setVariable (3ms)
+435ms ║║Executed virtual command writeToFuelStream (6ms)
+444ms ║║Comparison (integer) 0 is_greater_than (integer) 0 = false (3ms)
+446ms ║║Condition #26 evaluated false (7ms)
+448ms ║║Condition group #22 evaluated false (state did not change) (9ms)
+451ms ║║Cancelling statement #23’s schedules…
+461ms ║║Calculating (string) Error with WU - keeping LUX at + (string) 0 >> (string) Error with WU - keeping LUX at 0
+465ms ║║Error with WU - keeping LUX at 0
+466ms ║║Executed virtual command log (1ms)
+474ms ║╚Execution stage complete. (267ms)
+477ms ║Setting up scheduled job for Mon, Mar 5 2018 @ 6:17:15 PM EST (in 299.832s), with 4 more jobs pending
+485ms ╚Event processed successfully (485ms)