As @bertabcd1234 explained above, changing the name or label of a device does not break an RM rule. Removing a device can do so, but warnings are provided against this mistake.
Of course, as you point out, nothing is foolproof.
Neither of these are in our plans. You can backup all of your rules separately from the database.
I'm not being dismissive at all, just truthful. I'm sorry you lost things somehow, and odds are those losses are unrecoverable and most likely unexplainable.
you should at the very least provide a facility that dumps all of the rules to json in one go, that way it is more convenient than having to export each one individually.
Anyways, based on this interaction I understand a lot more about the internal dynamics of the Hubitat organization.
That exists now. And being improved in upcoming 2.2.9 release, now in beta. Notice below that you can select every rule check box. Then, all of those are in a single file. When wanting to restore, a similar check box list is offered to select which ones.
Question--there were previously (<2.2.9) some limitations on total size of the downloaded rule file. Do the improvements in 2.2.9 address that? Or would you continue to recommend that people with many/large rules need to still consider downloading their rules into multiple, separate files?
I don't think collectively we have enough experience with the backup and restoration of apps. Notice how the feature I showed above was marked (Beta). Personally, I don't do this for any of my rules, relying instead on database backup/restore. I do use that when I really mess something up. I've got rules dating back over 4 years, done in the original version of Rule (before Rule-2.5, Rule-3.0, Rule-4.0, etc).
In 2.2.9, Export/Import/Clone becomes available for all apps. Apps with child apps allow all children to be exported in a single file.
What happens if you try to import a rule from the backup json if none of the original devices or objects exist, will the import succeed, and will the original rule machine logic still be viewable in the editor, or will it import with missing logic and devices (i.e. broken rule, missing devices, etc.)?
I have dumped the json from one of the rules, judging from a cursory examination of the json structure, it would still be difficult to visually recreate the original logic, perhaps a screenshot at this point would be better.
Or perhaps a simple viewer that would present the facade or visual representation of the original logic and devices, essentially a visual recreation of the rule machine logic as it would otherwise normally appear in the rule machine editor for valid rules.
If no device exists, it will create a virtual device of the correct type, with the correct name. It offers "device replacements" if Import is chosen (as does Clone), where a different device can be selected.
This facility was created to allow installation of apps on different hubs, where the device DNI may not exist, and would certainly be different if it did exist.
I will try to restore from an even earlier database backup, what puzzles me is that restoration of a very old backup failed to restore the original rule machine logic. It tells me that potentially there was some corruption of the original rule due to the sometimes quirky behavior of the rule machine editor, specifically, when working on a complex or deeply nested rule with many nested if / then blocks, I have noticed that occasionally the editor gets a bit jumbled or confused about what should go where, and I have been able to "fix" the rule in order that it displays properly in the editor again, but was always left with the nagging doubt as to the veracity of the objects and their relationships, in other words, whether the object relationships were being saved to the database correctly, and whether that could be the actual root cause of my issues.
I note this simply because on restoration of the older database, I am seeing an extra open parenthesis displayed without a corresponding subsequent closing parenthesis in the rule logic.
In any event, thank you for the time and effort to answer my questions, it is much appreciated.
The database is fully backed up and faithfully restored. For a given app, say Rule-4.1 for example, we are pretty careful about backwards compatibility in new platform builds. So a Rule-4.1 backed up on one build, should work fine on a new build, and not be corrupted in any way. This is why we change the actual app versioning, for instance to Rule 5.0. A Rule-4.1 cannot be used with Rule 5.0, because the internal data structures are incompatible. But, Rule-4.1 is still in the platform, so it should still work as it did before (all prior versions are still in the platform).
OK, I was a little bit less angry today and had more time to restore older database backups.
Here's a graphical depiction that tells the story, apparently the July Backup and all subsequent backups were broken, i.e. the rules were already corrupted. It was indeed a device driver update or change that caused a name reset of those child objects.
I don't know how to improve this other than perhaps to check and see if broken rules in rule machine exist, and warn the user when he performs a backup that certain configurations are already broken? That way at least he knows that the backup he is taking isn't really protecting him in the way he thinks it is?
I could see someone rotating out older backups and then ending up with a worthless backup in this scenario.
So yes, at the end of the day, the earlier backup did restore the original logic, however, I've no idea now when was the last time I have updated those objects, so if the later backups contained changes to the original logic, that logic is lost.
The reason I was so upset is that I restored a July backup and that was still broken. Luckily the earlier May backup I think had the latest logic. A running change log of all items modified would be helpful here, because at the very least I could see what was modified when. This would help me determine which backup contained the latest changes to what objects (when they were last modified).
This is incorrect. The names of the devices is not the cause of this, or them being renamed somehow (which drivers don't do). Try it for yourself: put a device in a rule, and then rename the device, and see what happens to the rule in question.
These devices were removed. Who or what removed these devices? Not the rule, not the driver...
Another thing you can try: Create a virtual device and include it in a condition in a rule. Then remove the device. Refresh the rule page and see what you get:
This is incorrect. The names of the devices is not the cause of this, or them being renamed somehow (which drivers don't do). Try it for yourself: put a device in a rule, and then rename the device, and see what happens to the rule in question.
I see, OK, fair enough. The problem is that I did not remove the device.
Is it possible that another piece of software like the hubitat package manager removed and re-added the device transparently during an update? Or that some zwave event caused the device to be removed? I am speculating here because the package manager performs updates and I've no insight into its process.
I just know I didn't remove this device. There would have been no reason for me to do so. Also, I think it is odd that I didn't notice these rules were broken although admittedly once I got this logic working I left the hub alone for a period of months, and it was during this time that the hot tub was not in use (summer, etc.).
So while I don't disagree with your diagnosis regarding "removed device" being the root cause, I suspect some hubitat package manager driver update caused this in the background, as I have to insist, I did not go through a device deletion process for this device.
Is there an audit log that logs administrator actions and objects acted upon in the ui? If so we can take a look there to see if a device remove action was performed and by whom (manual user action or some other piece of software)?
@dman2306 would know for sure. But I don’t think Hubitat Package Manager can add or remove devices, it just adds/removes/updates driver (or app) code. Also as a community-developed app, the code is publicly available on GitHub so that anyone can gain insight into its process.
Correct. If a device existed it won’t let you uninstall the package it uses. Any time I’ve seen a device disappear, it wound up being a db restore I forgot about.
I have seen "something" cause devices to appear "broken" in RM without removing them too. I have 3 Google nest hubs. These are the devices that were recently updated to fuscia.
What I found was that the devices were not DELETED BY ME but had been deleted by either the update from Google or the update to the Chromecast integration or something else and had new names. I didn't know they were not working until a couple days ago.
I am only posting so that @lcstyle knows that this has happened to someone else too. For me, it was an easy fix and I chalk it up to one of the many flukes that happen on an inexpensive piece of consumer electronics.
Incidentally, I have found that there are two drivers for this device installed in my hubitat device. One is a system driver, and the other a third party user level driver. It is very very possible that I switched between them at some point. I am going to restore the May backup which restores the original device and the original rule machine rules, and attempt to switch between the system and user installed third party driver to try to reproduce the issue.
If the hub is put into Z-Wave exclusion mode, a Z-Wave device could be removed during that period without any warning, should someone touch the button on the device. There is no mechanism that I'm aware of that removes devices during updates. We'd have heard of this given the many hundred thousands of individual hub updates that have taken place.
Not that is preserved for any length of time, and only in so far as apps or drivers create such logs. Generally speaking, most apps and drivers do not log their own removal.
I'm afraid it shall remain a mystery how your devices were removed, thus messing up your rules.
