Figure out the purpose of DLG #2
Comments
|
I recently installed a DLG along with a ECL 110. I can make an effort and see if I can buy a cheap adapter. However, I do need the instructions :) It does turn off the pump and close the valve for the incoming district heating when there is not temperature demand.
|
|
Interesting, thank you for posting this. Could you perhaps provide some information about what DLG does or can do when it is connected to ECL110. Because this is not explained very well on the website at all. Basically what we are interested in is what does it do better than just ECL110 alone. I can probably provide some further information later tonight if you are interested in monitoring the communication between DLG and ECL110. |
|
One key feature for me is the ability to schedule the heating from the same app I use with my other Danfoss thermostats and the floor heating (controller by a Danfoss HC, a second one is to be installed). This will allow me to tune my heating in absurdum. I can set away from home temperature on the go, from anywhere. Another key feature is, as mentioned, that heat will be delivered when wanted somewhere in the system. This will allow me to have a nice warm floor in my bathrooms even during summer time. This would else require me to adjust the indoor temperature on the ECL 110 to above 23 degrees, which would waste some heat during transfer. It would also require me to upgrade all thermostats in the house to Danfoss Link. I have a garage and a basement room which is not covered by the Link CC (yet...). The ECL 110 is in auto mode, and the DLG seems to adjust all that is needed in order to maintain the heat. I don't know if the Link system keeps track of an internal heat curve. I've yet to observe the water temperature demanded by the DLG to see if I can map it to any logical step of the heat curve or if it is an arbitrary "this should do" number. My home consists in total of 10 Living Connect thermostats (I have one more not yet installed), 1 HC with five actuators controlled by 3 Danfoss Icon and the DLG. I will soon wire my HC to controll the shunt pump also. |
|
Impressive setup! So far we know pretty much how to read or change data that you can access through the LCD and buttons on the ECL110, because it was very easy to correlate most of these things with the MODBUS readings. For logging purposes it is also possible to read all of the information about status that appears on the LCD, like temperature readouts and pump/valve status and then store it in a time series database for later analysis. To me it feels like the feature that we do not know how to imitate yet is notifying ECL110 of the demand. If we figure this out, it would instantly make the device a lot better for anyone also using MODBUS to control the ECL110. Any clue if the demand is represented as a "yes/no" signal or does it correspond to any specific temperature that is demanded? Thanks for clarifying that you use AUTO mode. I'm using COMFORT, but I really cannot remember if there was any significant difference. I see that you don't have S2 indoor temperature sensor connected (correct me if I am wrong). If you open the temperature submenu (hold enter when you are on the room temperature line), is there anything in S2 that might be interpreted as demand? Perhaps this already provides any hints on how it works. To me it felt that S2 desired temp. is always the same as the set room temperature in main menu, but let me know if they are different in case of demand. Lastly, you are probably running version 1.08, correct? Here is a small outline of the procedure how to start recording data between ECL110 and DLG: Basically you are looking for an adapter like this: https://www.aliexpress.com/wholesale?trafficChannel=main&d=y&CatId=0&SearchText=usb+to+rs485<ype=wholesale&SortType=price_asc&page=1 They are about 4-5 EUR on ebay Europe and perhaps something similar on amazon, knowing that ordering from China might turn out more expensive for anyone in Sweden. If you are willing to wait up to two full weeks (based on last package I sent to Sweden a few months ago), I can also send mine once I can find it - haven't used it for a while.
All you have to do is extend the A and B wires from the connector on the ECL 110 side to the USB adapter. Since you can just unscrew the two middle wires from connector on the ECL110 side, you can temporarily fit two extension wires between the terminal block and screw it back together. To record the traffic between the devices, it is possible to use any serial port program (for windows: tera term, putty, mobaxterm etc...) with these settings. But there are also some programs that can decode modbus from a serial port stream directly, which also might be easier to use. Last time I used some .NET modbus library together with a simple 20-line console application to read in values. Once there is data coming in, the best would be to go through all of the features it has so everything gets recorded for later analysis. Power cycling to see initialization process could be of interest as well. |
|
I placed an order for the RS485 stick (and also for two IR readers so I can get real time district heating readings..). I will get back to you when they arrive. The shipping estimates is in the range 30-50 days.. You are correct that I don't have an indoor sensor hooked up. I have one spare that was included with the ECL 110. I can try what you suggested, and also do the same with the indoor sensor connected. I will have to get back to you regarding the software version and also if the demand is binary or some number (by hunch). I did notice that the DLG has one RJ45. I guess I can use USB to RS485 with RJ45 socket to connect (something like this: https://www.kjell.com/se/produkter/el-verktyg/stromforsorjning/solceller/usb-till-rs485-adapter-for-regulator-p45135 (swedish)). |
|
Isn't the RJ45 in use when DLG is connected to ECL110? |
|
It's free as a bird! The MODBUS cord uses the same connector as power. Can attach photo later today. |
|
Please do :). I thought it would connect to RJ45 on the DLG side like shown in manual:
The adapter looks like the one you'd want to use if RJ45 carried the MODBUS connections, but beware that there probably isn't a standard on how to wire RJ45 for MODBUS. So Epever (or whoever made the cable) and Danfoss could have used different pinouts. If you know how and have a RJ45 crimping tool already available, it would be trivial to just rewire the adapter correctly for it to work with DLG instead. Before buying you can verify that the ECL110 connector B, A (D-, D+ on the pic above) connections are present on the DLG RJ45 by connecting an ethernet cable to the RJ45 port on DLG and then using multimeter to find continuity between the two unconnected sides. Make sure not to do it while the DLG is powered on (disconnect DLG from ECL110 and wall first). If I'm explaining too basic or obvious stuff, you can let me know. It's hard to gauge over the internet how much you already know about electronics or what kind of tools you already have and know to use. |
|
Yeah, one would guess. The connector on the DLG is actually inserted on the right or left hand side (can't remember right now), and looks more like a 6 pin PCI-E connector, albeit smaller. The RJ45 is located in the middle, as by the image. I will test with an ethernet cable. I have some knowledge about electronics, but I appreciate the level of your explanations. |
|
I have continuity between the first and second pin of the RJ45 male connector when viewed with the safety pin facing up.
I think I have software version 1.08. All serial numbers and such seems to point to 1.08 as they start with the number 108. When I toggle vacation mode and home mode, the DLG sends 8˚ and 21˚ respectively as target temperature. |
|
I meant to write during the weekend, but was occupied with other things. The picture is good enough with the descriptions you provided, thank you for that. Vacation and home mode seem fairly straightforward, it's basically what you can do by hand from menu manually too. Also great to hear that you are running 1.08, there was a way to see this from ECL110 menu too, either when it booted up or from one of the about menus somewhere deeper. I'll try to find or write the software to log the data in the meanwhile, Also I feel like I should re-read the manual in english, so that nothing gets lost in translation. |
I bought a DLG some years ago and talked to Danfoss afterwards since the only difference I noticed was the ability to see the outdoor temperature from the ECL in the Link app. After a little digging they told me that the DLG also enabled the Link to control the temperature setting on the ECL based on the highest room temperature requested by the thermostats in the system. E.g. I want 20 degrees in my bedroom and 22 degrees in the living room, so if the living room is requesting heat the ECL goes to 22 and if only the bedroom is requesting heat the ECL goes to 20 (allegedly).
I have pretty much the same setup as Niklas and I've also just ordered an RS485 USB stick. I'm mainly interested in reading temperature data, that should be possible even with the DLG connected, right? Or will I only be able to sniff whatever the DLG/Link communicates? |
|
Thank you for the input, definitely a welcome observation, which makes sense. As for your question whether the USB dongle and DLG can communicate to ECL over the same bus - we don't really know for sure if that causes any sort of conflicts with DLG, but there is very little reason to believe it would be an issue (because why else they would be using RS-485 then). So in short, yes, but we need to confirm it to be absolutely sure. Requesting sensor data that ECL is aware of (S1-S4 readings) is well supported and as a rule of thumb, anything you can see or do using the LCD display and buttons of ECL, you should be able to do using the dongle as well. |
|
I got the thing wired up, I think, but unsure how to proceed.
I've connected with minicom but only getting garbage:
Any suggestions on how to proceed or what I may have done wrong? |
|
You probably didn't do anything wrong as far as connections go. Modbus RTU is a binary protocol, so it doesn't output anything human readable to the serial terminal. So it is actually alright if it produces garbage output in minicom. One thing you can do is turn on hex mode for your minicom (-H). This way you will see bytes instead of garbage, but you will probably still not understand anything without reading on how modbus messages frames are constructed. They are actually quite simple, but for a first-timer perhaps maybe a bit tricky to grasp without help. If you are interested however, there are articles like https://www.modbustools.com/modbus.html which help you to better understand the protocol. There are also programs which can read and format the Modbus RTU output from serial port directly, but I don't know which ones are easy to install or use on a pi. If you know programming, then you can also try using any of the modbus libraries available (python and node.js ones are probably one of the easiest to get up and running), many of which come with examples how to use the library. There are some nice graphical applications made for windows, but it has been long since I have used one. I can look into this during the weekend, if I can't find any good programs, I'll just write my own and share it along with the instructions how to get it running. I meant to do this earlier, but did not have the time for it then. |
|
Thanks, it looks better with -H, so hopefully the wiring is good at least =) I also tried the following program but that fail with either a timeout or (not so often) some CRC error. Very easy to install and would work well for my use (pull data with cron and punt it towards influxdb) but won't help with figuring out what the DLG does. https://github.com/favalex/modbus-cli " Sounds good =) |
|
Tried another library (pymodbus) and same thing, no reply and hitting timeout. Also, with minicom, it takes like a minute before I get any data. I also bought a connector from aviborg, might try that to cut out the DLG just to see if that changes anything. |
|
Check your wiring, could be that your A and B are swapped on the USB adapter. Red should go to B and brown should go to A. Guessing the backside of your adapter looks like this? https://ae01.alicdn.com/kf/H70f7b7e5ba6b4f53952605b8fc7d40c0j.jpg Another thing you can maybe post here is some output in hex from the minicom, it should be fairly easy to detect modbus traffic, if it is being received correctly. I'll also leave http://rapidscada.net/modbus/ModbusParser.aspx here, which is quite helpful at recoding frames from hex, although it requires some trial and error to find the start of the frame and then paste correct length of it. |
That's the one, yes. I think it's wired ok:
Hmm, if I paste my hex into that I get the following error: " |
|
It actually looks correct. One thing you need to mind is that when pasting commands there, you need to know if your frame is a request or a response and then only paste the correct length of it. I haven't gone through entire stream yet, but the beginning seems alright: Notice that response is 1 byte shorter than the request. Next one is again a request and takes 8 bytes... Edit: it is already quite interesting, for some reason it requested PNU (address) 2010, which we know nothing about yet (https://github.com/Ingramz/ecl110/blob/master/README.md) other that it can be requested. |
|
Ah, that's something atleast. It would be nice to be able to actively poll the registers I want but perhaps what I need can be sniffed from the DLG traffic if all else fails. Still odd none of the libraries worked, hopefully I just missed some essential detail. I happen to have an open ticket with Danfoss on a zwave repeater and asked them about reading modbus on the ECL 110 and if the RJ45 port on the DLG could be used for anything in that regard. They claim it's not possible to get anything from modbus on the ECL (heh) and that the RJ45 port is only used when the DLG is used as an CCM module for Danfoss Air units. |
|
It depends on how tolerant or considerate the DLG is when it comes to taking turns with other devices on the bus. The very next request/response is for S1 reading and it's likely you can indeed sniff everything you need at worst. |
|
So request for S1 (11200)?
But also S2 (11201)? Response:
29 should be 2.9 which is increased to 3.0 in the app 5 mins later:
|
|
I'm not sure what is meant exactly by Physical/Logical representation here, but I think the way it is documented in README is all based on the "Physical" value. But indeed, since it is in 0.1C increments, it's 2.9C, which seems correct based on your confirmation. |
|
Confirmed by checking an S3 modbus value against the readout on the actual unit. Pretty cool, then I just need a parser of some sort. |
|
To further both your and my purpose I think it would be cool with a little python daemon that listens on the serial port and parses the stream into requests and responses. Those could then be persisted in whatever form you would like for DLG discovery and I could probably manage to tack on some MQTT code and punt the relevant values off to OpenHAB/InfluxDB. Somewhat like https://github.com/ThomDietrich/miflora-mqtt-daemon which I'm using so the missus remembers to water her plants. Do you have time to hack up a little daemon to parse and persist? |
|
This works btw, getting a nice stream of bytes: It takes like a minut after starting before I'm getting any data. |
|
It looks like my understanding of modbus was incorrect and wikipedia was quite clear about pointing it out:
https://en.wikipedia.org/wiki/Modbus#Communications_and_devices In our case the ECL is a slave device and typically the USB adapter and DLG are master devices. The request-response cycle is rather straightforward too, send a request, wait, expect a response for your request within a certain time frame. So people from Danfoss actually are right that you cannot connect more than one "master" to the same bus that ask readings from slave device(s). The reason why becomes clear as soon as you try to request information from a slave device using two masters at the same time - neither master knows how to take turns with the other. There are clever ways around this, but most of them require additional hardware, for instance splitting the bus using two USB adapters (one acting as a master and other as a slave) and then relaying or buffering the messages between them. But in many cases this is not worth the trouble. However as established earlier, we can still monitor the bus without interfering with the ECL-DLG communications. I'll look into it now. |
|
I concur, I read as much as well. I made some monkey code to get the values I want into OpenHAB: I'm sure parsing can be made a lot smarter but so far so good. |
|
No, because I only had one device, but interpreting requires typically two devices communicating with eachother. It makes no sense if there's only one that sits quiet. You can give it a try however. If you know what should be contained inside the frames, you can start mapping out the locations of the data you are certain about. For example this person also tried sniffing frames almost 3 years ago: I can't see where the 19.97 is in however, 24.22 can be found inside the other frame, which is 2422 in hex: I have no idea what any of the other bytes correspond to. So you can use similar logic to do educated guesses regarding what you are looking for. The easiest ones usually are ones that you can change on demand, because then only that one specific part should change. |
|
I actually commented at the end of the same thread 🙂
The same guy provided another example further down the thread so I've
started mapping by setting room temperatures to something unique.
Thanks
…On Sat, 16 Jan 2021, 14:39 Indrek Ardel, ***@***.***> wrote:
No, because I only had one device, but interpreting requires typically two
devices communicating with eachother. It makes no sense if there's only one
that sits quiet.
You can give it a try however. If you know what should be contained inside
the frames, you can start mapping out the locations of the data you are
certain about.
For example this person also tried sniffing frames almost 3 years ago:
https://community.openhab.org/t/danfoss-living-connect-new-proprietary-z-wave-binding/34263/16
I can't see where the 19.97 is in
0x00021028120C054720202021030020102011030F031703280318032F0330057F0800049D013700004901C06599DA
however, 24.22 can be found inside the other frame, which is 2422 in hex:
0976
0x0002100A0D0D0001000409761C9A655E
I have no idea what any of the other bytes correspond to.
So you can use similar logic to do educated guesses regarding what you are
looking for. The easiest ones usually are ones that you can change on
demand, because then only that one specific part should change.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#2 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AMBD23NLVNYTTZ2GBXEWIV3S2GJH3ANCNFSM4EGJLKVQ>
.
|
|
Hi, We just got a Danfoss ECL110. I've connected the same way as @plysdyret but i don't get any response at all. Tried to switch the 2 cables (just for testing), but still no response. Running on a RPI3+ with the same blue dongle attached. Are there anything I can do to test? Thanks in advance |
You have Link CC and DLG also? |
|
No. Only ECL 110 directly connected to RPI using the dongle |
I never got into actually talking to the ECL, I'm just listening to traffic. Without Link/DLG you'll need talk modbus to the ECL to get answers. |
Ahh. So without Link/DLG I've can't use the dongle? Or should it work reading modbus messages? |
I think it should work just fine for reading modbus messages, but you'll need to query the ECL yourself to get anything to read. In my case I'm listening to the Link CC talking to the ECL. |
So basically I have 2 options:
or
|
Yes. But you would probably need the Link CC also, as I don't think the DLG does much on it's own. There should be modbus libraries available so I don't think it would be hard to use. The registers etc to query are known from this thread. |
|
It all depends what your experience with doing similar stuff is. If you can follow basic examples for instance in python, then you can find ready made examples to read modbus registers using pre-existing libraries. Some home automation software includes installable plugins for modbus, but they require you to learn how to configure them, so it can be easier than programming, but if it's totally new for you, then it might take the same amount of time. The keyword is "modbus master", there is a variety of software available online that can act as one. |
|
Did anyone ever find out how Danfoss Link writes indoor temperature to the ECL through DLG? |
I'm afraid not, but I haven't searched if there's been any advancements outside this repository. The main issue is that we haven't found a person with all of the required devices that's also willing to try to find it out for us. |
|
I don't have much time to devote to this, and I no longer have a zwave dongle, but I do have Link+ECL+DLG+thermostats running and I am sniffing the modbus traffic on the ECL to get forward and return temperatures etc. I can't help without a zwave dongle though, or? |
|
I am very much interested in the Modbus side of things, in particular how the temperature of the thermostat is relayed to the ECL, if at all. So, no zwave dongle. |
|
I seem to recall that the thermostat temperature doesn't get transmitted to the ECL so it can't be sniffed that way. We only get the registers mentioned earlier in this thread: #2 (comment) I spent quite some time trying to debug zwave payloads to solve this before eventually giving up. See this thread near the end for some details on that: https://community.openhab.org/t/danfoss-living-connect-new-proprietary-z-wave-binding/34263 |
|
Okay, so the ECL is controlled by means of adjusting desired room temperature. Probably because S2 is not writable. But it means there must be some logic in place on the Link side to emulate the behavior that the ECL would have if a sensor was connected to it. |
|
I've been thinking of making something similar that simply spoofs a room temperature sensor connected to S2, but never got to building one myself. @Soerengellert, could you expand on your idea of using a DAC? Which one are you using, does it need any extra circutry between? |
|
I use a Wemos D1 esp8266 module with an MCP4725 module connected directly on a breadboard. Quite simple, really. |
|
I ordered some MCP4725 and MCP4728 (4 channel version with internal voltage reference) modules from aliexpress, but they very likely will arrive when the current heating season is about to be over. My only concern at the moment with this approach is that I do not want to recommend it to others before I know for certain how the measurement circuit for the Pt1000 sensors is implemented on board. However considering that it can detect both "not connected --" and "short circuit ---" states safely, it will be very likely the classical voltage divider/op-amp circuit you can find online. Once there is enough evidence that it will be fine, I think this solution will most definitely beat any other approach in terms of both cost and simplicity. Personally I'm rather excited to get rid of the eyesores that are S1 and S2. |
|
I don't know anything about the sensor circuit. This solution definitely has it's drawbacks.
|
|
I think out of all of these 2 is probably the most concerning. Drift could be explained by "unstable" or drifting reference voltage. MCP4725's output is based on what you are giving it through VDD pin, so it could be that either the USB power supply or linear regulator on the D1 mini isn't good enough to provide a stable output over long periods of time. I am hoping that the MCP4728 will be immune to this, but I am just guessing. For non-linearity I don't have any suggestions at the moment. Can you give an example how much do you roughly need to increase/decrease DAC value to shift the temperature reading by 1 degree (also mention at which resolution, 12-bit?). I am guessing you are using +3.3V pin to power the MCP4725 module, right? Pt1000 itself can also be slightly nonlinear, depending on who has characterized the resistance-to-temperature conversion, but room temperature values should nearly always be in steps of 3.8-3.9 ohms per degree. |
|
To be fair, a single degree change can happen at a very minimal DAC value change, it's probably worthwhile looking at a longer span of temperatures, like 5 or 10 degrees to correctly assess the linearity and whether the change happens at even intervals. It could be also that the update rate of ECL110 isn't quick enough to instantly register a temperature change, however again, it's just a wild guess. |
|
Regarding drift, I have tried a couple of different (cheap) USB power supplies with no difference. Drift may very well explain all my woes as it is impossible for me to pinpoint an accurate curve with the drift. With regards to how much I need to change the value, I'll need to look it up in my notes. I only have floating-point values between 0 and 1. 1 being 3.3V as you correctly assume. |
|
I forgot that internally the modbus registers hold temperatures at 0.1C increments, so observing a 10C range would a lot. You can probably get the same information from 1-2 degrees, which should give you 10-20 data points. |
|
These are my figures. Sorry for bad formatting. Deg. C float |
|
The points do almost form a line. I encourage you to try operating with raw DAC values instead (0-4095), maybe the extra resolution here will help you land on a specific temperature value easier compared to using floats. 0.1C increase per 1 DAC value is about what I would have expected from such a device.
|
|
I am going to order ab MCP4728. |
|
Difficult to say, need to look where that 5V is coming from on the main board to be absolutely sure. |
|
Open the discussuion: I am using Home Assistant OS Do someone have any idea? |
Danfoss Link Gateway or 087H3241 is a companion device for connecting ECL Comfort 110 with Danfoss Link CC. As the name says it acts as a gateway between the RS485 line and 868MHz RF communication.
An application example from http://heating.danfoss.com/PCMPDF/087H9216_VIJMC36K_DLG_ECL110_Link_IG.pdf shows how it should connect, however the indoor temperature sensor S2 is missing, replaced by DLG. Documentation doesn't mention anywhere that S2 should be removed (but should make sense as Danfoss Link temperature sensors should be used. Confirm whether S2 is omitted intentionally or it serves for illustrative purposes only.
http://heating.danfoss.com/PCMPDF/VDKTC902_ECL110_LINK.pdf promises the following:
Water is only circulated (pump is on) when any of the radiator valves is open/the indoor temperature is below threshold? We can control the pump in manual mode, but that is not possible in comfort mode. My gut feeling tells that Danfoss Link CC somehow provides additional control information to ECL110, but no idea what it is.
That one interface being Danfoss Link, not useful for us.
Given that heating is not ON 24/7, same as 1?
Reads outdoor temperature sensor S1 from PNU 11200, we can do that already.
It doesn't hurt to ask Danfoss regarding the working principle either, it shouldn't be a huge secret how the ECL110 controlling part works.
If you happen to own a DLG and rest of the system (mainly Danfoss Link CC), it would be extremely helpful if the communication was sniffed using a USB-to-RS485 adapter ($1 from ebay) and a computer to connect it to. I can provide further instructions if necessary. The process is nondestructive and safe to do.
To sweeten the deal, I can offer a 014G0002 for anyone in return.
The text was updated successfully, but these errors were encountered: