Legacy Rule Machine Rules missing Logic Conditions

šŸ“ Rule MachineĀ®
1

Hi,

My rules have been moved to "legacy rule machine". Now a bunch of my logic conditions that took me a long time to develop are missing. To add insult to injury, I browsed a few threads discussing how to open lzf files so I can take a peek at what the logic was present in my backups.

I had no idea that Hubitat made the LZF data backups encrypted and not user accessible, I switched from wink to hubitat because I thought it was open platform, and now I can't even inspect my own backup data so I can recover the lost logic that I had applied in old rules.

So tell me hubitat team, what is the recommended approach to recover the lost logic?
Everything was working and now it is broken, and I have no way to recover. I tried restoring from an older backup but the rule isn't importing. If I could view the backup, I could at least see the logic and the conditions that were present in my conditional statements. Now I have no way to recover.

Also, the attitude of hubitat locking users out of their own data backups is not cool, I am specifically referring this quote:

I find this to be one of the most condescending statements I have ever read.

Very Not Happy right now.

2

The app's only been renamed so that Rule Machine 5 can take on the name of Rule Machine. Your existing rules should not be damaged at all

1 Like
3

something has happened kind sir, because some of the rules have ** broken rule ** or ** broken condition ** designator inside. I haven't modified anything in months.

4

You don't have to have modified the rules. Did you remove any devices from Hubitat? That's one thing that can cause this problem.

1 Like
5

does restoring a backup restore the devices?

If so I have restored several months old backup with the same issue.

Support email received say they don't work on weekends, so I'm pretty much stuck until tomorrow without being able to view the backup file.

I would also like to know how to restore to a way older firmware version than is available in the UI, is there a public repo of earlier firmware versions that I can download and restore to?

6

Use the Dignostics Tool to restore earlier firmware versions that are stored on your hub.

1 Like
7

image
image867Ɨ280 26.7 KB

1 Like
8

this dialog only lists two firmware versions, 2.2.8 and 2.2.7, I'd like to restore an even earlier version.

does restoring a backup also restore the original devices used in rules?

9

If you have deleted devices and have not subscribed to the hub protection plan, I don't believe the deleted devices are recoverable. The devices are not saved to the backups that are stored on the hub.

10

The device pairings won't come back, but the device in the Hubitat database would be there and should at least trick an app like RM into thinking it's there displaying things the way it used to be.

Regarding old firmware, they used to have a "hidden" endpoint to get the latest 2.2.3 and 2.2.4 (or 2.2.2 and 2.2.3?) firmware versions. Whether those still exist in recent firmware, I don't know, and I'd be cautious if you don't restore a corresponding (or older) database, but it sounds like you have one.

2 Likes
11

If you want to go back further, you can try the following endpoints - however I do not know if they still work or not...

I also do not know if you change the last few characters to 224, 225 if that will work or not... however I did successfully try the following

http://your.hub.ip.here/hub/advanced/download226

After issuing the command, wait a few minutes then look in the Diagnostics Tool and you should see the older Platform version available to restore to. Be careful to have a matched version of the database backup available to restore from after downgrading.

Just another data point - I have lot of older RM rules that have continued to function without any issue after each version upgrade.

3 Likes
12

Those are almost certainly due to a missing device. You must have deleted some device for that to happen. I have a ton of old rules, even Rule 3.0 that work.

You might be able (if you can open the rule) to edit the broken lines and add a new device.

Also, why not recreate the logic in Rule 5? If you open the old rule in one window, and the new rule in another, you should be able to fairly easily recreate the old one. I get that it is a bit of work, but even a super complex rule shouldn't take more than 5-10 minutes to recreate.

I was on Wink too, glad you got off that sinking ship. Nobody official, or anyone who knew what they were talking about, has ever promoted this as an "open" platform. Instead it is a local platform or one that can run offline. Open or open source imply that the source code for this would be available to everyone. Hubitat has never been that way.

Um, Bruce has an interesting way of saying things sometimes. And remember that you can't always read tone or intent through words. He really is a good guy and is very helpful to users on here. I wouldn't take this one sentence quite so literally. But I get his meaning, they don't want people mucking about in their hub firmware for a variety of reasons. One little edit or typo somewhere, and you have crashed the whole thing and are expecting support to fix it.

4 Likes
13

Interesting. I could have sworn the device was gone when I previously loaded a backup. But, then again, I can't remember what day it is or where I live most of the time. I apologize for the misinformation.

14

In this case, I believe what could have occurred is that a device driver update or some such similar automated process has renamed the device or otherwise altered the device driver causing the name of the individual sub-components on which I was depending for these rules to change. It is this scenario that I believe is the root cause for why the devices are missing, including in the list of defined conditions. What I noticed is that in the logic or condition editor drop down dialogs, I am able to see blank entries that are otherwise very thin width as opposed to the normal width of regular entries like symbols ( ) or IF AND, etc.

