I'm not sure exactly when it happened (I have done the past few updates and not scoured the logs, etc.). However, I happened to see an unexpected error in one of my RM 5.1 rules and got to looking into it--and now I see SEVERAL rules have numerous "Broken Action" lines.
Log lines:
@gopher.ny Any thoughts?
I'm not Victor, but the first thing I'd probably try is rolling back to 2.3.132 via the Diagnostic Tool and, if that doesn't help, a matching hub database backup from just before the upgrade (from Settings > Backup and Restore). You have one, right? 
That would both provide evidence that the upgrade is related and probably help Bruce figure out what may have caused it (if you can show what the action was before).
I'm not saying it can't be related (I saw another post recently with a broken action in .133, so there could be a pattern here) -- just that this would provide a hint at what it could be.
I'm doing all those things now. I wanted to pose the question immediately, in case there was a serious issue.
I rolled back a few versions--and the rules were all still destroyed. Now, working on another tact.
Adding to my post above, I found a broken action in one of my rules, too. This was my intended action:
When I went to edit this action (just for fun...in 2.3.1.133), everything was already selected except the device attribute (illuminance), so something there seems to have been messed up. It was an easy fix. In my case, it is something with setting variables, or perhaps setting variables to device attributes or choosing the device attribute itself.
Going to 2.3.1.130 seemed to fix things on hub1, 2.3.1.132 seems to work on hub2 as well.
It seems to be related to setting variables to custom attributes???
I wonder if it is possible that the problem surfaces in the "show current value" part of the code?
When the device throws an error, rather than just indicating the current values is bad or something--perhaps it causes the entire line to be blown away.
Saying that because it appears several of the issues relate to the "Hub Information" device--which seemed to have some issues in that release...gonna look at that if I get a chance.
This may have something to do with Custom Attribute. I will look into it.
Can you give me an example of the “issues”?
If you look at the rules once I got things restored to a working version, they were all that device (of course, on this hub (my hub1), I run VERY little (it has a very few apps and is mostly dedicated to managing z-wave). So, the "Hub Info" app is one of the few on this one--iow, not pointing directly at that app/driver, per-se. Just that on this hub, that was where the errors were thrown.
And, I saw errors with that device during (I believe) the "config" throwing errors itself into the log (doing a config, etc.). That's likely all lost to history in my version changes though.
Note that this hub was apparently running the .24 version of Hub info. But, my other hub had .26 and also had broken rules. The various errors also might be coming from various versions--as this list is my 'past logs' that cover all my version changes.
There is a bug with custom attributes in Set Variable contexts. We will be this corrected in the next hot fix release, which may not be until Monday. In the meantime, rolling back is advised -- otherwise each broken action has to be fixed by hand.
Those are all timing related, i.e. the hub was still busy when requested for information, and generally will successfully finish on the next poll.
Yep, seeing the same here. Variable type doesn’t seem to matter. In one broken action, a Variable (type string) was set to a string value returned from a custom attribute. In another, a variable (type number) was set to a number value returned from a different custom attribute of the same device.
Any idea when the issue was introduced? I’ve got backups going back quite a way. I assume we are talking platform rollback and database rollback, right?
It was introduced in Release 2.3.1.130. That was March 26 or 27 I think.
Hmm. So, I rolled back to .132 and my rules looked intact again (at least when I examined them all after the rollback).
Do I need to be going back before that (i.e., to .129)? And, do I need to restore the entire DB? Or, should I be safe with just the platform rollback to .132? And not touching anything for now?
Thanks.
Then may I respectfully suggest that, until a fixed platform version is released, one of the staff magicians make the “Download latest version” button in Diag Tools cause 2.3.1.129 (version before the issue was introduced) to be downloaded?
With all due respect, it's Friday night. I can't promise that anything can be done before Monday, and the most likely thing to happen is a hot fix. Something might happen prior, but that's not known at this time.
Ok, it was just a suggestion.
It's 11:42 PM EDT! Just being realistic.
I thought all you guys lived in a house together in Arizona. 
Download the Hubitat app
