Hi, I track the number of times a water sensor turns wet each day using a Hub Variable. I have an RM rule that has a required expression of variable >0. The app sends a notification to my phone and logs the value. These are being reported as null. I don't believe there is a typo in the variable name. Any ideas?
Are you waiting for 21:00, or are you pressing the Run Now button?
1 Like
It ran at 21:00. I received a null notification, exactly what it shows in the app listing I attached.
An actual trigger or "Run Rule Actions" shouldn't affect anything in this rule. Either is a good test for the text in question.
From what I can see, this should work. Maybe copy and paste the variable name just to make sure there aren't any typos? With a rule this small, it would also be easy to recreate just to verify it isn't some weird problem with the state of just this one.
1 Like
Same result. I recreated the rule, copying and pasting the variable from the list of hub variables. I did a run rule actions, and I'm still getting null events reported, even though the variable reports greater than zero in the required expression.
What else updates the variable? And what's the current value?
Might be worth including a log entry for the hub variable as a log entry in the rule....
Think I've pinned this one down... seems you may have a trailing space in the Hub Variable name. I created two copies of the same hub var, starting with the trailing-space version, which causes RM's match pattern to fail:
...and after creating the 2nd hub var with no trailing space... (can you tell which is which? I can't)
...the rule works as expected:
So I will suggest you either (a) add a %space % to your match pattern, or (b) re-create your Hub Var.
Pinging @bravenel to ask whether Hub Vars should be permitting leading/trailing spaces, and if so, how users can visually detect (or edit) that case.
P.S. Meanwhile, the Req Exp of the OP rule evaluates regardless because it points directly to the trailing-space copy of the Hub Var rather than by %reference%.
1 Like
Hopefully that's it... Still not a great outcome.... but something that can be handled...
1 Like
You're right! I added a space to the end of the variable name (before the %) and ran the rule actions and it worked fine. Thanks so much for your help. I had looked at this many times and didn't see the space there. Even copying from the Hub variable list and pasting didn't work, I guess when I selected it, the trailing space was not included?
I agree with your comment that it would be good for the system to check for leading or trailing spaces and delete them, when variables are being created.
1 Like
Fairly certain that the UI -- both on the Hub Vars list and internally in RM drop-downs -- is trimming any leading/trailing spaces, so you cannot easily test for their presence. Also, since invisible/whitespace chars are not expressly prohibited – in the way ' " \ ~ [ : ] < > chars are disallowed within hub var names – care is essential at inception.
The good news is that you can rename Hub Vars that are being used; just click the name, then RENAME, but you will have to type it from scratch in the text field rather than an in-place edit:
More good news is that if you encounter a naming conflict in the process, Hub Vars will warn you:
NOTE: In this unusual case, attempting to rename either hub var will produce that warning, evidence of yet more space-trimming going on internally.
Glad this got squared away. It was gonna keep buggin' me! 
Thanks again. Might not be a bad add to change the rules to prevent new variables from being created with leading or trailing zeros? Now I can focus on the issue of figuring out if the sensor is getting "splashed" and giving me wet signals, if I'm getting false wet detections based on how it's mounted, or if it's losing it's brains.
1 Like
