I started writing this as notes on the network activity, but realized it sort of sounds like a review, so I wanted to make clear that I’m just a customer, I have no other relationship with this company, nor have I received anything from them for free.  That said, I think that Litter Robot’s are the best automated litter handler on the market in the last 10 years, I bought my first one in 2009.  They’re robust, easy to use, and work well.

Automated Pet Care Products (APCP) released an upgrade called ‘Connect’ for their latest Litter Robot model (the LRIII) which connects your litter box to the internet to let you monitor it in real-time, and receive pushed notifications of status changes or errors.

Why would you want this?  Many reasons, but a few are–

• Tracking litter box usage can give insights into your cat’s health–yes you can examine the ‘output’, but that doesn’t tell you if your cat is spending time in the box and not ‘producing’, but this app will
• Reminds you when it’s full, or nearly full, which is especially useful if you keep it out of sight
• Gives you peace of mind that the device is functioning correctly (in my experience, once the device is setup having it malfunction is extremely rare, basically non-existent, but now you can know for sure that it is or isn’t working and exactly how long it has been like that)
• You enjoy keeping tabs on the mundane things in life, like watching your refrigerator temperatures or your cat’s bowel habits…

The upgrade to existing LRIII’s consists of:

• New mainboard (physically looks the same, but probably has newer firmware and maybe a multi-colored power LED, it still uses a PICF18)
• Communication board that attaches via a 4 conductor cable and has an ESP32 on it as well as a second PICF18
• New control-face sticker (adds a WiFi logo and is black instead of blue)
• A serial number sticker w/ QR code (the QR code is necessary to set up the app)

I’m wary of anything “IoT” being added to my network, you hear about too many devices become spies or part of a botnet.  With an ESP32 and PIC’s I think the risk is low, I also think that APCP has a unique product with custom written firmware, but I was interested to see what data is being sent around.

To capture that data I used a Raspberry Pi 3 which I have setup as an access point on my network.  Any device that uses its WiFi signal must route packets through the RPi3 which I can grab using a tool like tcpdump.

It looks like the LRIII Connect makes connections to an AWS instance every minute or so.  The LRIII and AWS pass messages in the clear using UDP.

A typical set of messages looks like this:

04:51:29.171485 IP ESP_xxxxxx.cisco-sccp > ec2-54-83-xxx–xxx.compute-1.amazonaws.com.2001: UDP, length 74
E..f……P…*.6S…….Rv.>LR3,xxxxxxxxxxxxxx,H,AC,Rdy,W7,NL1,SM122:06:26,PL0,CS0113,110D,2F23538F

04:51:29.470242 IP ec2-54-83-xxx–xxx.compute-1.amazonaws.com.2001 > ESP_xxxxxx.cisco-sccp: UDP, length 20
E .0.{..-..96S….*………AOK,xxxxxxxxxxxxxx

Note, the italicized x’s were other decimal or hex values, but I removed them to attempt to anonymize myself for this public post.  I’m sure that though APCP would have no issue identifying me if they wanted to though.

The first line above is a typical message from my LRIII to AWS, and the second is an “AOK” return from AWS.

There may be shorter versions of the LRIII message, but I haven’t seen them regularly enough to comment yet.

These are ‘heartbeat’ type messages that are sent very regularly, by doing this the LRIII effectively maintains a bidirectional communication link so that you can push commands to it via their app (like start a cycle, turn the night light on, etc) without any special network setup to allow incoming communication, because the LRIII is always reporting its status which gives the server a chance to issue it commands.

Breaking down the message from my LRIII to AWS it’s fairly clear what is being sent.  I appreciate that APCP is sending their messages in the clear and that they are relatively easy to decipher:

• LR3
  • Model
• xxxxxxxxxxxxxx
  • ID of my LR3 (removed from this post, it has a 14 digit hex number)
• H
  • ???
• AC
  • AC Power Present?  I have a the backup battery, but disconnected it during upgrade to Connect and haven’t yet reconnected it
• Rdy
  • Appears to be the status, I’ve seen Rdy,CST,CCP,CCC which I assume translatea roughtly to “Ready”, “Cat Sensor Timing” (waiting w/ Red Light), “Clean Cycle P” (Cycling), “Clean Cycle C” (Cycling Complete).  This doesn’t appear to change when in sleep mode, so I don’t think it’s a straight translation of the LED pattern to a state.
• W7
  • Wait Time? (To wait after cat exits the box defaults to 7 minutes)
• NL1
  • Nightlight On/Off (mine is on, this goes to NL0 when I turn it off)
• SM122:06:26
  • I think this has to do with Sleep Mode.  It changed to SM100:00:00 at the time when I have sleep mode set, prior to that it was counting up to 24:00:00.  So I assume this is a 24 hour counter.
• PL0
  • Panel Lock On/Off
• CS0113
  • Cat Sensor (weight) (This was 0x0110 when my cat was out, and 0x014F when in… dec “63” difference, so maybe it is 6.3lbs?  I assume this is a post-calibration value and that calibration is done with the known weight of the empty machine to handle variation between load cells)
• 110D
  • Sequence number? Consecutively increases each time.
• 2F23538F
  • Hash? Other configuration bits?  Seems to change each message

Anyway, that’s what I’ve seen so far.  In ~12 hours of observation I haven’t seen any other noteworthy communication or anything that looks nefarious.  The TLDR of this is that I won’t worry much about keeping it on my network–except for the fact that it’s yet another WPA2 client.

One thing I was happy about is that there is no local network communication.  Some devices, like TP-Link plugs and Philips Hue, want to communicate between the mobile app and device on your local network.  This makes using client isolation and guest networks problematic.  The LRIII Connect doesn’t use this–both the LRIII and the mobile app appear to talk to remote servers as intermediaries for all communication.

I’ll try to take a look at the data passed by the mobile apps later, but I assume that will be encrypted because in my experience HTTPS is now required for API calls by Android and iOS.