Communication with the Kinetid device

When the device is turned on it checks if it is registered in a home. If not – it becomes visible over Bluetooth for our mobile app. I will write more about tech details for the Bluetooth communication in other posts.

It tries to connect to the backend once put in the electrical socket. The devices can be passive and active. More about it here – www.kinetid.com and in my previous post about the project.

In the passive devices there is no ESP module (for communication over WiFi). The goal is to keep the price low. In the devices we have added PLC module. It is used by the passive devices to send signals to the active ones over the power line. What that means is that in a home you need to have at least one active device. It uses the WiFi to talk to the backend..

Each device has an unique identifier which we use to recognise it.

How we talk to the backend? We’ve programmed the device to report current consumption each minute. There is an electric meter in every device. What’s more the backend sends commands to switch on and off the electrical devices put in the device’s socket.

In order to make that happen we use Web Socket. Of course there were a lot of issues while we were programming the ESP module. And this post is about how we solved them.

The WebSocket, uses the HTTP protocol for the initial handshake. This is what the Chrome inspectors says while a WebSocket clients tries to connect.

Our backend is waiting for HTTP request, because it is a web server. The web site is there as well as the API for the mobile apps (REST over HTTP with JSON).

In order to open the TCP connection firstly we need the Sec-WebSocket-Key string. With it together with the string with a special GUID

the server is calculating the SHA-1 hash. In response the web server sends back the calculated hash. From now on the socket stays open and is being used for two direction communication.

We’ve got the backend but we have to write the code that behaves as a client. It will be installed in the ESP module and we will use it for communicating with the server.

We’ve prepared a simple WebSocket client, that is executed in the browser. It will help us while we are implementing all the spec of the WebSocket.

This, of course, is not enough. We had to create a simple TCP server to be sure that we properly implement the RFC, describing the protocol. What’s more, when the handshake is complete the protocol is switched – it wasn’t only the message sent over TCP but frames that wrap your message! Here it is:

We’ve started a simple Java ServerSocket. We will use it to simulate the web server so that we would be able to track every packet the browser client is sending.

So what’s going on here? After the client connects we start we start reading what it is sending. Because the first commands are HTTP protocol and lets say that 10K bytes would be enough for the message, we can be sure that the whole message would arrive with the first read. That is why we set the flag http to false because the next read will be with WebSocket frames.

The browser sends the request from the figure from above. Our server should respond properly. The response is in the handshakeResponse var.

We append the SHA-1 hash, which we calculated from the string the browser sent at the beginning together with the special string GUID..

We send back a response to the browser and if it is ok, the socket is open. Then in JavaScript the onConnect function on line 24 from the client above is called.

After connecting the client is sending the command hello. The protocol is proprietary but still sent over the frames.

What are these frames?

As you can see from the figure from above the higher lever protocol should be wrapped in another protocol, which is sent over the socket.

In subsuquent reads (after we set the flag http to false) our Java server first has to shows us what bytes are coming and the to try to parse them. Here are the bytes coming from Chrome. The string is and the bytes are:

The row will continue with zeros till the 10kth byte.

What do these bytes mean? Lets see how the frame looks like.

The first byte in the response is 0x81. In bits it is 1000 0001. According to the figure from above and the spec, that means that the message is not a part from another message (the first bit) and it is a text message (the last bit).

The second byte says how long the message is and if it is masked with the masing-key. According to the spec and the second byte, which is 0хAB or 1010 1011 we know that we have XOR encoding of the data because of the first bit (the left one). Than we have 010 1011, which is 43 symbols. Well, in fact the length of

is 43 symbols exactly.

In seven bits we can put not bigger number than 127 and of course there could be longer frames. That is why the spec says that if the number is 126, then we use the next two bytes for length. If it is 127, we use the next 4 bytes for length.

Our message is less than 127 so we continue with the parsing.

The next 4 bytes are the mask. It is used to XOR the message till the end.

This is thw whole method we used for parsing the message. At the end we have a ready parsed string.

So we already know how to create the message, what bytes are necessary, etc. Thus we can code the algorithm for the ESP. With the help of the simple Java server we had the change to fully test how messages are created.

And this is the whole server:

Java developers work closely with their embedded colleagues. This is how we do it in Infinno. We share knowledge so that the projects would be successfully completed.