Litter box warning 🚦

[672southmain]

I don’t know what you named your Litter Robot device, but that’s the name that will appear after configuring things.

Screenshot of App

Screenshots of device

In the device, give it a Device Label name, and, for Type, choose Litter-Robot. Click Save Device.

Then, in the App, select the device’s name, do the authentication, assign the app a name. Click Done.

Now go to the Apps page. You should see the litter robot manager app.

Now go to the devices page. You should see the litter robot device. If you don’t, then you won’t see it in the Dashboard app.

Then go to the Dashboard app, check the box for Litter Robot device, click update, click Done.

Did that do it?

[672southmain]

Actually, you could do a Repair in HPM to install over what you have.

[forlornlawngnome]

@672southmain

You can look at the code for the driver to see other attributes you can expose. Here is the Litter Robot portion of my dashboard:

Depends on if the install is bad or the instantiation is bad. Both are probably worth trying!

[russ-baker]

Thanks for all the help. I logged into HE today and Hubitat Package Manager had an update waiting. It was Litter Robot Manager. I updated and wala, litter robot manager is now working. So apparently that's what it needed.

I added a tile. All the cool attributes available. Veeeeery cool.
Now my tablet on the wall will tell me how full the drawer is.

It simply displays 14
I assume 14%. Help a noob out. How do I make that display the % symbol?
Oh, and is it possible to change the color of the tile based on the value. Say yellow when reach 70% and so on. I have much to learn.

[672southmain]

@russ-baker

It simply displays 14
I assume 14%. Help a noob out. How do I make that display the % symbol?

Yes. You have to add custom CSS, I believe. That’s outside my expertise.

@russ-baker

is it possible to change the color of the tile based on the value. Say yellow when reach 70% and so on.

It’s possible, but not for us mere mortals. A missing feature, requested many times, is the ability to define a custom Dashboard template. The Smartly group (search Smartly on this forum) have done some amazing things, providing drag & drop, etc. They are a bit hampered in doing significant updates right now because Hubitat staff has blocked their hubs from getting firmware updates and has blocked them from the Hubitat forum.

[672southmain]

TL;DR summary: DFI flag is worthless, only the Litter Robot mobile app can reset it.

Details

