---- TO ENSURE A LONG UNINTERUPTED LIST PLEASE REFRAIN FROM COMMENTING ----
Edit: Here are three related rules to manage a Litter-Robot Connect using Dominic Meglio’s (@dman2306’s) Hubitat port of the SmartThings driver and app.
The three rules are pretty much independent, and have been split so you may use one or two if you don't want all three.
With these three rules, the Litter-Robot mobile app (almost) never has to be used. I've revised these rules to reflect observations by @Bear (regarding the DFI (Drawer Full Indicator) flag - DF1, DF2, and DFS status) and his additions to the Litter Robot driver to expose the Litter Robot Status codes, and the observations by @forlornlawngnome regarding cyclesAfterDrawerFull not resetting. Dominic Meglio (@dman2306) has indicated that, at some point, time permitting, he will figure out how to reset the DFI flag from a driver command. I can't figure it out. Until there is a command to have the driver reset the DFI flag, the best way to empty the litter drawer, when it needs emptying, seems to be:
- turn the power off to the Litter Robot
- open the litter drawer, change the bag
- close the litter drawer - the Drawer Open rule will reset everything but the DFI flag
- add litter to the globe to fill to the fill line
- turn the power back on to the Litter Robot, this causes a clean cycle and calibrates the litter weight
- open the Litter Robot mobile app, it will ask if you forgot to reset the Drawer Gauge
- tap the button in the dialog to indicate you want to reset the Drawer Gauge, this resets DFI flag
—————————————————————————————————
Name of Rule: Litter Robot Drawer Open/Close Monitor
Comments: The Litter-Robot has a litter catch bag that fills up as the device cycles. When the bag fills, the drawer must be opened, the filled bag removed, and a new bag inserted. Then, the litter cycle gauge must be manually reset using the Litter-Robot mobile app. This rule automatically resets the gauge (through @dman2306’s Hubitat driver) when the drawer is closed after being open for at least 30 seconds (during bag replacement). This permits taking a peek and closing drawer without triggering reset of the gauge. “Litter Robot Drawer” is a contact sensor on the drawer. The Litter Robot driver doesn’t seem to generate a trigger event for the Litter Waste Level Monitor rule when Level goes to 0 after resetGauge(), hence this rule runs the Waste Level Monitor rule at the end.
—————————————————————————————————
Name of Rule: Litter Robot Waste Level Monitor
Comments: This rule was inspired by @jared.zimmerman’s forum post explaining how he set up an IFTTT automation to change the color of room lights from green to yellow to red depending on how full the Litter-Robot waste drawer was. This rule does the same with our vanity under-counter Hue lightstrips. However, my wife wants the vanity under-counter lights in our bathroom to be navy blue during the night (indicated by a virtual “Bedtime Switch”, controlled by Alexa and a schedule). Additionally, all the vanity under-counter lights turn purple while the Litter Robot Drawer is open (so you can make sure the contact sensor is closed after bag replacement).
Bear (@Bear) correctly observed that the drawerLevel attribute from the driver is only advisory, and is only a guess based on number of cycles since last Drawer Gauge reset, calculated as a percentage of cycles assuming that the previous Drawer Gauge reset was done when the drawer was full 100%. Whenever the DFI flag trips (caused by poop or clumped litter blocking the Drawer Full IR sensor), well, the litter drawer is full, regardless of how many cycles have occurred. DF1 is the first cycle after DFI is tripped, DF2 is the second cycle after DFI is tripped, and DFS is the third cycle after DFI is tripped, and there will be no more cycles after DFS until the drawer is cleaned and DFI is reset.
—————————————————————————————————
Name of Rule: Litter Robot Flash on Alarm
Comments: I quickly tired of getting notifications on my iPhone and iPad that the Litter Robot's Litter Drawer was full (you have 3 cycles after DFI is triggered to empty the drawer, and my cats can only poop so fast). While thinking of a solution, I realized that there was a bigger problem, namely, the need to be alerted whenever an Alarm condition existed on the Litter Robot. There are many reasons why the Litter Robot might need attention and won't perform cleaning cycles - the bonnet could be dislodged, one of the globe positioning sensors could be broken, etc. You can read the driver's code for all of the various issues that case alarms. So, this rule flashes the lightstrips under our bathroom vanities (without changing their color) when such an alarm condition exists that needs attention.
As most or all of you know, Rule Machine has a very special idiomatic form to do a "While ... Repeat" equivalent, namely, "Simple Conditional Action", which tests a single condition prior to entry into the repeat loop, and prior to each return through the repeat loop. So, in order to use this idiom that only allowed a single condition to be tested, I had to build a boolean "OR" expression and then test the result of that expression in the "Simple Conditional". Otherwise, if multiple conditions were permitted for this "while" idiom, the rule would be much simpler, and only have the few lines in the middle.
Some in the forum have pointed out that the second building of this boolean expression at the end of the Repeat loop seems redundant in view of the "Stop Repeating Actions" prior to the "Simple Conditional Action" statement. Perhaps, but my response to this is: First, my intent was to exactly replicate the "Simple Conditional Action" idiom, except with a full boolean expression "OR" conditional, which tests the condition prior to repeat loop entry the first time and also prior to repeat loop entry each successive time; and, second, during testing, I have seen instances where there were multiple threads concurrently executing in the Repeat loop (observed by double-frequency or zero-frequency flashing). Remember, each time the lastStatusCode changes, a new thread instantiation is triggered that concurrently runs the rule. That's also why there are two different local variables used to build the boolean expression. I've never seen this version of the rule fail.
---- TO ENSURE A LONG UNINTERUPTED LIST PLEASE REFRAIN FROM COMMENTING ----
