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:
The log shows:
Can I do anything to save this rule - or do I have to remove it and start over? It's not terribly complicated but figured it might be fixable
well, one solution was to export the rule, edit the json so that the variable was a string instead of integer, then import the rule with a new name.
the imported rule had the ** broken action ** on the step that set the variable to the switch status, but that was easy enough to edit/fix.
I left the old rule in place in case there is some troubleshooting/etc that can be done to fix it easier.
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!
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.