You can achieve all of these using the Rule Machine (RM) which is the software inside the hub that allows you to create your automations.
You can check the lux (from a suitable sensor) and store the value at a certain time into a variable. Variables can be numbers, strings and you can manipulate them and use them in your automation routines.
Counters are also easy using variables because you can do simple math on them.
You can check the status of a smart lamp which has been included to the hub, such as its status (on/off), its brightness, temp/colour etc depending on the lamp type.
You can also display and control lamps (and variables) on dashboards either locally on your LAN but also out on the Cloud too while away from home.
Here’s a screenshot of a rule where I use two variables to trigger other day/night rules.
%varLuxValue% is just a numerical variable I use to tweak the threshold quickly without having to edit multiple conditions each time.
%varOutdoorLux% is just a string variable I use to hold the values “light” or “dark” right now. Other rules monitor when this variable changed and depending on the value will adjust accordingly.
This way my lighting/rules aren’t dependent on some inconsistent +/- sunrise sunset setting and instead trigger anytime it gets below a specific lux threshold outside.
As mentioned previously the answer is yes but just be mindful of the frequency of events like this. I’ve found it’s really easy to set these types of rules up that eat up resources because it’s capturing some value non-stop where I could create or leverage a less frequent trigger that works just as well but only fires off when needed or is written in a way to kill the logic process as fast as possible.
Yeah, I know what you mean .. Ground my hub to a halt once or twice trying to do this kind of stuff. Make sure you take some backups of the hub before you start.
This is cool. Also the "Newbie" may want to consider using Modes for this. My motion lighting rules have a Mode check at the start so that they only come on during evening and night (unless a virtual switch is set for lights to come on during the day). And those modes are set using the average of 2 lux sensors.
Great suggestion. This is how I was running for a while actually!
Only reason I’m doing it the way I am above is because ideally, regardless of time... if it starts to storm outside and the outdoor lux is dark enough then the outdoor lights would ideally be on/off even if it’s not evening time.
Right now I’m just playing around with it to see if I can get it to work without putting tons of unnecessary strain on the hub.
@Angus_M’s suggestion is the better route in general. My way is overkill because I’m a nerd with too much time on his hands. Haha
Absolutely correct. I just let my mode change back to "Evening" whenever it needs to, including sometimes in the morning lol. I should really rename it to "Dusk" ha ha ha. I do "debounce" the change by setting a gap between the lux triggers in each direction which works quite well.
Values from 2 lux sensors are averaged together and then depending on the average value this could act as a trigger for either a “Night or Evening” mode.
a few of motion sensors are set to trigger actions/lights when they detect movement but only if the mode from above is “Night” or “Evening”... Or if a separate virtual switch you use to override is on.
Is this override switch something you toggle manually as-needed or does something different triggering it for you?
Yeah more or less. Actually, for (1) the lux toggles the mode between day and evening/dusk. My night mode is triggered at 11pm irrespective of lux. So in the morning when average lux reaches 130, I switch to day. Then if average lux falls below 100, I switch to evening/dusk. I can't remember the exact lux values (away from home right now) but it's something like that. Then for (2) I put a conditional exit at the top of all motion lighting rules. This says that if the mode is day AND a separate virtual switch (I call "lights on during the day") is off, then exit the rule. Then I proceed with the rule to turn on the lights if the trigger Motion is sensed. It works really well.
Actually, I've moved all my motion lighting rules over to Node-RED because I just couldn't achieve the response times I wanted from Hubitat. It works perfectly over there and is really snappy with Node-RED just running on an old RPi 3b. I'm using global variables to manage values for circadian temp and level/brightness which change according to time of day and I've found Hubitat really slow when working with variables and suchlike. So anything requiring some complexity and speed is best achieved off-hub in my experience, which frankly is a shame. I'm hoping that one day there will be a powerful enough hub either from Hubitat or elsewhere to avoid this type of issue.