diff --git a/protocol.md b/protocol.md
index 3d52139..87d769a 100644
--- a/protocol.md
+++ b/protocol.md
@@ -1,20 +1,28 @@
-There are two protocols involved here. There are a series of HTTPS requests
+# Ecovacs Protocol
+
+There are two protocols involved in the communication between the client and Ecovacs systems. There are a series of HTTPS requests
used to log in and find devices. Once logged in, you get a token that is
used to connect to an XMPP server, which mediates communication with the
vacuum. That's right, your robot housecleaner, like an errant teen, spends
all its free time hanging out in an internet chat room.
-This is all taken from MITMing the Android app. The protocol is quirky
-enough that I wouldn't be shocked if the iPhone app does it differently.
+This is all taken from MITMing the Android app. The iOS app appears to
+follow the same protocol conventions.
+
## Location
It appears that Ecovacs have broken up their API servers by location. Some
are designated by country, others by continent. All appear to use the
two-letter ISO codes, but at this time it doesn't look like all codes
-map to valid servers. If you're in, say, Australia and are trying to
-get this to work, I'd love a packet capture of DNS requests to see what
-the app does there.
+map to valid servers.
+
+The HTTPS and XMPP servers do not appear to be following the same convention.
+For example, a Canadian user must authenticate on country-specific HTTPS
+server, but XMPP commands work both on the worldwide server
+msg-ww.ecouser.net) and the North America server (msg-na.ecouser.net)
+
+
## HTTPS
@@ -53,76 +61,121 @@ vacuum via XMPP
## XMPP
-
-The Android app establishes a connection to an XMPP server and logs in using
-a secret that comes from the earlier HTTPS calls. It then sends XMPP IQ commands.
-It describes
-them as queries, but they all contain "ctl" elements that appear to be commands. Here are a couple of full
-examples with the private information removed:
+The app establishes a connection to an XMPP server and logs in using
+a secret that comes from the earlier HTTPS calls. It then sends XMPP IQ
+commands. It describes them as queries, but they all contain "ctl"
+elements that appear to be commands.
-A clean command:
-```
-
+
+### Cleaning
+
+**Command**
+- ``
+
+**State**
+- **Request** ``
+- **Response** ``
+ - type `auto` automatic cleaning program
+ - type `border` edge cleaning program
+ - type `singleroom` cleaning a single room
+ - type `stop` bot at full stop
+ - speed `standard` regular fan speed (suction)
+ - speed `strong` high fan speed (suction)
+
+
+### Charging
+
+**Command**
+- ``
+ - `go` order bot to return to charger
+
+- *Request* ``
+- *Response* ``
+ - `Idle` not trying to charge
+ - `Going` trying to return to charger
+ - `SlotCharging` currently charging in dock
+ - `WireCharging` currently charging by cable
+
+*Note: It appears the bot can be in an active CleanState (i.e. auto) as well as in an active ChargeState (i.e. SlotCharging). The assumption is that in this case, the cleaning task will resume after the bot is sufficiently charged. More testing is needed.*
+
+
+### Battery State
+
+Battery charge level. 080 = 80% charged.
+
+- *Request* ``
+- *Response* ``
+
+
+### Component lifespan
+
+The remaining lifespan of components. Based on an internal counters
+that can be reset with command ResetLifeSpan (untested).
+
+It's presumed that the timers need to be reset manually.
+
+- *Request* ``
+- *Response* ``
+ - Brush
+ - SideBrush
+ - DustCaseHeap
+
+
+### Manually moving around
+
+To stop the current action, issue the stop action.
+
+**Command**
+- ``
+- ``
+- ``
+- ``
+- ``
+
+
+
+### Errors
+
+The bot broadcasts error codes for a number of cases.
+
+``
+
+The latest error can be requested like so:
+
+- **Request** ``
+- **Response** ``
+
+However in some cases the robot sends to code 100 shortly
+after an error has occurred, meaning that we cannot trust
+the GetError request to contain the last error.
+For example, if the robot gets stuck it broadcasts 102
+HostHang, thenproceeds to stop and broadcasts 100 NoError.
+
+
+**Known error codes**
+- 100 NoError (back to normal)
+- 101 BatteryLow
+- 102 HostHang (bot is stuck)
+- 103 WheelAbnormal
+- 104 DownSensorAbnormal
+
+
+
+### Untested commands
```
+
+
-A charge command:
-```
-
-```
-
-Focusing on the core ctl elements, this is a sampling of commands seen on the wire after punching all the app buttons:
-
-```
+
+
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-```
-
-It appears that it adds an extra id when it cares to receive a specific response. This is a little odd in that
-the iq blocks already contain ids, but perhaps one is more a server id and the other is used by the robot itself.
-
-Here are some assorted responses from that session:
-```
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
```
-I don't totally get the relationship between the duplicate-ish items here, like the various clean reports,
-or the charge type differences, but I'll try to come back after rummaging through the logs further.
+It appears that it adds an extra id when it cares to receive a specific response.
+This is a little odd in that the iq blocks already contain ids, but perhaps one
+is more a server id and the other is used by the robot itself.