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.

OK, I’ve probably gone too far now…

It’s a mix of devices providing the data…

• For the inside/outside/fridge temperatures and humidities I’m using 433MHz “Acurite” brand probes.  They’re received using a Raspberry Pi with a USB SDR and RTL_433 package.  I’m using a Python script to parse the JSON output from RTL_433 and then write that to a PHP script on my web server which stores the data in a MySQL database.  The Acurite’s transmit every 16s, I only write data if the change is greater than 0.5 from the last value.
• For the “Storage” info, it’s a 3G cellular connected Particle Electron with an AM2302 and a 4400mAh battery set in my tin-can storage unit where I store all my tools and stuff that doesn’t fit or belong in the apartment–This is a new storage unit, my old one was indoors and somewhat climate controlled.  I’m a bit worried about how some of my stuff will do in this one which is a drive-up and seems to get very hot and very humid.  The Electron will measure and transmit every hour, to preserve the battery it goes into deep sleep between readings.
• For the “Soil” info, it’s a WiFi connected Particle Photon using an SH-10 stuffed into the spider plant’s pot and a YL-69 which measures resistance between two copper traces.  I take readings every 10 minutes and transmit regardless of changes.  This device is powered by an 18Ah 12V SLA battery so I do sleep the Photon between readings, but the SLA is kept float charged by mains.

I have a couple of fans around the apartment to keep us cool.  Being the lazy type I found that using their manual switch is terrible; I really needed to be able to turn them on or off without getting out of bed or getting off the couch.

To add on/off control to them I decided to buy a couple of TP-Link WiFi-controlled plugs at Amazon.  These aren’t bad, but the only way to control them is with an app that TP-Link produces–it’s cumbersome to pick up your phone, unlock, swipe to find the app, then touch the fan for the room you’re in, especially in the middle of the night.

What I needed was a really simple controller.  Just a single button.  If the fan is on, pushing the button turns it off.  If the fan is off, pushing the button turns it on.

After some quick research it became clear that local network control of these WiFi plugs is really trivial–you make a TCP socket connection to their IP at port 9999 and then send a set of XOR’d JSON commands.  If you poke around online you’ll find the details easily enough.

I have some Particle Photon’s (WiFi enabled Arduino’s), so I wrote up a quick sketch that works fairly well, but it ends up being a switch hung off of hook-up wire, a breadboard, and a 5V power supply–the control may be simple, but the rest is bulky and delicate.  It’s also not cheap, the Photon’s alone are $20.

Then Amazon Prime Day happened and they put their Dash buttons up for 99¢ … that’s the perfect controller for this project! — It’s compact, easy to use (just one button), battery powered, and now it’s under $1 each.

Amazon only allowed buying of one of each brand, so I picked eight random products and ordered some Dash buttons.  At under $1 each Amazon is certainly losing money sending me these, but I figured I spend so much there anyway they owe me one (or eight).

There are plenty of posts on the Internet about hardware teardowns of Dash buttons and all the potential from the hardware packed into these guys, but most people have settled on a very simple and practical way of using these in “off label” ways — The gist of it is that each time the Dash button gets pressed the Dash will connect to your WiFi network and send an ARP broadcast to make sure it’s OK to keep using the IP that it has.  That ARP is associated to a mostly-unique MAC address which you can then sniff out using another computer on the network.  Using this technique you can determine when a Dash button is pressed without having to make any changes to the Dash button hardware or software.

The key here of course is that you must get your Dash button on your WiFi network without completing the setup to Amazon–otherwise you’ll be ordering stuff each time the button is pushed!  Luckily it’s surprisingly easy to do this, you pretty much follow all the usual instructions for setup, but then near the final step you simply don’t select a product to associate to the button, instead you quit the app/setup.  This leaves your Dash setup to get on your network and make its request to Amazon, but Amazon will reject it because this Dash is not associated to an order or product.

There are a variety of ways to accomplish the sniffing, some people online are using NodeJS, but I’m more comfortable with Python.  Python also makes quick work of the TP-Link half of this project.

