I had an existing/working rule where i also wanted to track a switch's on/off status in a variable.
so I added a local variable (number) and set the variable to a device attribute (switch). I didnt know what kind of variable i needed at the time, and figured I could change it later if needed.
I don't know if the number<->string mismatch is what's causing a problem, but if i try to view the rule, i get an odd error:
That doesn't seem like an odd error, given that you're trying to put a string into a number. Nevertheless, I will look into catching/preventing that from happening. Rules, and variables, are 'strongly' typed. It matters that you only put a number into a number, etc.
Yeah, I get it. I just didnt know/couldnt tell which the switch type would be. I could see it being integer/boolean- and my last thought was string. So my thought was to just try each.
is it interesting for you if I keep the old rule since I have the new one working?
No. I've put in the type checking for Custom Attribute.
For numbers there could still be a problem, for example there is no way (usually) to distinguish between a decimal attribute and an integer attribute. Trying to put a decimal attribute value into a number variable would still cause an error. Yet another level of type checking to catch that one!