I have already told this story several times. Would be great if someone tells me why nobody seems to understand me. Is my english so terrible ?
So far, it all starts with LinkCC using older encryption protocol. Encryption protocol defines format of “peer IDs” - this is how devices on the cloud (called “Grid”) know each other.
The newer protocol is called MDGBinary. The client-side implementation is available in my library source code. All the communication (except forwarding request) happens on top of that encryption. PeerID for this protocol is a 32-byte hexadecimal number. In fact the protocol uses a pair of keys: private and public. The public key is your peer ID.
According to what @ChristianHC told me, LinkCC uses standard SSL/TLS for encryption. This is what you should start with. Also, i don’t remember who, showed me what those PeerIDs look like; those are long ASCII strings, containing digits and letters a-z. Those are way longer than 32 bytes.
@Vyacheslav_Anisimov This is what you’re getting. The forward request contains protocol signature (see ForwardRequest constructor); and it has to match on the remote side. It doesn’t, because LinkCC’s protocol is called differently, so the Grid rejects the request and returns you an error.
And no - C version doesn’t do anything that Java version doesn’t. They are functionally equivalent, just i tried to give the Java version at least some internal design C version was the first one, i wrote it by looking at the original library and nothing else; so it ended up in somewhat messed up code and inconvenient API in places.
Bottom line: you need to implement another EncryptedProtocol subclass, with the same interface as MDGBinary (well, except peer IDs of course), which would do the OpenSSL encryption. From that point establishing the connection should work.
Next step could be some tailoring of PairingConnection. Its challenge-response process is strongly tied with peer IDs being used. I looked at original LinkCC LUA code (provided by @ChristianHC ), frankly speaking it’s a barely readable mess, looks like there are some differences here. Without this part the remote phone, from which you want to download the configuration, will refuse to talk to you, even though you’d know its peer ID from the start.
I’m new to openHAB but I’m determined to see if I can get my devireg thermostats working with geo-spatial awareness (so the heating switches off when everyone leaves the house) before I give up on them and buy some new hardware.
I’ve installed the latest openHAB 3.3.0 on Ubuntu 20.04.1 LTS, opensdg 1.0.3 and dependencies, and have downloaded in moved to the appropriate folder the binding .jar 2.1.
When I navigate to https://localhost:8080/danfoss/ I get:
When I enter the pairing code, it fails. On my iPhone’s Devi app I get the message:
An error occurred - something went wrong, couldn’t send configuration
On the webpage I get:
Error : Failed to connect to the sender: Connection refused by peer
An in the log file I see:
2022-12-11 15:07:01.759 [INFO ] [nfoss.internal.DanfossGridConnection] - Successfully connected to Danfoss grid
2022-12-11 15:07:05.481 [INFO ] [nfoss.internal.DanfossGridConnection] - Last user is gone, disconnecting from Danfoss grid
I had a very similar behaviour. You wrote you used an I-Phone just like me.
For me it worked to first pair an android-device (running in a virtual Machine), and then enter the pairing code from the android device.
I have now set up my devireg twice, and both times the I-phone would not work.
Having read the thread I have the impression the equivalent of the DeviSmart mentionned in 2019 is nowadays this module 088U1101 Danfoss Icon App Module. Can anybody confirm my understanding is correct?
Then I am wondering if anybody integrated instead with the Zigbee module 088U1130 Icon Zigbee Module which seems to enable a more open integration running openHAB on a raspberryBI or equivalent.
I hope I haven’t missed any post above already explaining this. A search with these two references brought back zero result.
Does anybody have some feedback or advice integrating with one of these two modules?
AFAIK devismart and icon are two different systems and are not interchangeable. Support in the binding is based on some dumps I made a while ago. (both systems use the same online grid/protocol) I haven’t used the binding for a while because I didn’t install it after I reinstalled OH.
I tried but unfortunately my icon controller is too old (088U1072) so check your controller version before buying the Danfoss zigbee module/addon.
Hello! DeviReg Smart and Icon are indeed not interchange, neither their components are compatible/interoperable. DeviReg is a small-scale solution for apartments, it constitutes a single standalone regulator for one room. Multiple regulators in a system don’t interoperate in any way. Icon is a large-scale solution for a family house; it consists of controller, one or more room sensors, and extra accessories like pumps/valves.
Just their Wi-Fi protocol appeared similar, and they share the same cloud, so i packed Icon support in the same binding. Original Icon phone app also may support DeviRegs, however they still don’t interoperate with Icon system, they just sit there.
Thank you for your fast reply. My controller 088U1145 is indeed compatible with the 088U1103. I will order it then share a feedback on a separate thread
Would be great. Wanted to use your integration on openhab running Raspbian arm…
And totally changed my mind with 15 tabs opened whyle trying to install all the required libraries )
Do you mean you don’t know which folder to copy it to; or are there some problems with docker image being reset every time?
In the latter case i don’t know, sorry, i am not a fan of docker at all. I know it’s problematic, you need to rebuild the inage, because in fact docker isn’t a customizeable thing at all. It is in fact not meant for distributing software like this, i don’t know why people do it, perhaps just because it’s a fashion trend
C version was the first one, i wrote it by looking at the original library and nothing else; so it ended up in somewhat messed up code and inconvenient API in places.