The script below is a quick and lazy cobbling of some Dash button sniffer logic and TP-Link HS-105 controlling logic.  In summary, it sits and listens for an ARP broadcast from the hard-coded MAC addresses, once one is detected it polls the current state of the appropriate TP-Link plug and then sets that plug’s relay to the opposite state.

You can modify the script to attach any number of Dash button MAC addresses to any number of TP-Link plugs–even controlling multiple plugs with a single Dash button press.  In the script I have hardcoded everything for simplicity, but you could get fancy about the associations if you wanted.

First note I’ll make is that the Dash buttons will sometimes broadcast an extra ARP beacon or two, to counter this I added in a short 5-sec back-off time to prevent toggling an outlet more than one time in those cases.

I should also note that at this stage of development the error handling is virtually non-existent, in fact it’ll quit if it can’t reach a plug on the network.

That said, it’s good enough for now!

from scapy.all import *
import json
import socket
import time

onCmd = '{"system":{"set_relay_state":{"state":1}}}'
offCmd = '{"system":{"set_relay_state":{"state":0}}}'
infoCmd = '{"system":{"get_sysinfo":{}}}'
port = 9999
brMAC = '68:37:e9:e6:33:f0' # Airheads
lrMAC = 'ac:63:be:b8:31:d4' # Tide
brIP = '10.0.1.44'
lrIP = '10.0.1.39'
brLC = 0
lrLC = 0

def arp_display(pkt):
 global lrLC, brLC
 if pkt[ARP].op == 1: #who-has (request)
   if pkt[ARP].hwsrc == lrMAC:
     print "Pushed Tide - Living Room"
     if (time.time() - lrLC > 5):
       #print "Executing..."
       lrLC = time.time()
       currentState(lrIP)
      else:
        print "Duplicate, skipping..."
     elif pkt[ARP].hwsrc == brMAC:
       print "Pushed Airheads - Bedroom"
       if (time.time() - brLC > 5):
         #print "Executing..."
         brLC = time.time()
         currentState(brIP)
       else:
         print "Duplicate, skipping..."
     #else:
     # print "ARP Probe from unknown device: " + pkt[ARP].hwsrc

def encrypt(string):
 key = 171
 result = "\0\0\0\0"
 for i in string: 
   a = key ^ ord(i)
   key = a
   result += chr(a)
 return result

def decrypt(string):
 key = 171 
 result = ""
 for i in string: 
   a = key ^ ord(i)
   key = ord(i) 
   result += chr(a)
 return result

def currentState(string):
 try:
   sock_tcp = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
   sock_tcp.connect((string, port))
   eString = encrypt(infoCmd)
   sock_tcp.send(eString)
   data = sock_tcp.recv(2048)
   sock_tcp.close()
   rawJson = decrypt(data[4:])
   #print rawJson
   decodedJson = json.loads(rawJson)
   currentState = decodedJson["system"]["get_sysinfo"]["relay_state"]
   if (currentState == 1):
     print "Currently ON, turning OFF"
     turnOff(string)
   else:
     print "Currently OFF, turning ON"
     turnOn(string)
 except socket.error:
   quit("Cound not connect to host")

def turnOff(string):
 try:
   sock_tcp = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
   sock_tcp.connect((string, port))
   eString = encrypt('{"system":{"set_relay_state":{"state":0}}}')
   sock_tcp.send(eString)
   data = sock_tcp.recv(2048)
   sock_tcp.close() 
 except socket.error:
   quit("Cound not connect to host")

def turnOn(string):
 try:
   sock_tcp = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
   sock_tcp.connect((string, port))
   eString = encrypt('{"system":{"set_relay_state":{"state":1}}}')
   sock_tcp.send(eString)
   data = sock_tcp.recv(2048)
   sock_tcp.close()
 except socket.error:
   quit("Cound not connect to host")

print sniff(prn=arp_display, filter="arp", store=0)