Used johnwill1's example to turn on/off a light using LUX. Like the idea of limiting trigger action. The LUX sensor is set for 1 second reading intervals and successfully writes data to a log file in the hub.
Made up a rule on a C7 hub based on johnwill1's example with FW version 2.3.5.152. It appears in rule one that the variable is set and its value (true/false) changes when the rule is run dependent on LUX levels. However, in rule two, the variable will not change.
Maybe missed something on my end or did not make the correct selection on the rules machine.
Suggestions or code modifications would be most appreciated.
The rule you've posted ensures that the value of the variable rearLuxLow will never be set by the rule because the required expression and trigger conflict with each other.
What, specifically, isn't working? Both rules look fine to me. I see you said "the variable will not change" in the second rule, but I'm not sure what the basis is for that statement. If you are just looking at the rule interface, note that the display of current values does not update in real time, only on page load. Reloading the page should help (though it does look correct if both rules executed around the same time, given the last reading I see from your lux sensor in the first screenshot). But that is just a display issue and would not affect functionality.
If you are trying to troubleshoot an app, including a rule, enabling all logging is normally a good starting point. I see that (mostly) in your second rule, but I'm not sure about the first. The next step would be to check out "Logs" for what they actually say. For more ideas on troubleshooting apps, including rules, read the first half of this document (which covers some of this information and more): How to Troubleshoot Apps or Devices | Hubitat Documentation
rearLuxLow are local variables to both rule 1 and 2. If you're expecting a change in rule 1 rearLuxLow to change value in rule 2, it won't happen. You need to make it a hub variable so it can be shared between the two rules. Local variables are only available for use inside the specific rule where they were created.
Made the change and it is now operational. New at using RM and was not aware of the two different types of variables. Removed all of the local variables and created a hub variable using a different name to avoid confusion.
Is it possible, with this app, to use one LUX level to turn on the light with a different level to turn it off? As an example 100 LUX on with 50 LUX off or the other way around?
IF (Time between Sunrise and Sunset AND lux < 100) THEN
On: Test Switch
ELSE-IF (Time between Sunset and Sunrise AND lux < 80) THEN
On: Test Switch
END-IF
This can also be written as
IF ((Time between Sunrise and Sunset AND lux < 100) OR (Time between Sunset and Sunrise AND lux < 80)) THEN
On: Test Switch
END-IF
Just for reference, I use HUE sensors for my Illuminance based automations, and due to the minimum illuminance change value between reported events and reporting cycle of the sensors, as well as an averaging app, I find that a deadband is unneccessary.
Essentially the delta in Luminance over the time between any two reports, coupled with the averaging of the value (3 sensors averaged) of luminance, ensures that I get no "cycling" and I need not add the additional deadbanding code.
Unfortunately, I'm at work, or I'd post my rule. Suffice it to say it's similar to @pseudonym's example, but I use the activation restrictions for managing the time of day, and a global/hub variable to set my illuminance level threshold value across a number of rules.
Yes, will add it to the test code and go from there. Like the time addition to make sure that there is no conflict in LUX readings.
Here is what is being used at this time. The action is to SET two different modes. One for night (3) and one for day (0). There will be twenty actions for day (sunrise) and twenty for night (sunset).
The goal, as indicated in your code, is to use two different LUX values as sunrise and sunset LUX varies dependent on sensor placement. Also, for additional flexibility a delay can be added, as needed, to individual actions if more control is required.
Using a Zoo ZSE-11 sensor for the LUX data. It can be set to report 1 LUX to 30K LUX increments. This will also assist with deadband issues. It is rated for indoor, but will add silicon caulk to make it more water resistant.
If the two modes, one for sunrise and one for sunset are not adequate then a third mode could be added for dusk. Perhaps >150 for sunrise, <75 for dusk and <40 for sunset. Will have to test under actual LUX conditions and see what is needed.
Have been using rise and set times with an offset for sunrise/set. That generally works but needs tuning for cloudy vs sunny sunrise and sunset conditions.
Would like to look at your code, if you get a chance to post.
Thank you for posting your code. It is most appreciated. Will try some of your ideas and see if they can be combined with johnwill1's example.
The overall goal is to trigger the HTTP GET statement once for sunup and once for sundown each using a different LUX value. i.e. sunup LUX > 100. sundown LUX < 80.
Took your advise and came up with the following to send a GET statement based on LUX within a sunrise window. Also, made up another app for sunset.
Have not yet tested as will have to move the LUX sensor inside to test the various conditions but it looks like it will function.
When logging events, triggers and actions, for this app, noticed that LUX is updated 4 times per second. Is this normal or is there a way to not have any LUX triggers unless those LUX events occur in the greater than 50 and less than 70 LUX range?
Seems like it should work (although perhaps not as you hope!).
That update rate seems crazy though. Let me look at my sensors and see if there are any settings that govern that.
The Hue devices have a setting "Lux Reporting" that defaults to 10 Lux, but can be adjusted upward or downward. At 1 lux, i could imagine several times per second, but you'd have to fiddle with it to see how it would behave.
The Zooz appears to have a the same setting. You may want to change the Lux Sensitivity (minimum change) to a bit larger range. Having said that, your guard band >60 <70 is a pretty tight, so raising the Lux sensitivity might break your rule ( this is why I caveated the first part of my reply).
I dont know what the reporting range of the Zooz is, but the average of 3 Hues outdoors presently, 4:30p Eastern is 12513.
I use 500 Lux for Dusk, and 200 for "night", so I'd guess the difference between 60 and 70 is effectively indistinguishable. Both are "dark".
Bottom line: I think your guard band is likely too narrow.
Yes, the Zooz LUX sensor can be set as quick as 1 LUX updates. May move that up to 5 pr 10 to limit the number of updates. And increasing the guard band will then also be necessary.
The Zooz maxes out in the 65K range. For sunrise and set it would appear that numbers under 200 LUX are the numbers of interest.
Checked the LUX log and at sunrise (4:41 AM) the LUX is 34. A quarter hour later at 4:56 AM LUX is 74. May try 100 LUX for that action and adjust from there or if more light is needed then higher.
One negative is that the GET statement fires multiple times during the guard band window. Will add a boolean T/F to the action to eliminate that aspect of the app.
Will move the sensor inside today and work with it using the desk lamp. Thus a good way to test the app, etc.
Perhaps a boolean T/F based on a time window could be used to turn the LUX sensor on/off to reduce the amount of LUX updates from thousands per day to just a few hundred. Not sure if suspending the rule
One could turn the action rule on/off but that would seemingly not effect the continuous LUX reporting aspect of the app.
The LUX log is setup to report LUX < 250 as higher values are of no interest.
