I just stumbled over this article, which explains what is the situation with the Danfoss Living Connect
Living Connect review
Man i got it working! it seems that i have the Z-wave version after all ! it was about the sitemap configuration and thanks to @chris4789 who shared his config i got the sitemap up and working.
So the conclusion is that Danfoss Living Connect Z produced this year IT IS Z-wave and work with any Z-wave controller.
Thanks for help all!
1 Like
Hello everyone,
I’ve bought a Danfoss Link CC with few thermostat living connect 014G0002 and a boiler relay - it’s up and running for few days. I know that it’s not an open z-wave but I’m looking for a way to communicate with the thermostats / CC to get the current temperature per room and see how it’s changing over the day. I’ve noticed that you’ve made some progress on that topic - @ChristianHC Could I get the access to your repository? My bitbucket account: ako009
Hi! Chris is not working on the project at the moment due to family circumstances.
Perhaps we together can finish the job, but this assumes you are a Java or C developer.
I have successfully implemented an opensource replacement for Danfoss mdglib to use with DeviSmart floor thermostats. But unfortunately LinkCC uses older, different version of the protocol, so they are generally speaking not compatible. But the knowledge i’ve gained during implementation of DeviSmart protocol can seriously help. Protocols share the same ideology.
Also i can email you an archive of Chris’ repo, i have an access. He might answer eventually but it takes him about of 1.5 weeks to do so.
So if you’re okay with getting your hands durty, tell me and let’s do the job. I can tell you everything i know, gonna be a bit long lecture.
@Krystian I need your email to add you to the Repo, you can send me a PM with it.
@Sonic Has done an amazing job of recreating the needed coded so that it isnt dependent on any code from Trifork. As he said, the “only” thing needed is to switch out the Sodium SSL library used in Devi with the EC Curve SSL used in Danfoss Link. All the sourcecode for this exists as LUA code from the original Danfoss Link android app. So somebody with Lua and C knowledge should be able to do it. However unfortunately i dont have the time to do it, nor am i experienced in C.
Yes, and this switch means rewrite, because the encrypted tunnel is 80% of the code.
Actually the whole thing for LinkCC can be easily written in pure Java, thanks to standard SSL. I decided to write my library in C not only because i am more comfortable with C, but also because the Sodium crypto engine is written in C, so there would be native code involved anyways.
Hi, currently I am not able to sent PMs, yet - I’ve read above that it requires some time - I’m still too new 
Once I will be able to PM I will sent you my email address. Thanks.
@Sonic I have some experience in C/C++ and Java development and maybe I could help. However I’m not able to spent more then 2-3 hours per week on that.
Does your library communicates directly with thermostats via proprietary z-wave protocol or through Danfoss servers? Is it the opensdg project on github?
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: https://github.com/trifork/secure-device-grid 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.
2 Likes
Wow, outstanding work, give me some time to go through this and your and Chris code. I finally got the basic badge and able to send PMs. Thanks.
Hi Krystian & @Sonic
I see that the last reply in this thread is approaching 1-year anniversary - did you ever manage to get OpenHAB to work with LinkCC? I was hoping to include this feature (without upgrading to Ally) into my floorplan 
Best regards
Hello there!
As far as i understand, @Krystian lost interest due to lack of time, so nobody works on implementation of legacy LinkCC protocol.
As to newer SDG protocol, we have full support for DeviReg Smart and some limited support for Icon. I am the only one working on the project, so it’s very hard for me to cover everything. Additionally there seems to be some memory leakage, which doesn’t reproduce for me, i cannot find it. 
I tried to lurk around other HA forums, like Majordomo and HomeAssistant, but nobody expressed an intention to join the project. So i am alone.
Damn, sad to hear …for me and you
If I only knew how to assist - my realm is more front-end/.Net, so a bit out of my comfort zone here… but hey, maybe I can assist when I get deeper knowledge of OH.
Hi Sonic, Do you have access to the codebase with the finings so far , if so could you share it please ? I might have some time to look in to it
Of course i do, it’s my codebase
OpenSDG library: GitHub - Sonic-Amiga/opensdg: Free and open SecureDeviceGrid protocol client side implementation
Danfoss binding: GitHub - Sonic-Amiga/org.openhab.binding.devireg: DeviReg binding for OpenHAB
Here’s also a link to old Christian’s repository, containing decompiled LinkCC: https://bitbucket.org/ChristianHC/danfoss-link/src/master/ I’m not sure if you have an access though, it isn’t public. But i also have an archive and can share it.
To summarize the differences between LinkCC and mdglib/OpenSDG :
- LinkCC uses standard SSL/TLS; SDG uses custom derivative of CurveCP protocol
- Challenge-response procedure, used to authorize a peer, can be different.
That’s all. You can find out more details about inner workings of the whole thing in DeviSmart binding discussion thread; and also in original mdglib documentation.
Hi Søren,
But am I right, you are not able to decode the information? You state the message said what the the temperature was, but did you get that from the z-wave packets or from your controllers?
best
Morten
Hi Morten.
I get the temperature by decoding what the thermostats are reporting to the Danfoss controller. I have a z-wave sniffer running.
@Sonic, do you have something which is actually working?
Sry, I havn’t been visiting this thread for some years :). But I am still very interested in getting this to work.
@scaarup Hello! For LivingConnect - no, because it uses older version of the protocol. For newer products: DeviReg Smart and Icon - yes, long time ago, please see this thread: DEVIReg Smart thermostat binding - #200 by siest4
If you are a Java coder, i can explain the differences between protocols. They are not big. I have neither LC hardware nor time to support it myself, sorry.
I have actually given all the links several messages above.
Okay, but will the work you have accomplished, enable me to at least communicate with my controller or the endpoint at Trifork? Because that would still be a major improvement.