Litter Robot Connect

My device has stayed connected and working with ST since the last reauthorization I did weeks ago. The only integration I have is to turn on the bathroom exhaust fan when the cat is detected, and I also set up a routine in Alexa so that I can recycle the unit with a voice command. (I rarely use it since I’m usually already right in front of it when I need to manually cycle it.)
As @vf21213 said, it’s a great device even without the integration. I bought a refurbished unit and saved about $90. You can find the reconditioned units on their web site when they become available.

I finally got around to setting this up and testing it out. Thank you, @natekspencer for doing the heavy lifting - it works great so far. I made a few changes and submitted a PR on GitHub - but if anyone’s interested they can pull my code there if @natekspencer doesn’t agree with my changes:

  • Added support for “SDF” status code, which seems to be “started with drawer full”
  • Changed the potential values for “robotCleanerMovement” from the raw status codes from LitterRobot to match the stated values for the capability.
  • Set any “human needed” status to be an “alarm” value on “robotCleanerMovement” - I know Nate mentioned not wanting to do that on this comment Litter Robot Connect

I’ve also modified CoRE to support the robotCleanerMovement capability (also a pull request here https://github.com/ady624/CoRE/pull/81 although the project seems stalled).

Using CoRE, I have configured my Inovelli LVW30-SN set to flash the notification light when human interaction is needed - since our Litter Robot is in a closet in the basement we have a tendency to forget about it.


That said, I think the idea of “child devices” that are switches is probably the right one. Nothing seems to know or care about this robotCleanerMovement state, so most simpler automation smartapps I’ve seen don’t even show the device as available for triggering automation. CoRE is kind of a special (in multiple uses of the word) case.

2 Likes

Thanks, @ydant. I’ve merged that PR on GitHub so it’s available on the main branch. Like you mentioned, I don’t think any security related integrations are looking at the robotCleanerMovement’s “alarm” state, and if they are, they probably shouldn’t be in my opinion.

Confirmed. I’m MITMing the traffic between the robot and server, and the reset gauge request never makes it to the litter robot, so it seems to be server-side only.

That would be interesting to look through. I don’t really care enough about remote control right now to go through the extraction effort, but I would love to crack this checksum issue.

Same. I’ve written mine to MITM and forward all commands unchanged, so everything works normally, but I get instant updates internal to my network (I’m using zigbee2mqtt and Hubitat now). I’m only using mine to monitor status and turn on a notification LED on my Inovelli switches, but I find that to be really helpful to keep from forgetting about it. Is your project available anywhere?

Here’s my current effort - GitHub - mbafford/litter-robot-to-mqtt: Intercept communication between the Litter Robot and the server and rebroadcast to mqtt - I finally dusted it off and updated after two years. Maybe this time it’ll stick.

I’ve also started a GitHub issue with my thoughts about the checksum if anyone wants to collaborate there and try to crack the checksum nut together.


I’m also convinced the CS#### values sent in the Litter Robot status represent the weight measured by the robot. Values seem to range between CS0040 - CS03FF in my limited testing, and once you go over weight, they become CS33FF and the status changes to CSF (cat sensor fault). The CS3 seems to indicate overweight.

There’s also an occasional CS1### where the last three digits don’t change - but I can’t figure out what that means. I’ve never seen CS2### or anything higher than 3.

The weight is not represented in the JSON API. I am going to experiment more with that, but it may be useful for locally indicating the Litter Robot has been overfilled - which leads to issues with successfully cycling, so detecting it prior to a cycle attempt would be really helpful.

1 Like

I’ll have to look to see if I’ve still got the code lying around anywhere, I never got around to publishing it to my GitHub account. Same with the dump of the flash. Turns out it wasn’t that hard to do if you’re comfortable soldering on to PCBs - the only thing I’d recommend is to solder straight on to the ESP module - don’t trust anything else on the PCB.

1 Like

Hi @natekspencer, is it possible to expose the last cleaned in the device handler so other smart apps (ie core) could view this info? I’d like to be able to turn on a light if the litterbox hasn’t performed a clean cycle in X hours (usually means I need to add more litter)

I just pushed an update for this. You should be able to access it in Webcore now. You’ll have to parse the date like so:

datetime(replace(left([DeviceName:lastCleaned], 19), '-', '/', 'T', ' ') + ' UTC')
1 Like

Wow that was fast, I pushed the updates and get an error when attempting to get the attribute

Did you make sure you published the device handler update as well? If you go to your devices screen on graph.api.smartthings.com, do you see a “lastCleaned” current state for your litter-robot?

I did publish the device handler as well, and I do see a lastCleaned state on that page.

webcore still says that lastCleaned is an invalid attribute

Nate,

I ended up removing my litterbot from webcore and then re-adding it and now it works, it must cache attributes or something like that.

Thank you so much for this addition

1 Like

Hi @natekspencer, I saw that you were looking into updating the manager app to try and fix the authorization error, I’m running into this myself now where somewhat often it looses the token.

If you can’t figure out a way to consistently keep refreshing the token, perhaps a notification for when the manager loses authorization?

I’ve updated the manager app to address reauthorization failures. It will now perform reauthorization with an exponential backoff strategy. It will also update the status of any litter robots that are controlled by it so that you can visually see there is an issue.

You’ll now see something like this:

I’m trying to use smart lighting to alert me when the drawer status is full, but I can’t seem to figure out how to do it. What kind of sensor/trigger does the app register when the drawer is full that I can call in the Smart LIght app?

Thanks.

I use webCORE to be able to do this, rather than the Smart Lighting app.

I’m trying to setup this up, but I’m getting an error that ‘No API key was found’. I’ve no idea how to find my API key, nor is there a place to enter it. What am I doing wrong?

edit: I found the API key you posted, and found that I needed to enter it in the IDE. Can you put that API key in the Github README?

Great idea, @flyize ! It’s been almost a year since I published the initial app here, so it’s harder to find in the middle of the conversation now then it was initially.

1 Like

Also, is there a way to set a flag if it needs help? I found that CSF’d and never restarted itself yesterday. I’d like to setup a Webcore piston to ensure it tries to restart itself a couple more times and then alert me.

The litter-robot will enter an “alarm” state via the robotCleanerMovement property if it is an issue status such as CSF. I’m not sure what you mean by “restart itself”, but you can trigger things off of that state. I have a webcore piston myself that changes my hue lights to red and flashes them every 45 minutes based off of that exact state.

1 Like

Hi!
Will this app run ok in the new SmartThings app?