I have not heard back from support yet regarding whether they are able to recover the original logic and objects that were present in the database.

15

What kind of devices are they?

Did an app create a group of child devices, or something like that?

16

Taken out of context, perhaps. But there are some very vocal supporters of the concept of open source software that seem to have trouble accepting that Hubitat isnā€™t an open source project (as @neonturbo explained).

17

Changing the name of a device alone wouldn't have caused this; apps, including rules, reference devices by their internal IDs (not the DNI). But in a parent/child situation, it's possible switching to a different parent driver could have added or removed child/component devices, which could have caused this if the rule referenced one of those (which are otherwise mostly the same as other devices, having their own IDs and being able to be referenced by apps without the app knowing anything about the parent or other children). So it's possible something could have happened there.

The situation you note in "Manage or Create Conditions" is one that may also happen when a device that is referenced to in the rule was removed. This alone is harmless, but if the same devices (and maybe conditions--I'm not sure how much that breaks things there) were referenced in the rule, you may end up with "Broken Action." Removing and re-creating the action should address that if you remember what the action was; Rule Machine can't fix it on its own because whatever was there isn't there any longer.

18

I don't believe there is any way that support can recover anything concerning "original logic". If objects that were in the database are no longer there, which is what causes the holes in rules you are describing, there is nothing that will bring them back. If you have backups you could restore those to have a look at the past (download a new backup first, so you can get back to the present again).

At this point, you are probably spending much more time and energy fussing with this than it would take to recreate what you need.

As a general comment, it is not really a function our support provides to try to recover things like this, nor to solve problems with built-in apps of the type you are describing.

It restores their database entries. But if those devices were unpaired from your hub, restoring a backup does not cause them to be rejoined.

Again, it restores the database to its prior condition. That may or may not be useful, but as a way to see how things were in the past, it might be helpful.

19

But in a parent/child situation, it's possible switching to a different parent driver could have added or removed child/component devices, which could have caused this if the rule referenced one of those

I believe this might have been the case, or an update to the driver could have reset the device / child names.

Removing and re-creating the action should address that if you remember what the action was; Rule Machine can't fix it on its own because whatever was there isn't there any longer.

Makes perfect sense, thank you for the feedback, I believe this is the case.

20

If you have backups you could restore those to have a look at the past

Apparently restoring a backup isn't bringing back the original logic in the rules, so that's why I was insisting on questioning specifically what all is restored in the backup process.

I think at this point even if Hubitat insists on keeping the encrypted database format, Hubitat should consider enhancing the backup process in the following way: to generate and export the json of each rule machine rule and archive them in an unencrypted compressed format, zip, gz, whatever, and include that inside a container archive that would also include the encrypted H2 database. That way users would have the option to unzip the parent container archive and recover a zip with all the rule machine JSON exports.

Something like this sure would have saved me a lot of time and or trouble, that or create some sort of administrative rest api endpoints that would allow me to dump the json of specific rule machine rules via automation, that way I can setup a cron job to run some script that will hit those endpoints and backup the json for multiple rule machine rules on a regular basis.

Please understand, you are giving your users a false sense of security when clearly there are gaps in the administrative interface object consistency / relationship validation logic. Your object validation logic has holes in it clearly, and if it is possible for a device rename or driver change to significantly break the rule machine rules in this way, which leads to irrecoverable data and time / effort loss for your users, then you should provide an improvement here.

This whole time I was relying on the builtin backup functionality and thought my hard work was safe. Now it seems like the logic that took me some time to develop, specifically, temperature comparisons being made between sensors (relative to device) that were child objects of a parent device (specifically, DS1820B temperature sensors wired to a Parent Fibaro Smart Implant device) are now lost, so to recreate the logic represents a few weeks of trial and error perfecting the logic and the comparison, plus there were temperature offsets that were arrived at by trial and error. Not exactly very intense or complex in terms of depth, but certainly representing lots of time spent tinkering to recreate the original logic.

Regardless, the Hubitat team should come to the self realization that A. their product isn't 100% foolproof, nothing is, and in light of this grant some leeway to their users by either A, decrypting your database to allow users to inspect the data, with the caveat that manual modifications will void any type of supportability, or B. enhance the backup logic to generate and include json exports of the rule machine rules and include them in an archive package that contains them in unencrypted form along with the still encrypted h2 database.

Don't appreciate the dismissive nature of this comment incidentally:

At this point, you are probably spending much more time and energy fussing with this than it would take to recreate what you need.