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.
1 Like
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 ?
4 Likes
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.
1 Like
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.
1 Like
Awesome!! 
So far, current tasks are:
- Clean up the API, add state notifications callbacks
- Normal main loop with events etc, current one is a quick crappy hack
- Implement pairing by OTP. Required for receiving configuration from the phone.
- Write a binding using the library
- Testing against other products, like LivingConnect
Help is desperately needed.
(1) largely solved by now, (2) is in progress, currently for Windows only. I like VisualStudio.