Hello! I own this product : https://www.devismart.com I am also an experienced engineer and i would like to have a binding for it.
So far i was able to reverse engineer application-level protocol. Now i have a demo command-line tool, which connects to the device and reads data back.
Spoon of salt, however: the communication relies on this service : http://securedevicegrid.com . They ship a library in the form of binary blob, which handles all the tunnelling. A demo version of the library with documentation and sample code is available on github, but the production version is somehow tweaked inside, making it incompatible with the demo. The demo successfully connects to the infrastructure, but fails to communicate with peers. So my test app is using a blob, extracted from Android app, and runs on Android.
So question number one: it is possible to make it running on GNU Linux using hybris (https://github.com/libhybris/libhybris), but will OpenHab accept such a contribution, containing extracted proprietary blob? Is it worth spending time on it?
Option number 2 is to reverse engineer the communication library itself. I have made some progress in this direction, it deems viable, but i need some help. If there’s anyone interested, please reply here or in PM. I will share all the code and info i have
There was already a similar effort : Danfoss living connect, new proprietary z-wave binding , but the activity seems to have ceased and i’ve failed to contact them and acquire any artifacts so far.
I’m not a developer and my opinion is not definitive. But I would expect the answer is a weak maybe depending on the nature of the license that applies to the binary blob. If it’s a “you’re free to use this blob in any way forever” then it might be OK. If not than I’m positive the answer would be a no. And from your description, this sounds like you’ve extracted this binary blob from the Android app without any explicit permission to distribute it at all. In that case, trying to distribute the blob would in fact be illegal in many countries.
But even if the license is super permissive, I imagine the project would not be happy about accepting a binding that requires a proprietary binary blob.
I think Option number 2 would be the most likely way to get a binding approved. But for the short term, an alternative is to write a stand alone bridge similar to Zigbee2MQTT. Once you get it to talk MQTT you have automatic compatibility with OH and most other home automation systems.
But I’m not a maintainer or developer on OH so my opinion doesn’t carry much weight on this. But I do have a good deal of experience with OH and working with the devs.
This looks like the license for only the demo on their GitHub page:
You may use these examples and demos for evaluation purposes only. Using SecureDeviceGridTM in your product requires a license. Please contact us.
So unless you would in somehow get permission to use any binary code it can not be accepted as it would be illegal.
Having a binary blob would not directly be a showstopper. There are bindings that support specific platforms and contain binary code. Like bluetooth or gpio binding.
Well… Thank you for the information. If using a binary blob is not a stop sign itself, then i know what i will do. The original Android app’s license allows me to install the app on any devices i own with no restrictions. So it is allowed to install an APK on an OpenHab server. 
However i am making some progress in understanding the tunnelling protocol, so “apk in a box” is a backup plan.
Also it is worth to note that it ts technically possible to communicate with the device directly, thus avoiding any interaction with Trifork’ infrastructure completely.
That doesn’t mean you have a license to redistribute it. You can build a binding using the blob but you cannot submit it to the OH project unless you have an explicit license to redistribute the blob. License to use does not grant license to distribute.
I’m not talking about redistributing the blob. What i mean is to require the user to download the app from e.g. APKPure (isn’t it legal?) and install it manually (e.g. via PaperUI). Then the binding would pick it up and use.
Debian does the same thing with proprietary firmware blobs.
If you are not getting the binary blob directly from the people who created it, the legality is dubious at best.
Yes, and Debian has gone to the owners of those blobs to ensure they have the legal right to distribute them. And they obtain the blobs from the owners of the blobs, not some random third party site that may or may not have the rights to distribute them. I’m not a lawyer but this looks really shady to me.
Well, good news…
First, i’ve found a bug, which prevented Windows version of my testapp to work. So, github version of the library is actually fully compatible with the thermostat. No more need to fiddle with the Devi app.
Second, i’ve made a breakthrough in understanding the tunnel protocol, so there will be a FOSS code.
I think it’s now time to present something to the public. Hopefully there’s someone interested. I’ve removed illegal artifacts from my test code and here it is:
Any followers ?
Today i have completed the handshake with Trifork cloud and got READY packet with completely handwritten code. The next thing is to figure out how to tell the cloud to connect me to other peers.
Sounds promising … I also own a DEVIReg so I am very interested in your progress
I guess i’ll release some code this week
Got hold of plaintext data, running inside the tunnel. Some binary serialization format, not identified yet, but thanks to previous Christian’s effort i think it could be protobuf. Will try this today.
Sounds good! Remember that the protobuf serialization format is in the lua source and the android source that i previously shared with you
Thank you very much, yes, i remember. I guess message format should be the same or closely related. Have already looked at them.
Interesting that not all packets successfully deserialize as protobuf. Didn’t found out too much yesterday, simply crashed asleep…
It is protobuf with prepended header. A toy decoder in python is available in DeviComm repo.
The work is in progress, i have come to the point where i am about to connect to the actual device via the cloud. Some details need to be figured out plus the main loop needs a big overhaul in order to support more than one socket. Current blocking approach just won’t do and i don’t want to enforce multithreading.
To the honor of Trifork the cloud is really secure because it does not listen to unencrypted traffic between peers. Once the forwarding is set up you start talking directly to your device using asymmetric cryptography.
The only noticeable flaw of this architecture is a need for Internet connection. Once it’s down your link is lost, even if you are on the same wifi. But this is not SDG flaw, it allows local connections; but DeviReg’s fault. Apparently once it is connected to a wifi as a client it stops listening on local port, forcing you to use the cloud.
And it is probably impossible to redirect it to your own server because it most likely verifies server’s public key, which means that in order to clone the server you also need to have its private key.
It’s alive!!! 
I am reading raw data from my thermostat using my library.
The API is quite draft, little thread-safety, no notifications. Will improve over time.