Leaving the office behind, we decided to go the German monastery. The sun energy and the fresh air gave us power for the next few weeks. Some of the colleagues came with their bikes. Beer is never enough but still we only needed some more kebapche and sausage from the nearby village.

Advice: don’t wait for the last moment to buy the beer.


We develop native mobile apps for the most popular platforms.

Partners like Karoll, BACB and Samsung trust our knowledge and experience in development for iPhone and Android.



The backend solutions that serve the mobile and web apps are written in Java with Spring.


For the databases we use MySQL and that helps us scale without interruptions, securely and cheap. We deploy in Tomcat and in front of it we put Apache web server.



We host our cloud systems in Amazon Web Services, Microsoft Azure and  Google Cloud Platform and adopt their best practices to provide reliable solutions.

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 – 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.




Control your air conditioner from your mobile

Our partner Kineted is launching a service that makes your home smart. You’ll be able to set an energy plan which is a bunch of rules that control your electrical devices. More  – here.

We’ve helped them with the software and hardware dev.

Our hardware team has created a cheap device, which you plug in the electrical socket. Then you plug for example your air conditioner in the device’s socket.

From now on our device tracks how much energy has been consumed from the air conditioner and sends the data to the cloud.

In order to guarantee a low price we don’t equip every device with internet connectivity. In fact only a single device needs connectivity (WiFi). We call it active device. The other devices (passive) send their signals over the power line at home. Then the signals are multiplexed and sent to the cloud by the active device.



The whole device is developed by our team. We use WebSocket for communication, which the active device provides by its ESP module. The PLC module takes care of the communication over the power line. It has also a meter.


All the gathered information is sent to the cloud. Every minute we know exactly how much energy was consumed. Each user can track in real time the energy of any electrical device at their home.


Soon we are launching the apps. They will give the user option to track the consumption at any time. What’s more, they will be able to turn on and off their electrical devices.

When the user buys a device and plugs it in the socket, for the initial setup we use Bluetooth low energy. It is a part of the ESP.

When turned on for the first time they start advertising their id (iBeacon). Our device is looking for it and when found, it asks the user to enter their WiFi network and pass. This step is necessary because we need a way to tell the active device how to connect to the cloud. When done, the BLE is stopped.

 We developed an Android app, too, because in Bulgaria most of the people prefer that operating system.

Soon we will know how exactly the end user price of the device will be. Thanks to the experience of our team we will provide affordable service that makes your home smart.


Augmented reality with Samsung

We created the first Bulgarian augmented reality exercises together with Junior Achievement and Samsung.  Students from 1st to 12th grade took part in real time testing –  they point their mobile phone cameras to a certain pages of their student books and the magic happens.

Behind the camera they can see  flying 3D animated objects. Every single one can be moved and placed  in the  desired direction.

They can learn about the structure of the cell or take a closer look to the human body. More about the exercises –here.

We also organised a  mentoring programme with  the students.

Our team  taught them how to make presentations and how entrepreneurs take problems from the real world and  try to transform them into a  successful business. They had the chance to see the developing process of  the exercises, too.

We developed the app with Unity and Vuforia.