itsnotlupus
commented
7 years ago I have no inside or formal knowledge about the device, but yes, state.ts encapsulates whatever I could figure out(/guess) about the websocket connection the devices establish with server2.vesync.com
The protocol is indeed in plain-text over a websocket, and consists of JSON payloads being sent back and forth. I think I sniffed it by running tcpdump on my main router, but ARP poisoning it would have probably worked too.
The commands that the device can send to the server are in handleDeviceMessage(), the commands that can be sent to the device are in handleCloudMessage(), and for each little case statement, I've tried to associate an entry in messageSchemas that defines the expected shape of each payload, very roughly.
Most of the commands were observed over the wire. A few are only listed in comments, because they were present as strings in the firmware, but I couldn't get them to appear in a network payload.
You're spot on about the security aspect, down to the ability to change the firmware, triggered over plain-text, with an unencrypted HTTP firmware download. That's something the proxy disables altogether, because even I have my limits. Everything else is unencrypted too, but it's what allows a dumb MitM proxy like this one to work, so I guess I can't complain too much.
I haven't really used the little plugs as a way to measure power consumption (it's more of an "ok google, turn on the living room lights" kind of thing for me), so I haven't strongly focused on the power measurements and alerts bits of the protocol. But, from memory and staring at the source right now:
- Roughly every 180 seconds after booting up, the device will emit a /report command that includes the average power consumption over the time period since the previous /report was emitted, or since starting up if first report.
- At any point, you can ask the device for its "runtime info" with /getRuntime, and get a /runtimeInfo packet back which includes whether the plug is powered, as well as an instant measure of power and voltage. Those 2 numbers are meant to be a float value, but are each sent as integers left shifted by 14 bits for whatever reason. And you get two values for each, usually both fairly close to one another. There's probably a reason for this, but I couldn't figure it out. I've ended up averaging them. As an example, server.ts has a getPower() method that converts those things to plausible float values.
- I believe it's also possible to setup alerts when power consumption dips below or above some threshold, but it doesn't look like I got around to figuring out how exactly (but it's likely to be done with /setTrigger and /delTrigger commands, resulting in the device emitting /trigger messages when conditions are met.) (From the behavior of the android app controlling those things, and its tendency to trigger spurious over-wattage notifications for a very boring LED light bulb, I suspect this alert mechanism may not be the most reliable way to track things, but ymmv.)
HankB
dirwin517
Do you have any information on the protocol? It looks like state.[js|ts] need to understand the content of the messages. (I have no javascript experience so I am unable to determine this directly by examining the code but it appears that these devices use a straightforward text protocol.)
I'd also like to confirm that these devices are not using encrypted (e.g. TLS, HTTPS etc.) communications. I see no mention of this or certificates in the code so I assume it is straight HTTP. I also see what looks like an HTTP firmware update URL which would reinforce this. (HTTP for OTA updates reminds me that the 'S' in 'IOT' stands for security. :-/ )
My desire is to use one of these devices to monitor power used by a freezer from a PC application so I can tell when the freezer door is open, the freezer is running continuously and contents are starting to thaw. :( Any help you can point me to regarding the protocol would be very helpful.
Thanks!