Yes, it is on github. The complete story with links is here: https://community.openhab.org/t/devireg-smart-thermostat-binding
The communication is not done directly unfortunately and it perhaps can’t be done, unless you figure out some manufacturing mode settings in device’s firmware (should they be there), which is hard. Once set up, the device only wants to talk to a proprietary cloud, owned by a company called Trifork. Your smartphone also connects to this cloud and “dials” your device, like on old good phone exchange. Devices are identified using a hexadecimal string known as “peer ID”.
The cloud communication is encrypted. DeviSmart version uses custom protocol, inspired by CurveCP, but using custom homebrew packet format. LinkCC uses standard SSL. On top of that SSL the cloud speaks protobuf; the device itself can speak anything. A typical workflow is:
- A peer (let’s say your smartphone) connects to the cloud (they call it “grid”).
- Your smartphone knows peer ID of your LinkCC. It asks the cloud to connect to the device.
- The cloud responds with IP address, port and some forwarding ID. Your smartphone opens a second connection to the given address and port (it’s the cloud server again) and sends “forward me to this ID” packet (unencrypted). The server is expected to respond with “OK”, and from that point on you are talking directly to your device. Only now you need to do the SSL handshake, the procedure is the same as with cloud, but the encryption happens betwen two peers now, the grid is not listening, it is just forwarding packets.
So how does your smartphone know peer ID of the device? For this purpose another procedure exists, called pairing. Pairing happens between two peers on the grid, using a one-time password. One peer issues the OTP, another peer uses it for connection. The procedure is similar to a regular connection, but there’s no data exchange; instead you need to perform a challenge-response handshake, and after this you are able to establish data connection, because you’ve learned peer’s ID during pairing process.
A very first pairing is done in so called bootstrap mode. In this case the device acts as an access point, and it will accept any connection on its private network. mdglib study shows that the traffic is even unencrypted, plain socket. But as soon as you configure wi-fi parameters it stops listening on local port and only wants to connect to the grid, so this mode is unlikely usable. I haven’t done much research, however, because i don’t want to cold-reset my working setup.
“Share house” function in the smartphone app pairs with another smartphone using an OTP (yes, that very pairing), and after this sending smartphone sends all the data it knows (including peer IDs) to the receiver. Another thing the sender does is adding receiver’s peer ID to device’s whitelist. The device only talks to whitelisted peers when configured.
For more details you may read documentation for the original Trifork’s proprietary library; it’s available here: GitHub - trifork/secure-device-grid: Secure device-to-device communication solution for IOT Note that the library will not work with LinkCC; it is DeviSmart version, but all the concepts are the same. You may also study my code, you’ll see what protobuf communication and workflow looks like.However remember that for LinkCC some of this stuff can be slightly different (i’ve looked at LinkCC app’s LUA code and it looks like so). My test app will not be useful for you because it talks only to DeviSmart (but you can run it and see how it connects to the grid).
Grid servers for LinkCC is the same as for DeviSmart, so servers speak both custom tunnel and standard SSL, but your device knows only one of these, so you won’t be able to connect to your peer. And for DeviSmart keys are 32-byte long (and your public key is your peer ID), while from Chris i know that LinkCC uses 20-byte peer IDs.