Ok, I think I have it figured out, and I now understand what @forlornlawngnome and @Bear were talking about, and why I was seeing different results. Thor and Loki finally pooped enough for me to do my experiments. The alternative to extended waiting was to get 6 cats (like @Bear has), which I was hesitant to do (our city requires an animal breeder license if you have more than 5 animals, and we've already got 2 dogs in addition to the 2 cats).

First, the good news. It's not a timing issue, and it's not a Litter Robot firmware issue (well, it's a feature that appears the same on all firmware versions that the two of you have reported, matching what I see). Now, the less than good news.

The issue is with the Drawer Full Indicator flag ("isDFITriggered"). The only way I can find to reset that flag to 0 (once it sets) is to hit the "Reset Drawer Gauge" button in the Litter Robot mobile App.

When the DFI flag turns 1 (caused by tripping the Drawer Full sensor), cyclesAfterDrawerFull start incrementing, the blue "ready" light on the front panel starts flashing, the lastStatusCode (while idle) changes from RDY to DF1 to DF2 to DFS, and the Litter Robot stops cycling while in DFS status (as @Bear correctly reported). Cleaning the Litter Box and doing a "reset" (whether from the front panel or from the Litter Robot driver or from the exposed resetDrawerGauge custom command) doesn't reset the DFI flag. And, the DFI flag isn't real time - cleaning the litter drawer, but not doing a reset in the Litter Robot mobile app, doesn't change the DFI flag. It's set until the Reset Drawer Gauge button in the mobile app is pressed.

The "Reset Drawer Gauge" button in the Litter Robot driver, like the resetDrawerGauge() custom command exposed by the Litter Robot driver, behaves exactly the same as the "reset" button on the front panel of the Litter Robot: they:

1. reset the drawer gauge in the Litter Robot mobile app;

2. reset cycle count and cycles after drawer full;

3. change the idle status from DFS (or DF1 or DF2) to RDY;

4. stop the blue "ready" light on the front panel from flashing.

It DOES NOT reset the DFI flag ("isDFITriggered") to 0. However, because the idle status is no longer DFS (Drawer Full Stopped), the Litter Robot will now cycle. So, it seems to me, as @Bear reported, the DFI flag is useless and is ignored. I suspect that it works the way it does (still allowing the Litter Robot to cycle as long as the status is not DFS) is because some people don't use the Litter Robot mobile app (certainly not the people who don't have a Litter Robot Connect model), so the exposed variables seem to be exactly what they would be in the standard (non-Connect) Litter Robot, and it wouldn't be good if you had to hit the Reset Drawer Gauge button in the Litter Robot mobile app if you didn't use the mobile app.

This is why @Bear kept insisting that the right thing to do was to monitor the DF1, DF2, DFS status. It's why I wasn't seeing this behavior because I was emptying the drawer as soon as the drawer threshold became >= 85 (as @jared.zimmerman did in his original IFTTT rules). It's why @forlornlawngnome was seeing cycle counting since full (cyclesAfterDrawerFull), because the DFI flag was still set.

So, on reflection, @Bear seems to have the right approach, and I will change my rules and repost.

The problem with that is that we often go away for a day or two, and, if the Litter Robot stops cycling (you only get DF1, DF2, then DFS to stop cycling), Loki, one of my cats, refuses to poop in the Litter Box if there is already poop in it. She wants clean litter, and will poop on the floor rather than go into the Litter Robot if it has poop that hasn't been moved into the drawer.

For the time being, after cleaning, looks like the only way to clear the DFI flag is to go into the Litter Robot mobile app and hit the Reset Drawer Gauge (even if the "reset" button on the front of the Litter Robot has been pressed, or even if the Litter Robot driver has done a "resetDrawerGauge", whether by pressing the button in the driver or by having a rule do a "resetDrawerGauge()" command.

Now, the driver has a mystery command "R", with the comment:

R - valid, not sure what it does, though, reset or refresh maybe? weirdly a new parameter showed up called "cyclesUntilFull" after posting this, but still not sure how it is utilized

I will play around with this command, see if it is able to reset DFI. The other way would be to put a sniffer on the ethernet traffic from the mobile app to the Litter Robot server, and on the Litter Robot server to the Litter Robot, to watch the traffic that occurs when the Reset Drawer Gauge button is pressed in the mobile app.

There's got to be a command that can reset the DFI flag because the Litter Robot mobile app is able to do it. I will investigate further, but I wanted you to know the results.

[dman2306]

@672southmain

There's got to be a command that can reset the DFI flag because the Litter Robot mobile app is able to do it. I will investigate further, but I wanted you to know the results.

There is. I just haven’t implemented it. I should have time to test it out this weekend (unless I forget)

[672southmain]

Thanks, Dominic.

[forlornlawngnome]

@dman2306

There is. I just haven’t implemented it. I should have time to test it out this weekend (unless I forget)

Makes me wonder what other secret things they have hidden in their API!

[672southmain]

Reading through the original thread in the SmartThings community forum (where the driver was developed before Dominic Meglio (@dman2306) ported it to Hubitat), the reason the Litter Robot cloud server still remains in the Hubitat loop is that no one has figured out the CRC algorithm used by the Litter Robot device to validate commands from the Litter Robot cloud server.

As long as the Litter Robot cloud server remains in the loop, the Litter Robot risks becoming dumb and unresponsive if the cloud server is pulled offline. Otherwise, the Hubitat driver could communicate directly with the Litter Robot itself.

The original author of the driver (Nathan Spencer) has lost interest in the code because he no longer uses SmartThings and doesn’t want to do the heavy lifting to change the app & driver to the new SmartThings app architecture when the SmartThings Groovy support dies later this year.

[dman2306]

Doubt there is anything hidden. This is just calling the same api the button in the app calls.

[forlornlawngnome]

@672southmain

As long as the Litter Robot cloud server remains in the loop, the Litter Robot risks becoming dumb and unresponsive if the cloud server is pulled offline.

After the PetNet fiasco, this very much worries me! Though it will still at least function locally unlike the PetNet.

Sadly, this is waayy past my networking expertise to even know where to begin.

[672southmain]

Here’s the SmartThings thread. It’s interesting reading.

Litter Robot Connect

[dman2306]

FYI figuring out the checksum wouldn’t just make this integrate. You’d still need to setup a network sniffer to grab the UDP packets and pass it along to hubitat. This is doable but not as simple as “install this app on HE,” you’d need to setup a raspberry pi with an mitm proxy and have it in a position where it can grab the litter robot traffic. So doable but not trivial.

[joe-hennessy]

What is the contact monitoring?

[672southmain]

Whether the bonnet has been removed. Closed = Bonnet is in place. It will show as a status code of BR.

[672southmain]

After reflection upon @Bear's and @forlornlawngnome's comments, I revised my rules to manage the Litter Robot. The revised rules are in the Rule Repository, here:

RM4 - List of example rules

---- 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 (regard…

[forlornlawngnome]

Is there a reason you didn't do lastStatusCode "contains DF" and instead wrote out a condition for each state of DF1, DF2, and DFS?

@672southmain

[672southmain]

Not really. I just went through the status codes in the driver. As a remark, “contains” probably takes longer to execute than a straight compare, and, to me, a listing of the codes seems clearer because it matches the driver.

[forlornlawngnome]

Fair enough! With two litter boxes it just felt like so many clicks to create 6 conditions vs 2