Hi Christian,
bitbucket: Tuck_
Could i get access i’m looking into creating link for google assistent to work with it 
Hi All,
@Tuck08,@morten235, @wojciii,@janushansen, @Jere, @marco80, @misncz
I haven’t had any time to look more into this, however all the code for the decompiled app is here: https://we.tl/t-L47bkmW6uC
There haven’t been any updates to the app on the google play store so it is the same code. What is needed is to get either the library or the lua code to run on other systems than android. This requires somebdy skilled in Lua or Linux, which is not me.
Also, there are rumors that Danfoss is working with TriFork in regards to an open API: You can read more here: https://github.com/trifork/secure-device-grid/issues/4
Hi everyone, meet yet another angry Danfoss product owner onboard. 
I have DeviSmart floor thermostat and also want to integrate it. I’ve read the thread and some links. My takeaways:
- The whole thing is using trifork mdg.
- mdglib published on github isn’t compatible with Danfoss products. Neither Danfoss products are compatible between themselves. But it can be used as a reference.
- It seems to be that application-level protocol is text-based.
- But it’s forbidden to use mdglib without license.
I’d like to know what exactly you are working on. Are you trying to reverse engineer mdglib in order to be able to reimplement the tunnel? You’re talking about lua. Does it mean mdglib core is written in lua? Or is this monstrocity located inside DanfossLink app itself?
P.S. I know that DL belongs to a product line different from DeviSmart.
P.S. There was a suggestion to relink mdglib from Android to Linux, i can tell this is not possible due to binary incompatibility. But there is a solution called libhybris, it can be used at least for research purposes.
Hello everyone! Is there anyone reading this?
I’ve recently made some progress. First of all, i was able to reverse engineer a protocol, running inside the tunnel. Now i want to modify mdglib demo app to talk to my DeviSmart using a library extracted from the app APK. I have a rooted Android device to run this contraption. The Android library has both JNI and native entry points, so building the testapp was an easy task.
I have also looked into the lib itself. I found no LUA engine, neither any scripts. However i found sodium library in there: https://download.libsodium.org/doc/ . This is what they are using as a crypto engine.
At the moment my app doesn’t work due to mdg_init() error. Unfortunately error codes are not documented; neither there is anything on logcat. However, i’ve noticed that the app generates a private key, so callbacks are being called. They likely return something wrong; need to inspect them versus original Java stubs.
Also now i know that Danfoss config, published in the github repo, is correct; but the published library indeed fails to connect. However, i am in doubt that there is some big difference, most likely it has to do with built-in license key.
Plan to continue fighting today.
3 Likes
Hi Pavel,
The main difference between the Danfoss and the Devi implementation is the library they use for establishing a secure tunnel. Danfoss uses a brainpool curve and Devi the libsodium library you mentionded.
When the tunnel is established, both apps coomunicate with MDG through google’s protobuf library.
The reason you cannot connect to Danfoss using the demo code from trifork is because it is using the Devi implementation.
The lua sourcecode was included in the Danfoss APK in an earlier version. I’ve sent you an invitation to my bitbucket repo which contains the Protobuf descriptors needed to “decrypt” the communication as well as the LUA sourcecode.
From likes i see somebody is reading this thread. Meanwhile i started a new one: DEVIReg Smart thermostat binding
Some recap:
- I have a demo code which talks to my thermostat and reads the data.
- I have got an insight into tunneling protocol and soon i will start working on a free and open communication library.
Current evaluation and technology demo code is available here: https://github.com/Sonic-Amiga/DEVIComm . Should also be useful for all who want to work on Living Connect.
Since it is Z-Wave, I think it should possibly be integrated into the existing Z-Wave binding.
DeviSmart is not z-wave. And to my surprise protocols are different indeed. However at a glance they are related and share the same basic flow.
It looks to me like DeviSmart version is scaled down in order to fit into limited resources of the thermostat hardware. LivingConnect is a more advanced system with many devices and a single big controller box.
In contrast, DeviSmart is just a thermostat. You can have several of them, but there is no interaction between them. You only control them via app; they have some rudimentary zoning, but it is all managed by the app in software.
So DeviSmart protocol is custom binary, with simple message structure and no heavy lifting like protobuf and proper SSL
The thread title is incorrect then.
Perhaps. Let me explain.
The thread was originally started by Living Connect owner. LivingConnect is a complete solution; it consists of some devices and a controller box. Devices connect to the box, apparently by proprietary z-wave. The box connects to the Internet and can be controlled by a smartphone app. A typical turnkey smarthome package. I would expect devices themselves to be pretty dumb, with majority of control logic being implemented by the box.
So, if we want to throw the box away and talk to devices directly, that would be z-wave. If we want to talk to the box and use it as a gateway, this is not z-wave.
This thread in fact discusses option number two.
DeviSmart is a related product in a sense that it also uses Trifork cloud and it uses similar protocol, but not the same. I guess LC uses full-featured SSL (i conclude it from this thread). DS uses a reworked version of CurveCP (http://curvecp.org), with the same crypto procedures but different packet format. I’ll publish my prototype code for that afrer i pass the initial handshake.
That is useful information omitted from the first post. It was written indicating they were just an interested (potential?) user with no knowledge of the protocol used.
My concern is that any Z-Wave related binding integrate with the official one, or at least, not interfere.
I’ve actually read the first post now. Apparently there was earlier version of Danfoss hardware, branded LC-13, which was open, and OH could talk to it using Z-Wave. But the newer product line, the LivingConnect™, works only with the supplied controller.
Apparently they decided to force-sell the complete system with the controller rather than sensor kit.
And, i guess, the thread slowly drifted away to discussion of how to work with the controller rather than individual hardware items.
At this point it stops being z-wave binding and starts being LivingConnect™ binding.
Personally i have googled out this thread somewhere in the middle by searching information on “mdglib”, the core communications library, used by Danfoss.
Hello, readers! I have made some progress with mdglib reverse engineering, my library works and successfully connects to DeviReg thermostat. I have looked at Christian’s LivingConnect sources and i see that it uses the same grid servers as DeviSmart does. So, the library should work with both products.
Developers are strongly wanted to help me in different areas.
1 Like
Interesting that grid servers apparently support also normal SSL, used by the LUA code. I guess in order to connect to a LivingConnect box we need normal SSL, because the box most likely supports only one protocol.
1 Like
hello,
i just got a danfoss thermostat living connect z lc13 and im trying to add it in my network but it seems to be impossible. i have openhabian 2.4.0-1 installed on a rpi 3 and i have different zwave devices installed around the place.
i found the thermostat in the discovery tab an added to the thing list. when i create items from channels using visual studio code every thing is going out, i cant access nor the sitemap or the basic ui which says “It seems like you have not defined any sitemaps yet. To build one, please check the documentation for guidance.” if i delete items and sitemap related to thermostat everything works fine.
do i do something wrong or this thermostat is not working anymore with openhab?
ps: i use aeon labs gen 5 as a communicator and i read some posts here that some of the users with same config managed to add this thing, others couldn’t. i tried already to delete it from the network several times, to addit back or to reset the thermostat according to the manual but no success yet.
any answer kindly appreciated.
Are you sure that the device is compatible with the ZWave system? This particular thread is talking about the Living Connect system which is not compatible with ZWave and requires a special binding. Danfoss apparently decided to make their devices proprietary and incompatible with ZWave. If you have one of these versions of device, then you presumably require this special binding and not the ZWave binding.
If you do have a ZWave compatible version, then you might want to ask this question on another thread so it’s clear.
hi, thanks for the answer. this is what openhab detects: Z-Wave Node 012: LC-13 Living Connect Z Thermostat
how can i know which one is which? what version it is? it says living connect so it means its the one that is not compatible with zwave binding? what about this “z” on the end of its name? and why i can discover it on paper ui?
im confused…
Yep - me too. I don’t have any of these devices, so unfortunately can’t answer the question. Possibly the XML file that OH creates might indicate if the standard command classes are used as I assume that the Danfoss specific devices don’t support the standard classes and only support the proprietary class and some of the standard management classes (but that’s a guess).
as a remark: when i create items from channels i get 4 items:
Number:Temperature ZWaveNode012LC13LivingConnectZThermostatThermostatSetpointHeating "Setpoint (heating)" {channel="zwave:device:1503f015:node12:thermostat_setpoint_heating"} Number ZWaveNode012LC13LivingConnectZThermostatBatteryLevel "Battery level" {channel="zwave:device:1503f015:node12:battery-level"} Number ZWaveNode012LC13LivingConnectZThermostatTimeOffset "Clock time offset" {channel="zwave:device:1503f015:node12:time_offset"} Switch ZWaveNode012LC13LivingConnectZThermostatAlarmGeneral "Alarm (general)" {channel="zwave:device:1503f015:node12:alarm_general"}
tried to add each one, one by one in the sitemap and only the last one can be added! if i try to add another item the sitemap its gone and as another remark is that if i try to add another item from another thing like a watt meter from a fibaro relay the sitemap reacts the same, it disappears! maybe its something wrong in the sitemap file?
The answer if it is supported by Z-Wave or not, is not clear yes or no…
A little history…
When Danfoss introduced the Living Connect Thermostats athermostat could be paired to either the Danfoss controller or a Z-Wave controller, at some point you should choose which way you wanted to go:
- Propetary Danfoss
- ZWave
I think in the beginning the difference was in the firmware on the thermostats.
As far as I know the LC-13 is the Z-Wave version, I don’t know if the early ones also was LC13. As far as I remember one of the problems was that it both supported Danfoss as well as Z-Wave (I actually think that it is the same thermostat under the hood)
Now a days there is a clear difference between the Danfoss thermostat propiertary thermostats and the Z-Wave version. The firmware is completely different, allthough they both rely on Z-Wave.
If you have a newer LC13 (last 2-3 years), it is no doubt that it is a Z-Wave version (and only that).
The older ones has some problems as far as I know.