Rule Machine custom attribute bug

[yototogblo]

It seems like with the latest release of HE, using custom attribute in rule machine is broken. When I select a custom attribute, at times it doesn't give the option of *changed, "=" etc. The screen just stays stuck. If I change the custom attribute a bunch of times, it might then give the wrong option (like showing ">" for a string). Seems very buggy right now. Anyone else experiencing this? I'm on release 2.2.6.140.

Thanks

[Sebastien]

Are you using a custom driver and if so, which one?

This might be an issue with the driver you are using. There are some attributes that are sometimes used in drivers that don’t play well with Rule Machine.

I had this issue in the past and this is the information that I got from the Hubitat team.

[yototogblo]

Thanks for responding. Looks like you're right. I tried another custom driver that I have rules set up for and didn't experience this issue. How did you resolve it in case?

Here's the custom Logitech Harmony Driver:

[Release] Logitech Harmony Hub Driver v0.1.20230311

WARNING - v0.1.20221230 is a BREAKING code change. DO NOT UPGRADE to this new version unless you are willing to spend the time to start anew with your Hamony Hub integration with Hubitat. This new version now uses Hubitat's built-in Generic Component Switch driver, which has the benefit of allowing the Child Activitiy Switch devices to show up in the new Hubitat HomeKit integration. v0.1.20230311 Added proper support for the push() and hold() commands on the parent device page. v0.1.20221231 …

[Sebastien]

I have that one too - what attribute are you trying to use? I’ll give it a try to see if I have the same issue.

[yototogblo]

Ah, you're fast... I just changed my response completely. I thought I was using custom attributes previously for that driver but I was using it for a different driver and turning things on for the Logitech driver.

I'm trying to use custom attribute "bulb1Level". However, I'm experiencing the issue with every custom attribute so you can try any other one also.

[Sebastien]

When I experienced this, the developer joined the conversation and if I remember correctly, he was able to update the driver so that it would work.

I’ll see if I can find the thread again... (might not be as fast doing that... )

[Sebastien]

Would you mind taking a screenshot of the rule, specifically the point where you are having an issue? I tried to reproduce, but I think I’m missing something...

[yototogblo]

Actually, I think I figured out the issue. The developer used "Integer" to define the type of the attribute (for bulb1Level, bulb2Level, socket1Level and socket2Level). Looks like Hubitat doesn't recognize that and requires it to be "Number" or "Decimal". I just changed it to "Number" and it seems to be working fine now!

[Sebastien]

Yup! As I recall, that is how the issue needed to be resolved. You’re good!

Tagging @ogiewon in case he wants to update this in the driver, if he feel like it, for the other users.

[yototogblo]

Thanks for your help man! @ogiewon please would you mind changing the type of the attribute in your code. Thanks

[bravenel]

This keeps coming up. The valid types for attributes are Number, String, and Enum.

Not Boolean, Integer, Decimal...

[Sebastien]

@bravenel

This keeps coming up.

Right?

Hey, how about a new feature when saving code - search for “Boolean, Integer and Decimal” and throw a warning. (not being serious...)

[ogiewon]

@Sebastien

Tagging @ogiewon in case he wants to update this in the driver, if he feel like it, for the other users.

@yototogblo

Thanks for your help man! @ogiewon please would you mind changing the type of the attribute in your code. Thanks

The Logitech Harmony Hub Parent driver has been updated in my GitHub repository. I guess I need to review community pull requests more carefully. Thank you for the feedback!

[JasonJoel]

Not to be pedantic, but there are a few more valid types per the documentation:

https://docs.hubitat.com/index.php?title=Attribute_Object

dataType - String: The type of data that is stored in this attribute, possible values are (ENUM, STRING, DYNAMIC_ENUM, JSON_OBJECT, NUMBER, DATE, VECTOR3).

But definitely no boolean, integer, or decimal listed.

[bravenel]

@JasonJoel

Not to be pedantic,

Don't let that stop you....

[JasonJoel]

Can't really argue that, now can I?

At least I'm self aware of my annoying tendencies. lol That has to count for something, right?

(also, sometimes I think I point out things like that as a passive aggressive way of verifying the documentation is correct)

[bravenel]

OK, I was avoiding being pedantic before. But, to honor your sentiment:

Rule-4.1 also recognizes STRING_ENUM, JSON_OBJECT and VECTOR3. These are treated as ENUM, STRING and VECTOR3 respectively. It does not presently recognize DYNAMIC_ENUM or DATE.

I should spend a few minutes to make Rule more gracefully deal with non-supported attribute types, although my passive aggressive side likes throwing an error at those who tempt the fates with unsupported attribute types. It's a good mechanism for getting driver devs to be notified they have an issue.

[yototogblo]

For the sake of users, would be great if there was a way to identify the issue quickly (like an error message when selecting the attribute) as opposed to having to investigate it.

[bravenel]

You didn't provide enough information above for me to know what actually went wrong.

[yototogblo]

I'm responding to your comment above. It'd be nice if an error was thrown in rule machine that made it clear that the custom attribute had the wrong type set. Otherwise, anyone would think it's an issue with rule machine itself.