I have a simple time-triggered rule that lowers my west-facing shades every day at noon, and I'm using the OpenWeatherMap native device to determine weather conditions which I include in a Required Expression for the rule. The required expression currently prevents the shades from lowering if the "weather" attribute contains rain, mist or overcast. That all works just fine.
However, I'm now realizing that I would be better served by evaluating the "cloudiness" attribute instead, because I'm finding that there are many other "weather" conditions for which my shades don't necessarily need to be lowered and I'm not keen to include every possibility in my required expression. My challenge is that the "cloudiness" attribute is a string, not an integer.
I do know how to define a local variable and transfer the value of cloudiness (string) into a local integer variable and evaluate it. Where I'm stuck is how to do that in a required expression, which is evaluated BEFORE any actions run.
Is there a way, within a rule, to transfer a device attribute (in this case, the "cloudiness" value from OpenWeatherMap) into a local variable other than with an action? Or would my only option to be to create a separate rule that is triggered one minute before my shade-lowering rule which populates that cloudiness value into hub-level integer variable which my Required Expression could then evaluate when the shade-lowering rule is triggered one minute later?
Am I missing a trick to do this in a more streamlined way?
Rather than do a local variable, create a Hub Variable and rule that changes it based on "cloudiness." This way you can use the Hub Variable as a required Expression.
If you wanted this in one rule, rather than a Required Expression, you could use a conditional trigger. As long as it is one specific string you want the rule to trigger, the conditional trigger could look for a custom attribute on the virtual device.
You may also want to consider the possibility that the sun will come back out (not just tomorrow ), so assessing the state of the weather at a single point in time may not produce the desired outcome, unless I'm missing something..... Some kind of check and wait for condition might be more appropriate than a required expression.
Thanks @JB10 - your first suggestion is the one I had already thought of and mentioned in the final paragraph of my post. That means an additional triggered rule running just before my shade-lowering rule, which isn't a big issue, just not as clean/simple as I was hoping for. As for your second idea, that is the challenge that prompted my post. The device attribute in this case is a string value (for some bizarre reason as "cloudiness" is a number), but I need to evaluate it as an integer (i.e. "when cloudiness < 50 lower the shades"). Hence the need to use some sort of local or hub-level variable to get that converted into an integer. Even a conditional trigger would require that the attribute was already converted to an integer first.
@sburke781 - very valid point, and I've thought about that. But it started to make this whole exercise more complicated than I wanted it to be.
So, @UserSeventeen , are you saying that it is possible to compare a locally-defined NUMBER variable against a device attribute STRING variable as if it were an number? In other words, in your example, I'd be able to use a conditional trigger that basically says "If %value% < _cloudMin trigger shade-closing actions" ? And that expression would treat %value% as a number because it's being evaluated against another variable that is actually a number?
@UserSeventeen's example is what I was trying to explain, but their pictures show it better. You just have a simple rule that controls the Hub Variable:
Understood @JB10 - thanks. I do see how to do that, but that still leaves me running two rules instead of having all this happen inside a single rule. Again, totally doable - perhaps I'm looking for a solution that doesn't exist.
You'll need to rethink the trigger. You could use Between Two Times as the Required Expression and the cloudiness value changing as the trigger. You could still use noon as an additional trigger just to make sure that rule runs right away rather than waiting for a value change. With some tweaks, you might be able to get this combined into one rule.
The other thing to consider is that if you are okay with two rules, rather than create a Hub Variable, you might consider creating a virtual Lux sensor and use converting the weather reading to a Lux value. Going this way opens up the possibility of using Room Lighting or other apps that may make it easier to open and close the blinds based on the value.
Agreed. I think two rules is probably the easier route. I do like the idea of converting the value to Lux because Rule Machine and I think Room Lighting can do “and stays” with that value which would help with the flip flopping too.
i wanted to offer another way of accomplishing this. To me this is simpler, but what works for me… may not work for you.
I use SunCalc Driver to know where the sun is in the sky so i know how far down the shades need to be to block out the super bright parts of the sun. In combination with a Lux sensor in the window, i know when the sun needs to be blocked. Using a Lux sensor compensates real time cloudiness and bloom state of a large tree in from of the window as a single, easy to use integer.
Thanks all for the suggestions/guidance. Ultimately, I'm looking for simplicity and what would really be helpful is if whoever created the OpenWeatherMap virtual device just changed the "cloudiness" attribute to type NUMBER rather than STRING. Perhaps there was a reason it was defined as a string variable of length 20, although I can't understand why.
Is that something I request from Hubitat Support, given this virtual device is a "System" virtual device (i.e. as far as I can tell, not developed by a third party)?
In the driver I maintain: OpenWeatherMap-Alerts-Weather-Driver the cloud variables are declared as numeric. You must be referring to the integrated OWM driver? You would have to get to Hubitat Support to to request a change to the built in driver.
), so assessing the state of the weather at a single point in time may not produce the desired outcome, unless I'm missing something..... Some kind of check and wait for condition might be more appropriate than a required expression.
