I would like to create a rule to adjust lights, triggered on the value of "cloudiness" in the open weather device. It seems I have to use the Capability Custom Attribute and under comparisons I only have =, !=, contains, changed, is empty and the value option is text. I am looking for a condition that would allow me to compare via < or > and a numeric value.
You can put a string into a number variable, it must be a valid number value however.
What about the greater than or less than comparisons?
After converting the string to a number the > and < comparisons are available through RM
ok I typed 50 in there and still no < or >
Are you using a numeric variable or the string attribute?
Following on from @thebearmay above.
Below is a rule to save the 'cloud' level into a variable.
You can then use this value in RM.
1 Like
You're testing a TEXT variable, it needs to be Number or Decimal
cloudiness in the weather device is 75. in this case. That looks like a number to me. If it is text how can I change it to a number?
ok let me check into that
1 Like
Create a number variable and then put the attribute into that variable. It can be a local or hub variable.
Just put teh device attribute into the hub variable you don't need to make it a connector.
1 Like
Still not getting it,
so you are saying I have to create a separate rule to set the hub variable?
then I can use that as my trigger for the rule to update my lighting.
I will check it out. Thanks
1 Like
You could do it in the same rule. Just have your rule trigger whenever cloudiness changes. You can then put the cloudiness value in the hub variable and then do something based on it's current value.
You could do this without a separate rule by triggering on "changed" and then doing some work with variables in the rule to compare the value as a number, but if there is some advantage to controlling when the rule triggers (e.g., for "Wait.." actions), a separate rule may be better. (EDIT: So the same as @terminal3 said above while I was typing.)
But either option sounds like a workaround for the real problem: what driver is this? If the attribute only exposes numeric data, it should be declared as a number to make things like this easier. If you wrote this code, there are changes you can make; you could also try politely asking the original author (if it is custom/community code) to consider the same. If it's a built-in driver, staff would probably be interested in addressing the issue, too.
