This looks like some sort of data base corruption with is not cleared by performing
Backup-SoftReset-Restore sequence and of course, hub reboot.
Here is an old unused hub variable in question:
plus rule conditions:
So, this rule is not using a variable in question.
But if I delete this variable the Data Base will become even more corrupted in a
very funny way. Attempt to use Export/Import/Clone functions results in
Unexpected Error message.
Actual RM Rules and hub itself seems to be still functional (I think).
I restored hub to the previous (one step older) backup. The Unexpected Error message
was gone and Export/Import/Clone functions are working fine. However incorrect hub
variable mapping is still present.
I have few unused hub variables with incorrect mapping to the rules.
I am afraid, sooner or later much bigger problem may pop up because something is
definitely not quite rite with a data base "as is".
Is it any way to cleanup data base as much as possible?
Ideally I prefer to have absolutely clean data base.
I see this myself. I recently revamped some rules and removed the use of a global variable and started using a local variable. All of these rules were running a common rule, but I found that linking so many rules like this was causing some slowdowns on the hub.
I still use the global in two rules. On the Hub variable page if I select that global it still list all of the rules that I removed it from. In the screenshot below only the first rule and last rule in the list actually use that variable. Can't speak to the error as I have not deleted the variable because it is still in use by those two rules.
This is almost certainly the result of the rule not properly un-registering hub variables it is no longer using (apps must, or at least are "supposed" to, register this use so they show up on the Hub Variables settings page; unlike devices, there is no direct reference that the database keeps between the app and a variable, so the onus is entirely on the app for this). If a rule shows more than you're using, it is likely the result of having once been used and being removed from the "in use by" list of that variable when removed. This would not be database corruption, so a restore would not help, and it also should not cause any actual problems -- though it is something that could likely be addressed on the app side.
This is unlikely to be related to your Export/Import/Clone problem, which as I noted in your other thread is also not indicative of a database problem but rather some unfortunate internal app data that can be worked around.
I should add, given comments in your other thread, that if you want to "fix" this on your own, I'm not aware of anything that would work besides creating a new rule--though copying the actions between the two should save you some work. This is assuming you've already tried the usual tricks like hitting "Done" in the rule to re-initialize everything (I'd actually be surprised if that didn't work...).
However, if my guesses about the cause are correct, this is likely something Bruce could track down and address on the app side so you don't have to.
But again, it shouldn't cause any problems--for the hub, at least (aside from making it harder for you to find apps/rules that actually do use it).
The problem I had with Export/Import/Clone utility happened right after I deleted already unused but still listed in use hub variable. BTW, I am using only one active window while modifying rules. I am not sure if I can reproduce this problem because fixing everything is very time consuming. Hub is running gassilons of automations.
Bringing hub down even for the reboot is immediately noticed by my wife and I am hearing a lot of complaints.
It's possible the Export/Import/Clone utility looks at the old app and tries to register the same variables in the clone, so it's possible there is some connection if the original app still had the old one registered (but I don't know all the inner workings of this utility).
In any case:
This is not necessary to fix the problem with Export/Import/Clone, as you can see with the solution above.
I have this exact same issue. A no-longer installed device with attribute "Button" keeps throwing "attribute Button with >1024 chars hidden" or something similar any time I open the Hubitat app on my phone. I had to rebuild a dashboard completely from scratch because the export/clone functions won't work on dashboards, and several Rule Machine rules also either throw an error or a completely blank JSON file when you attempt to clone or export them.
The "Button" issue is not the same at all, and it's a warning, not an error, and won't stop you from doing anything. (I suspect it's related to internal data used by the mobile app, but I haven't seen anything for sure.) For your export/import/clone problem, I would suggest trying the steps I mentioned in the other thread.
By "exact same issue" I am referring to the database corruption. There is clearly database corruption as the device with the warning shouldn't exist anywhere on my system anymore. I also had an unused hub variable (not related to the button thing) that it said was being used by a Rule Machine rule, but it is not anymore, I completely rewrote the rule to avoid using a variable. Not knowing what I was doing, I removed the Hub Variable anyway. This was months ago and there is no way to undo it now.
The issue with errors when trying to use clone/export features in Rule Machine or Dashboards seems to corroborate that my issues are similar to the issue in the OP.
The OP's issue, as I mentioned above, is not database corruption, and I don't think yours is either. The "button" issue is referring to an attribute on a device used internally by the hub for the purposes of something in the mobile app; the hub variable issue may be similar, and if you are having export/import clone problems, again not corruption, the steps I linked to above should fix it.
If you still suspect database corruption, you can make a backup and then restore it. There is a cleanup process involved with this (no need to soft reset in between, though you'll see that advice in the past--one is effectively performed as part of a restore now). It won't help with app- or device-specific problems (e.g., an app with an internal state that the app code isn't handling well and throws an error under some circumstances), as yours appears to be, so they will likely be there when the hub comes back. But it's a safe process to try (as long as you don't reset anything else), so you certainly can if it gives you peace of mind to rule out this possibility.
