I have this rule in RM Legacy... and when picking "Custom Attribute" I get the proper dropdown as shown here
But when I try to create the same rule in RM 5.1 on the same hub...
I just get two standard attributes to pick from.
Has the process changed that much from RM Legacy to RM5.1 or.. these functionalities not been implemented yet in Rm 5.1 ?
What driver are you using for this device? Rule 5.1 will only show you attributes whose type match that of the variable you are using (this is a change, and I guess the other half of this question is what kind of variable it is--but I've only seen driver issues so far with this). If it's a custom driver, the author (or someone) may need to fix this. If it's a built-in driver, staff should be able to.
I'm a also assuming you're on the latest firmware because there was a related fix recently.
it is a custom driver.. for AEON HEM v1..
I changed the attributes from string to number, and it starts showing up on the dropdown.. ( but not if I make it a decimal..)
BUT.. as soon as I click the "powerOne", it goes to this screen
and I see in the error log..
app:4022021-10-21 03:12:43.888 pm [error]
java.lang.NumberFormatException: null on line 5017 (method selectActions)
after that.. if I click on "done".. I see this...
and the only option is to remove the rule.. because clicking on "Select actions to Run" goes back to the numberformat exception
NUMBER and DECIMAL are different types (the former restricted to just integers), so it's not surprising that you see a difference there. But if it's really sending a string for your attribute, which I'm guessing is powerOne (and it's definitely a string in that driver--it's an interpreted GString, double quotes, $, and all), just changing the attribute's definition at the top of the driver won't work; you'd need to make sure it's actually sending the correct data type with the event.
A bigger question: is this driver still maintained, and did it ever work? The first post in that thread doesn't look promising. I know I've seen people use a custom driver for these, but I'm not sure if this was the one, or if there is something further down in that thread that I didn't see.
EDIT: I should also add that if you can just use this value as a string, a string variable would work; and if fixing the driver isn't possible or desirable, RM can "parse" strings into numbers, assuming the string is a valid number (or decimal), with the appropriate actions, so you can probably still make it work in that case, too--just with some extra effort.
i just tested with rule 5.1 and a string variable.. working for me and showing all custom attributes of type stgring in the device handler.. And this iis a custom device handler not built in.. So it sounds like it is a typing issue as mentioned.
In Rule 5.1, since variables are typed, and attributes are typed, it only offers those attributes whose type matches the selected variable type.
if I do a compare of string variables as numbers for comparing values, will that work ?
They would have to be converted to numbers before you could compare them to a number. Or you could convert the number to a string, and compare those. The latter would only get you equal and not equal.
I'm not sure I follow what you want to compare.
good points.. will try to see what would be the easiest and changeable in the future ! will let know how I end up fixing this.
I dont think it is maintained .. it still works perfectly fine in RM Legacy, just not in RM 5.x
your idea probably would work.. in that to cast the string to decimal and then use it.. that would be the easiest to do and maintian in the future as well.. without having to change any of the driver code.
since the custom driver is a Home energy meter driver.. and I was using it in the Rule.. I was trying to compare the power usage ( the numbers of the power usage... )
but casting them to number/decimal would work...
Download the Hubitat app
