A lot of places I seen the Danfoss living connect lc-13 recommended. But as these are not being manufactured anymore I went for the new ones just branded “Danfoss living connect”. They are recognised by openhab2 and being detected as the lc-13. But they do not work. The reason is that Danfoss removed the Z-wave capability in the sw 3.02. And are now using some proprietary protocol. Is there way we could get this new termostat working? Could it maybe be possible to reverse engineer the protocol and at that to the z-wave binding? Or maybe it could be possible to load a custom firmware onto the device?
As this is a popular thermostat I think it could be good to find a way to get it to work
1 Like
The problem is also described in this thread which link to pdf where it on page 5 is showed that from sw 3.02 Z-wave is not supportet.
Interesting - I missed the previous thread (on holiday in India 
).
It might take a little work, but it should be possible to work out what’s happening. First I would search the web to see if someone else has already cracked this, otherwise, you (or someone) will need to reverse engineer the command class. This shouldn’t be too hard to at least get the basics, but I would suggest to search the web first.
To be clear, this is still Z-Wave - it’s just a proprietary command class (Fibaro also do this a lot, but they also support the standard classes as well).
I have searched the web. But I have not been able to find anything jet.
When you say it is Z-wave I believe that it is just the commands that is not standard. So to reverse engineer the protocol I should probably get hold of a Danfos link controller and the run some kind of z-wave sniffer to see what’s going on. (at the moment I only have the thermostat)
To correct what i said above. Danfoss is at the moment providing 2 different thermostat. One named Danfoss living connect which is the one with the probationary protocol and one with named connect Z which is has z-wave protocol. The z-wave cost twice as much as the one with the probationary protocol
I asked Danfoss for the specifications of the protocol. But they did not want to give it to me. Here is there answer which does not really help:
Dear Sebastian,
I am replying to your request for information on “Spørg en Danfoss Produktekspert”.
As you have mentioned Danfoss Link communication technology is based on Z-wave however uses a proprietary implementation.
Unfortunately we do not share this proprietary information with third parties.
The reason why open Z-wave thermostats (014G0013) are more expensive is that they are able to operate with a wider variety of hardwares, whereas 014G0002 only works with Danfoss Link system.
Therefore I recommend implementing Danfoss thermostats on the open Z-wave platform as we will not support customers that use some sort of reverse engineered solution but rather recommend buying approved Danfoss hardware.
If Danfoss Z-wave solutions are not affordable to the end-user, instead we suggest to get new Danfoss ECO (http://smartheating.danfoss.com/danfoss-eco/) which has a Bluetooth implementation.
It can also be used as part of a Bluetooth based smart home solution and integrated into BLE gateways.
If you have more questions, please do not hesitate to contact us, our service team is ready to help.
Best regards
Justinas Amelinas
Key Account Manager
Danfoss A/S
Residential Heating
Hårupvænget 11, 8600 Silkeborg, Denmark
Mob.: +45 23 60 28 77
E-mail: jamelinas@danfoss.com
www.danfoss.com
I was wondering if someone reverse-engineered the web protocol which is used for communications with Danfoss app on a smartphone… it should allow a full control of your setup without getting too deep into “living connect” specifics.
I like the idea of getting the info via the web protocol 
I have about 20 Danfoss Living Connect thermostats and the WiFi controller, but I have absolutely no idea on how to grab this communication, but I would love to help
I was briefly looking into this approach. When I browse the web for some instructions on how to setup the Danfoss Link, it seems that the Mobile device need to be paired to the Danfoss Link CC, to be able to communicate with the API. From a security perspective I completely agree, that there should be some protection / encryption. But I won’t spent that much money on a closed ecosystem. Hopefully Danfoss will open the Link API in a near future.
I also looked into the pure Z-Wave edition of the Thermostat, but then I have to do the programming my self. And honestly I think Danfoss has a lot more expirience in heat control than I have…
Of course, you need to have some kind of authentication process to access your home smart systems. Finding out how the pairing/authentication process works is one of the challenges of reverse-engineering the protocol.
I do not have Danfoss hardware yet, so I tried to sniff the communication between iPhone app and Danfoss servers when I specify the random pairing code. I didn’t see any HTTP communication from the app related to the pairing process besides logging. It seems that either the application tries to connect to the central controller directly via the local network, or the pairing code has some kind of checksum.
Not so obvious for everybody making IOT devices though, .
Disclaimer: I’m a newbee in z-wave/ZigBee protocols but feel pretty confident about internet security ;).
If you’re working on a z-wave/ZigBee protocol level, then having the device within your network is enough to communicate with it. But once you’re talking to it via the internet - authentication is essential, otherwise, anyone could see your data.
I wonder if anyone is willing to share a connection to their CC (so that I could connect Danfoss iOS app on my iPhone to the CC unit) so that I could try to capture the communication. A successful connection to CC unit will allow me to capture the process of pairing and retrieving settings information (and hopefully to understand it). Currently, the only communication I saw were logging requests to https://danfoss.tpa.io/api/ - this is most likely the service that works as a middle layer between Danfoss CC and mobile app.
I just got the Danfoss living conect thermostat working using Synology NAS and Aeo zwave dongle and the zwave binding by Chris Jackson working - little bit tricky for a newbie like me, but, got it working after some advice…
How did you get it working? I can connect it with my openHAB2 and it is being recognized immediately. I cannot set the temperature though.
Thanx for any advise.
The main problem I had was that the diescovery phase wasn’t fully completed. I was able to verify this by noticing that the node.xml files weren’t created under the zwave directory (which they should be when successfully discovered). To get it working I did the following:
-
Triggered the discovery mode again and during this process I pressed the discovery button on the danfoss device MULTIPLE times. This resulted in successfull discovery and the creation of the node.xml files.
-
When fully discovered, I navigated to: Configuration=>things - now I was able to see the channels.
-
I checked the channels and created items for each channel - this made them appear under: Control - and from here you simply press the temprature number which makes the increase/decrease button appear and you can set your temperature.
hope this helps
BR
Good to find others struggling with the same challenge as me :).
I have spent a lot of time on this. MitM attacks on the Danfoss controller and Danfoss App. I have tried to decompile the Android Danfoss App. I have downloaded the controller firmware and tried to take it apart. The controller communicates with an API hosted by Trifork, the same goes for the Danfoss App. The api is served on port 443 and uses ssl. However I am unable to even connect with it with openssl. Some strange ec curve issue. When I took the Android app apart, I found a file called brainpoolP320r1-curve.pem which contains EC PARAMETERS - probably needed to connect.
I have tried to get the app and controller to communicate with my fake API which also is served with a fake Trifork CA. However nginx is unable to use the brainpool curves, even though openssl supports them. Apache can serve using some brainpool-curves, but not the P320r1 - in my first try. Right now I have given up on the API.
So trying z-wave. I bought this z-wave sniffer https://www.suphammer.net/product/suphacap and am now able to see the traffic to/from my thermostats and the controller. I have reversed part of the protocol and can now see temperature per thermostat and if it’s heating or not.
I am now not certain if I really want to take over control of my thermostats, as I am sure Danfoss does a much better job at this than I can. So maybe monitoring the state is enough?
z-wave example - my thermostat 2 says to the controller, that it is at 19,97 degrees:
0x00021028120C054720202021030020102011030F031703280318032F0330057F0800049D013700004901C06599DA
and my controller says to the thermostat, go to 24,22 degrees:
0x0002100A0D0D0001000409761C9A655E
Has anyone made better progress on this than me?
1 Like
Hi Søren,
It could be nice if you could share how you get this information. I am a big newbie on this, but I have in some time tried to get my B&O gateway to connect to Danfoss. B&O had an earlier version semi working with Danfoss, where they connected to this site https://linkdeviceapi.azurewebsites.net/, but I think they have partly closed that website now.
All I want of information is the actual temperature and maybe the set point. If you could assist me with your findings, it would be really nice.
Hi Søren,
I have been through the exact same process as you trying to get into the Danfoss CC protocol.
As you found out, the communication is hosted by trifork and they use a proprietary version of this library: Trifork - Secure Device Grid (I can only post 2 links as a new user, so just search github)
I managed to decompile the android app and extract the certificates. The general library (which is LUA based) for both the CC Controller and the iOS and Android apps are in files/mdg-c.zip directories. Everything needed for generating certificates and pairings are in there. The API calls themselves are in the android source code.
The communication to and from the endpoint is based on googles protobuf library and sent over https which is why you cant MITM attack it. However the only thing needed is to decipher the protobuf models and use the endpoints from the app, then you can talk to the controller either directly or through the endpoint.
I’ve managed to succesfully connect to the Trifork endpoint via the following commands:
openssl s_client -tls1 -connect mdg-danfoss.hosted.trifork.com:443 -servername mdg-danfoss.hosted.trifork.com -showcerts -cert app_cert.pem -key app_key.pem -CAfile trusted-CAs.pem -state -debug
Furthermore you can scan the endpoint with Nmap to see which ssl version they accept:
nmap --script ssl-enum-ciphers 77.66.11.92
So what is needed is to write a short program that connects via the openssl commands above and communicates via protobuf to the API endpoint. However i have never worked with protobuf and as such have not have success with it yet.
Would it be possible for you to share the decompiled code, with the API calls from the Android app?
I’d be happy to give deciphering them a shot, I just don’t have an android device right now.
Hi Christian.
Awesome work, I must say!
In stead of trying to figure out the protocol ourselves, wouldn’t it be an idea if we could get the controller to connect to our webserver and see what it actually posts? I bet we need some sort of authentication string, api-key/token anyway.