Strange readings from the bus.

[silfax]

Hi, I am trying to implement your solution for monitoring my boiler, but it looks that I'm stuck at the very beginning. All I get from reading the bus is: I really don't understand where that 1;1fffffff; is coming from. I tried looking with an oscilloscope and it looks that whatever is transmitted over the bus stays always the same, with a lot of high level, which may explain the Fs. Any advice on where to start debugging? Thanks!

[flyingflo]

Hi, at least it seems to be a valid frame.

One important thing I remember is, that the remote control and monitoring feature must be enabled to receive useful message.

This is in the settings menu of the control panel (called "Serviceebene" in the manual)

• "Allg. Kenndaten"
  • "Fernverstellung": "ja

hope that helps Flo

[silfax]

Thanks a lot for taking the time to reply. The setting indicated by you is correct, I was aware of it. However, there seems to be a basic thing that I don't get, namely the position of the rotary switch for setting the address. It was on '0' at my boiler. If I understood correctly from your software, it should be on "1". However, once set to "1", the MEC2 immediately displays an error that cannot be cleared and I still get the same 1;1fffffff; on the bus. The "gravity switch" seems to be missing from my version of board, but I installed a 120 ohm resistor. Any hint? Thanks again!

[flyingflo]

Hmm.. I've no idea what the gravity switch would be.

Anyways, the bus adress has some special meaning:

• 0: standalone controller, does not communicate on the CAN bus.
• 1: master in a network controllers.
• 2-15: any slave controller.

[flyingflo]

Do you have more than one controller on the bus? I think it should be possible to use any other adress except 0 for this purpose.

[flyingflo]

NM482 is the power supply module.

[flyingflo]

Ok, now I got it. The NM482 is the module with bus connector and it has a switch for the bus termination resistor. The bus should be terminated on both ends, however, it seems you already receive valid messages, so physically the bus seems ok.

[silfax]

Yeah, as I told you, I installed a 120 ohm resistor. The gravity switch (which is missing from my version of the board) was supposed to do the same thing, I guess, but by connecting a resistor already installed on the board. There is also a resistor on the can interface. I would say that I have this covered correctly.

I only have one controller on the bus. As per my understanding, the MEC2 doesn't count, since it uses a different bus.

The setting of the rotary switch is a bit confusing. "0" is standalone and it would be consistent with nothing available on the bus. "1" seems indeed to be master and it would also be consistent with the error message I get on the MEC2 (no other devices on the bus). I haven't tried with "2" or more, since there's the following table in the service manual: As far as I understand, setting the switch to 2-15 is not valid for 4211 and would probably make the controller a slave with no master on the bus(?). I was reluctant to experiment with that mid-January. :) Can you remember how your switch is set? My controller is a 4211 and consists of 1 x NM482 power supply module and 1 x ZM422 or ZM434 (can't tell for sure right now, I'm not at home). Maybe your setup is different?

Thanks again!

[flyingflo]

The controller ID is set to 1 on my device. I'm not sure about the installed modules, currently, but sounds familiar. It was some years ago, when I built this.

[alesha76]

Hi! I had the same problem(71 bus errors), I decided to play with the addresses in Arduino on Esp, I set byte sndBfu = CAN0.sendMsgBuf(0x11, 0x8, data) for transmission; and after that everything worked. In principle, to repeat, you first need to download any library under the MCP2515 CAN controller or under yours - I don't know what kind of CAN you have) and try to get data from the bus in a readable form Standard ID: 0x400 DLC: 8 Data: 0x87 0x06 0x09 0x05 0x19 0x16 0x01 0x07 and if you get this or something similar, then there should be no problems.

[flyingflo]

I think the bus looks ok in @silfax setup. The question is, why the controller panics if it's address is set to 1.

[silfax]

Hi, Alesha. Thank you for your input. The board I use is probably the most common you can find: I use the MCP2515 library included here by Florian., together with his software. As I was saying, it seems that the issue is that I cannot "convince" the Logamatic to send anything on the bus. In the Buderus RS232/ECO-CAN adapter manual is somewhere stated that the default mode of the controller (Normal-mode) is to just send data on the bus, no request needed. It also seems that if the device has the address 0, there will be no data sent whatsoever. Now the problem is that even if i select address 1 from the rotary switch, there's still no data on the bus. Just sets of high level bits, which would explain the Fs. Could you please confirm that your Logamatic address is set to 1? If so, do you get the MEC2 error described above? Even if the communication would work (which it doesn't), the MEC2 always displaying an error is a bit of a deal breaker for me. The other members of my family rely on the MEC2 for info/settings and for the moment it looks that I'm nowhere near to provide them an alternate solution.

[silfax]

I think the bus looks ok in @silfax setup. The question is, why the controller panics if it's address is set to 1.

And not only that it panics, but it seems that it refuses to send any data on the bus. I checked with an oscilloscope the terminals where the MEC2 is connected and it is obvious that the data is changing and you can notice different bytes. You are probably aware that the communication with the MEC2 is serial as well, but at a lower speed (1200bps).

[alesha76]

I have the controller value set to "0", I can't send either, but as I wrote earlier, I played with the addresses and I got it, apparently in the flyingflo code you need to fix the controller address in the transmission line

[alesha76]

Yes, and according to the initialization of COM MCP2515, I have it like this in arduino if (CAN0.begin(MCP_ANY, CAN_50KBPS, MCP_8MHZ) == CAN_OK)

[alesha76]

And another question is what kind of buderus 2107 or 4211 system do you have

[silfax]

Taking your last three messages in order:

1. My current goal is to use this system for monitoring only, therefore not being able to send commands wouldn't be an issue at all.
2. The initialization of the CAN interface is correct, I receive the confirmation message.
3. It is 4211.

[silfax]

I have the controller value set to "0", I can't send either, but as I wrote earlier, I played with the addresses and I got it, apparently in the flyingflo code you need to fix the controller address in the transmission line

Could you please elaborate a bit on the address topic? I don't know, I may have got it completely wrong, but here is my understanding of how Florian's software works:

1. "heat-can" acts just like an interface and publishes the CAN raw readings to the mqtt server. I would say that the address should not be relevant here.
2. The "logamatic" python script does the further processing. This script also sends some commands to the controller, therefore here the address would be of the essence for directing the message to the correct device. I did not dive very deep into this part, my first goal being to at least see the raw data published to the mqtt server.

Is the above correct or did I mess it up?

[alesha76]

Well, then I think that you need to look carefully at the program code, I also did it a long time ago, the experience of flyingflo helped me, I have been tracking this topic for a long time, it has advanced further than others, but I implemented it on arduino (esp8266 + MCP2515 like yours) and it works for me. It may be easier for you to write your own code if you receive data from Lagomatic, there is nothing complicated there, and codes from 2 flyingflo branches can be used as a bus data decoder and I took another example from this MarianMajor76 / ArduinoMec2 dipositarium - the author monitored the solar collector, he also has 4211 The principle is the same only we read from CAN tires and he's with BF

[alesha76]

I won't be able to comment on the work of flyingflo, since I couldn't launch it) so I wrote my sketch at that time. It was important for me to get the result and I tried different options in the end I settled on arduino - it is more understandable to me.

[silfax]

Yeah, reading the MEC2 (BF) bus is my second option and I will give it a try the incoming week-end. I have already prepared a level shifter for connecting the Logamatic with an ESP32. I was aware about Peter Holzleitner's project long before, but I would say that Florian's is a more stylish approach. Thanks for indicating the other repository, I wasn't aware of it. I'll take a look.

[alesha76]

Good luck, write me any questions!

[flyingflo]

"heat-can" acts just like an interface and publishes the CAN raw readings to the mqtt server. I would say that the address should not be relevant here.

Correct. It is just a MQTT <-> CAN gateway. It does nothing on its own. It has to configure the CAN controller according to your hardware and set the correct bus baud rate. Then it sends to MQTT whatever it receives on the CAN bus, and vice versa.

The raw messages are far from human-readable. Thus, I wonder what @alesha76 does with them?

The "logamatic" python script does the further processing. This script also sends some commands to the controller, therefore here the address would be of the essence for directing the message to the correct device. I did not dive very deep into this part, my first goal being to at least see the raw data published to the mqtt server.

Correct. Here, the protocol logic is implemented. The reason for this separation is development iteration speed. This reverse engineering took countless iterations, which were much faster on a fast PC with python, than on the arduino platform, were each iteration would require a full compile-update cycle. Actually, this program sends nothing by itself. It just decodes monitor data (which comes without request) and sends it to structured MQTT topics. However, there is one exception. The controller broadcasts its complete config on startup and later only sends incremental updates. Therefore, if the script hasn't received the complete config (because it was started after the logamatic), it requests it once at startup.

Another side note: The protocols (e.g. normal-mode, direct-mode) described in the documentation from the manufacturer, like the RS232 Gateway and the service key, are different than the CAN protocol. These devices translate the framing and handshaking.

Ideas for troubleshooting, @silfax :

• In the settings menu of the MEC2 there is an error log, which saves a number of recent errors. Can you find something useful there?
• I suspect it could be a hardware problem. CAN bus nodes detect errors while sending their message. Probably your logamatic goes into error mode after sending the first message. Then panics, shows an error message and remains silent.
• Try to start the logamatic with address 1 without your hardware on the bus, and see if it shows the error as well. CAN bus has an acknowledgement mechanism on the link layer. So probably this causes an error as well, if nobody is on the link. (I also don't want to try it during winter). And probably this is the reason for the error with address 1.
• You could double check the bus line polarity (can_hi, can_lo), reduce line length and probably try it without termination resistors on one or both ends. When the lines are short, termination shouldn't matter.
• You mentioned you have access to an oscilloscope. Are the signals in spec? You could even dig deeper and check if the ACK bit is set in the CAN frame (which indicates two working nodes) and such ..

[silfax]

Thanks a lot for your helpful input, Florian! I will check tomorrow. 4 is partially checked. I mean polarity is definitely correct. I did some testing without resistors, but I cannot recall exactly how, so I'll try to do it once more. The cable is about 1m long, so quite short, it is CANBUS dedicated cable, shielded, twisted-pair. There's a screw connector at about half length (installed for convenience), but it shouldn't make any difference, I guess. 5 is also partially checked. Levels look ok to me with 1.6-1.7V differential voltage, signal well defined and square shaped. I will try to dig deeper after reading a bit more about the specs of the CANBUS protocol. 1, 2 and especially 3 seem more promising directions to explore, though, so there may be hope after all.

[alesha76]

hello friends! flyingflo I process the data of the CAN Logamatic bus in the ESP8266 controller (ESP 32) according to the Buderus manuals "Monitordaten_System_4000_V1_7747004149_01-2009.pdf". The processed data is transmitted to the WEB interface and used by MQTT in the home assistant. @silfax the length of the supply tire can be 25-35 m, when I tested it at home, I had exactly that. Buderus is in the Basement and had to pull the wire) before that, I had to run with a PC and a controller to Lagomatic every time, which was not convenient and took time. And about the resistance at the ends of the 120Om bus: jumper J1 on the MCP2515, a jumper is installed on the Logomatic under the CAN connector, an iron bracket - it is barely noticeable, but it should be since it is also integrated to close it.

[alesha76]

I have implemented like this (but not completely) there is no time to manage day and night through the Web Interface.

[silfax]

Did some testing last night and I can only suspect a hardware issue in my Logamatic controller. Whatever I tried, in whatever configuration, nothing else gets transmitted on the CANBUS, except for the packets of high level bits that would be consistent with the Fs. There's no variance of the signal, not even a single bit changes over time. I think the other things I checked are not relevant anymore if I don't get any data on the bus. I will most likely give up on this and move on to trying to read from the MEC2 bus. At least I know for sure that there's plausibly looking data over there. Thank you both for the support!

[flyingflo]

The CAN bus lines do show valid physical levels, right? What exactly do the high level bits look like?

• in recessive (passive) state, both are about 2,5V
• in dominant (active) state, can_hi is close to 4V and can_lo is close to 1V.

(iirc..)

[silfax]

I can't really say what the levels are. I think that this would mean measuring them against a ground terminal. Unfortunately I am not able to identify one. The space being too tight, I am unable to read anything on the board. I am measuring them one against the other. Below is what I get: So I have 2.1V low/high, which could be consistent with the voltages indicated by you. Regardless of the levels, I don't think the shape is correct. The block of data in the photo gets repeated forever, with no variance. I suppose that I should see different bytes of data with different 0s and 1s, not always the same succession. The BF terminals (the ones for the MEC2) clearly show different bytes of data travelling on the bus.

[flyingflo]

Wait, no ground terminal? That's not good. CAN bus signals are differential, but not isolated. Both nodes need to measure them relative to the same ground potential.

I'm quite sure the connector on the logamatic has three pins: hi, lo, gnd (?). The ground signal should shield the wire and connect the nodes.

The signal in the image looks good, I would say. You can't see whether the content of the frames is the same, from this perspective.

[silfax]

The connector has indeed 3 pins, but the wiring shows only 2: Also, from what I read, it looks that CANBUS should work with 2 wires. I think I've tried measuring the terminals 2 & 3 relative to terminal 1, but I don't recall getting anything meaningful. I'll take another look.

[flyingflo]

It will work with two wires, if the nodes have the same ground potential by other means, e.g. all are connected to earth potential like the logamatic, or all are in the same car. But if your second node is e.g. powered by a USB power supply and connected nowhere else, it will be isolated, and you must define its ground potential.

[silfax]

Ok, but the CAN adapter module only has pins for CAN-H and CAN-L:

[alesha76]

Hello friends! a small remark: I have connected without ground and everything works. As I remember, there was one problem in the Logamatic and MCP2515 module interface project: I also couldn't get anything with CANBUS for a long time - the problem was that not all libraries work correctly with this module!!!! I tried a huge amount until I found the necessary one. @silfax try compiling a trial sketch for reception from the library and see if you get anything in the port monitor!!! if not , there are other bible libraries in GitHub under MCP 2515, try them ! you should get a listing of the lines in the port monitor as I previously sent. I'm using MCP_CAN_lib-master

[alesha76]

And also try to get something small, play with ESP pins from the bus, it's possible that with the module. You have ESP 32 in the NODE MCU ESP8266 project !!! if there is an option to have ESP 8266, try with it.

[silfax]

I am running the software on an ESP8266 and have tested communication with an identical adapter.

[alesha76]

Are receiving and transmitting packets going through the port?

[alesha76]

Hello @silfax! A working library with examples for CAN BUS will help you read the Lagomatic bus. I use it in my project. https://github.com/coryjfowler/MCP_CAN_lib.git

[silfax]

Hi, Thanks for the tip. I will give it a try one of these days. For the moment I've been successful in reading the data from the MEC2 bus. I built a level shifter by myself in the end (fortunately the parts are quite trivial) and I've connected it to an ESP32, which serves the data over TCP/IP (this is an idea I got from somewhere else, but I liked it better, since I can avoid running a longer cable or installing some computer close to the boiler). I've also translated the original Perl script to Python (chatGPT has been very helpful) and I have everything mostly up and running, the data being published to MQTT. Today I am planning to dockerize the python script so I can run it on my Synology NAS (which I use as a Docker host) and that would be all. Oh, and I will still have to put the level shifter and the ESP32 in a decent case.

[alesha76]

@silfax I congratulate you on your success! Yes! Thanks @flyingflo for his idea! But as life shows, everyone chooses their own way of solving!)))

[flyingflo]

Cool. I'm curious what the protocol looks like on the MEC2 bus. @silfax?

[silfax]

Well, as far as I can tell it is fully identical with the protocol used on the CANBUS with the data corresponding to the description in the 7747004149, Monitordaten System 4000 document. I suppose it was the obvious choice for the Buderus engineers, not making sense to implement two different protocols. The communication is at a lower speed, though (1200). I am still confused by the values of a couple of the parameters, but I guess I'll figure them out after I gather more data. @flyingflo: I suppose the decoding part of your Python software would work with the data acquired using this method.

[alesha76]

@silfax I have the Lagomatic CANBUS protocol coming in this form. Standard ID: 0x400 DLC: 8 Data: 0x80 0x00 0x80 0x02 0x30 0x30 0x2C 0x2D Standard ID: 0x400 DLC: 8 Data: 0x80 0x06 0x00 0x00 0x64 0x03 0x80 0x00 Standard ID: 0x400 DLC: 8 Data: 0x80 0x0C 0x20 0x2C 0x36 0x00 0x00 0x00 Standard ID: 0x400 DLC: 8 Data: 0x81 0x00 0x80 0x02 0x30 0x30 0x2C 0x2D Standard ID: 0x400 DLC: 8 Data: 0x81 0x06 0x00 0x00 0x64 0x02 0x80 0x00 Standard ID: 0x400 DLC: 8 Data: 0x81 0x0C 0x20 0x2C 0x36 0x00 0x00 0x00 Standard ID: 0x400 DLC: 8 Data: 0x84 0x00 0x01 0x60 0x3C 0x3A 0x22 0x00 Standard ID: 0x400 DLC: 8 Data: 0x84 0x06 0x80 0x00 0x03 0x00 0x00 0x00 Standard ID: 0x400 DLC: 8 Data: 0x87 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Standard ID: 0x400 DLC: 8 Data: 0x87 0x06 0x09 0x05 0x19 0x16 0x01 0x07 Standard ID: 0x400 DLC: 8 Data: 0x87 0x0C 0x18 0x16 0x01 0x09 0x02 0x04 Standard ID: 0x400 DLC: 8 Data: 0x87 0x12 0x15 0x01 0x07 0x1D 0x15 0x01 Standard ID: 0x400 DLC: 8 Data: 0x87 0x18 0x09 0x02 0x0A 0x14 0x01 0x07 Standard ID: 0x400 DLC: 8 Data: 0x87 0x1E 0x1D 0x14 0x01 0x09 0x02 0x06 Standard ID: 0x400 DLC: 8 Data: 0x87 0x24 0x13 0x01 0x07 0x1E 0x13 0x01 Standard ID: 0x400 DLC: 8 Data: 0x88 0x00 0x35 0x4E 0x2E 0x3C 0xD3 0x08 Standard ID: 0x400 DLC: 8 Data: 0x88 0x06 0x00 0x80 0x00 0xFF 0x00 0x00 Standard ID: 0x400 DLC: 8 Data: 0x88 0x0C 0x0A 0x51 0x65 0x00 0x00 0x00 Standard ID: 0x400 DLC: 8 Data: 0x88 0x12 0x01 0x7D 0x43 0x00 0x00 0x00 Standard ID: 0x400 DLC: 8 Data: 0x88 0x18 0x1E 0x64 0x9C 0x00 0x4E 0x6E Standard ID: 0x400 DLC: 8 Data: 0x88 0x1E 0x00 0x45 0x00 0x01 0x04 0x64 Standard ID: 0x400 DLC: 8 Data: 0x88 0x24 0x00 0x00 0x6E 0x6E 0x6E 0x00 Standard ID: 0x400 DLC: 8 Data: 0x89 0x00 0xFC 0xFC 0x08 0x1B 0x00 0x00 Standard ID: 0x400 DLC: 8 Data: 0x89 0x06 0x03 0x01 0x00 0x00 0x06 0x00 Standard ID: 0x400 DLC: 8 Data: 0x89 0x0C 0x00 0x00 0x00 0x00 0x00 0x00 Standard ID: 0x400 DLC: 8 Data: 0x89 0x12 0x35 0x4E 0x10 0x1E 0x64 0x4E Standard ID: 0x400 DLC: 8 Data: 0x89 0x18 0x1A 0x8D 0x32 0x00 0x00 0x00 Standard ID: 0x400 DLC: 8 Data: 0x80 0x00 0x80 0x02 0x30 0x30 0x2C 0x2D Standard ID: 0x400 DLC: 8 Data: 0x80 0x06 0x00 0x00 0x64 0x03 0x80 0x00 Standard ID: 0x400 DLC: 8 Data: 0x80 0x0C 0x20 0x2C 0x36 0x00 0x00 0x00 Standard ID: 0x400 DLC: 8 Data: 0x81 0x00 0x80 0x02 0x30 0x30 0x2C 0x2D Standard ID: 0x400 DLC: 8 Data: 0x81 0x06 0x00 0x00 0x64 0x03 0x80 0x00 Standard ID: 0x400 DLC: 8 Data: 0x81 0x0C 0x20 0x2C 0x36 0x00 0x00 0x00 Standard ID: 0x400 DLC: 8 Data: 0x84 0x00 0x01 0x60 0x3C 0x3A 0x22 0x00 Standard ID: 0x400 DLC: 8 Data: 0x84 0x06 0x80 0x00 0x03 0x00 0x00 0x00 Standard ID: 0x400 DLC: 8 Data: 0x87 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Standard ID: 0x400 DLC: 8 Data: 0x87 0x06 0x09 0x05 0x19 0x16 0x01 0x07 Standard ID: 0x400 DLC: 8 Data: 0x87 0x0C 0x18 0x16 0x01 0x09 0x02 0x04 Standard ID: 0x400 DLC: 8 Data: 0x87 0x12 0x15 0x01 0x07 0x1D 0x15 0x01 Standard ID: 0x400 DLC: 8 Data: 0x87 0x18 0x09 0x02 0x0A 0x14 0x01 0x07 Standard ID: 0x400 DLC: 8 Data: 0x87 0x1E 0x1D 0x14 0x01 0x09 0x02 0x06 Standard ID: 0x400 DLC: 8 Data: 0x87 0x24 0x13 0x01 0x07 0x1E 0x13 0x01 Standard ID: 0x400 DLC: 8 Data: 0x88 0x00 0x35 0x4E 0x2E 0x3C 0xD4 0xF8 Standard ID: 0x400 DLC: 8 Data: 0x88 0x06 0x00 0x80 0x00 0xFF 0x00 0x00 Standard ID: 0x400 DLC: 8 Data: 0x88 0x0C 0x0A 0x51 0x65 0x00 0x00 0x00 Standard ID: 0x400 DLC: 8 Data: 0x88 0x12 0x01 0x7D 0x43 0x00 0x00 0x00 Standard ID: 0x400 DLC: 8 Data: 0x88 0x18 0x1E 0x64 0x9C 0x00 0x4E 0x6E Standard ID: 0x400 DLC: 8 Data: 0x88 0x1E 0x00 0x45 0x00 0x01 0x04 0x64 Standard ID: 0x400 DLC: 8 Data: 0x88 0x24 0x00 0x00 0x6E 0x6E 0x6E 0x00 Standard ID: 0x400 DLC: 8 Data: 0x89 0x00 0xFC 0xFC 0x08 0x1B 0x00 0x00 Standard ID: 0x400 DLC: 8 Data: 0x89 0x06 0x03 0x01 0x00 0x00 0x06 0x00

[alesha76]

Standard ID: 0x000 DLC: 8 Data: 0x09 0x38 0x00 0x01 0x1E 0x1E 0x00 0x01 Standard ID: 0x000 DLC: 8 Data: 0x09 0x3F 0x02 0x05 0xE1 0x00 0x65 0x65 Standard ID: 0x000 DLC: 8 Data: 0x0A 0x00 0x65 0x11 0x22 0x2A 0x02 0x22 Standard ID: 0x000 DLC: 8 Data: 0x0A 0x07 0x00 0x00 0x05 0x05 0x2D 0x01 Standard ID: 0x000 DLC: 8 Data: 0x0A 0x0E 0x01 0x04 0x4B 0x05 0x4B 0x3C Standard ID: 0x000 DLC: 8 Data: 0x0A 0x15 0x03 0x01 0x05 0x01 0x01 0x05 Standard ID: 0x000 DLC: 8 Data: 0x0A 0x1C 0x0C 0x03 0x65 0x00 0x00 0x65 Standard ID: 0x000 DLC: 8 Data: 0x0A 0x23 0x04 0x0F 0x0B 0x00 0x07 0x3C Standard ID: 0x000 DLC: 8 Data: 0x0A 0x2A 0x28 0x0A 0x0A 0x11 0x65 0x65 Standard ID: 0x000 DLC: 8 Data: 0x0A 0x31 0x65 0x65 0x65 0x00 0x65 0x65 Standard ID: 0x000 DLC: 8 Data: 0x0A 0x38 0x00 0x01 0x1E 0x1E 0x00 0x01 Standard ID: 0x000 DLC: 8 Data: 0x0A 0x3F 0x02 0x05 0xE1 0x00 0x65 0x65 Standard ID: 0x000 DLC: 8 Data: 0x0B 0x00 0xE2 0x65 0x01 0x06 0x65 0x65 Standard ID: 0x000 DLC: 8 Data: 0x0C 0x00 0x65 0x00 0x46 0x01 0x01 0x01 Standard ID: 0x000 DLC: 8 Data: 0x0C 0x07 0x01 0xF8 0x28 0x3C 0x3C 0x01 Standard ID: 0x000 DLC: 8 Data: 0x0C 0x0E 0x02 0x01 0x65 0x01 0x04 0x02 Standard ID: 0x000 DLC: 8 Data: 0x0C 0x15 0x00 0x02 0x00 0x00 0x00 0x01 Standard ID: 0x000 DLC: 8 Data: 0x0C 0x1C 0x00 0x3C 0x19 0x0A 0xFB 0xFB Standard ID: 0x020 DLC: 8 Data: 0x00 0x01 0x08 0x48 0xC0 0x8C 0x40 0x14 Standard ID: 0x000 DLC: 8 Data: 0x0C 0x23 0x41 0x1E 0x00 0x0C 0x02 0x01 Standard ID: 0x000 DLC: 8 Data: 0x0C 0x2A 0x03 0x28 0x17 0x0C 0x3C 0x65 Standard ID: 0x000 DLC: 8 Data: 0x0D 0x00 0x65 0x65 0x65 0x65 0x00 0xFF Standard ID: 0x000 DLC: 8 Data: 0x0D 0x07 0x65 0x65 0x65 0x03 0xFF 0x00 Standard ID: 0x000 DLC: 8 Data: 0x0D 0x0E 0x03 0x01 0x01 0x01 0x06 0x65 Standard ID: 0x000 DLC: 8 Data: 0x0D 0x15 0x00 0x02 0x01 0x65 0x65 0x00 Standard ID: 0x000 DLC: 8 Data: 0x0D 0x1C 0x00 0x3C 0x01 0x01 0x00 0x00 Standard ID: 0x000 DLC: 8 Data: 0x0E 0x00 0x01 0x65 0x65 0x00 0x06 0x64 Standard ID: 0x000 DLC: 8 Data: 0x0E 0x07 0x14 0x14 0x05 0x00 0x15 0x01 Standard ID: 0x000 DLC: 8 Data: 0x0E 0x0E 0x05 0x1E 0x05 0x1E 0x05 0x28 Standard ID: 0x000 DLC: 8 Data: 0x0E 0x15 0x02 0x55 0x1E 0xFF 0x64 0x01 Standard ID: 0x000 DLC: 8 Data: 0x10 0x00 0x01 0x65 0x00 0x4B 0x05 0x0C Standard ID: 0x000 DLC: 8 Data: 0x10 0x07 0x23 0x05 0x0A 0x01 0x1E 0x09 Standard ID: 0x000 DLC: 8 Data: 0x10 0x0E 0x1E 0x0C 0x19 0x32 0x28 0x00 Standard ID: 0x000 DLC: 8 Data: 0x10 0x15 0x0F 0x0F 0x08 0x07 0x07 0x08 Standard ID: 0x000 DLC: 8 Data: 0x10 0x1C 0x0F 0x0F 0x64 0x05 0x01 0x04 Standard ID: 0x000 DLC: 8 Data: 0x10 0x23 0x00 0x32 0x05 0x04 0x1E 0x32 Standard ID: 0x000 DLC: 8 Data: 0x10 0x2A 0x01 0x01 0x32 0x4B 0x08 0x0A Standard ID: 0x000 DLC: 8 Data: 0x10 0x31 0x32 0x32 0x00 0x19 0x0A 0x06 Standard ID: 0x000 DLC: 8 Data: 0x10 0x38 0xD8 0xC4 0x0C 0x0A 0x3D 0x46 Standard ID: 0x000 DLC: 8 Data: 0x10 0x3F 0x01 0x00 0x00 0x11 0x00 0x02 Standard ID: 0x000 DLC: 8 Data: 0x10 0x46 0x00 0x4B 0x1E 0x1E 0x02 0x11 Standard ID: 0x000 DLC: 8 Data: 0x10 0x4D 0x00 0x00 0x00 0x00 0x00 0x00 Standard ID: 0x000 DLC: 8 Data: 0x10 0x54 0x00 0x00 0x00 0x32 0x32 0x05

CAN BUS transmits continuously. What is being removed from BF is an internal protocol and it will be identical to CAN.

[silfax]

For me it fits with the description in the documentation:

0x80=Heizkreis 1=18 Byte 0x81=Heizkreis 2=18 Byte 0x82=Heizkreis 3=18 Byte 0x83=Heizkreis 4=18 Byte 0x84=Warmwasser=12 Byte 0x85=Strategie wandhängend=12 Byte 0x87=Fehlerprotokoll=42 Byte 0x88=bodenstehender Kessel=42 Byte 0x89=Konfiguration=24 Byte 0x8A =Heizkreis 5=18 Byte 0x8B =Heizkreis 6=18 Byte 0x8C =Heizkreis 7=18 Byte 0x8D =Heizkreis 8=18 Byte 0x8E =Heizkreis 9=18 Byte 0x8F=Strategie bodenstehend=30 Byte 0x90=LAP=18 Byte 0x92=wandhängende Kessel 1=60 Byte 0x93=wandhängende Kessel 2=60 Byte 0x94=wandhängende Kessel 3=60 Byte 0x95=wandhängende Kessel 4=60 Byte 0x96=wandhängende Kessel 5=60 Byte 0x97=wandhängende Kessel 6=60 Byte 0x98=wandhängende Kessel 7=60 Byte 0x99=wandhängende Kessel 8=60 Byte 0x9B =Wärmemenge=36 Byte 0x9C =Störmeldemodul=6 Byte 0x9D =Unterstation=6 Byte 0x9E =Solarfunktion=54 Byte

I get data for hot water (0x84), heating circuit 5 (0x8A) which actually corresponds to heating circuit 0 when using the Logamatic 4211, as stated in the documentation, boiler (0x88), configuration (0x89) and error log (0x87).

Everything is decoded nicely, except for the error log, which is WIP and will probably be finished this week.

[alesha76]

This is a transcript of the errors)

[flyingflo]

One detail I still don't know is the command that is sent when you press the "Warmwasser nachladen" (hot water re-heat) special button on the right on the MEC2. Now that you read this bus, can you capture it, @silfax?

[silfax]

Yes, I know what function you are referring to. Well, unfortunately that may not be possible. According to the guy whose instructions I followed:

"The room sensors' replies to the controller are current-based. This signal can be seen as voltage levels less than +10 V on the bus. However, due to the low voltage excursions this signal is not easy to monitor by looking at the bus voltage only."

Or, in German:

"Die Rückmeldungen von den Thermostaten zum Regler werden offenbar als Stromimpulse gesendet, d.h. die 10 V-Versorgung wird stärker belastet, wenn der Thermostat den Arbeitspegel anlegt. Man erkennt dieses Signal als Spannungen kleiner als 10 V am Bus. Durch Beobachten der Spannung läßt es sich aber nicht leicht auswerten, weil der Spannungshub zu klein ist."

Because of this, you don't actually captur what the MEC2 is sending on the bus, his purpose (as well as mine) being mainly to simply monitor the system. Reading what the MEC2 transmits would probably need a different level shifter/adapter. There are some oscilloscope captures on his website as well, if you want to take a look:

https://www.holzleitner.com/el/buderus-monitor/index-de.html

[flyingflo]

Oh! They took quite a big effort to create a 2-wire bus with integrated power supply :smiley:

You will need quite a major hardware upgrade to sniff the back channel and create your own sender. I use the remote control feature a lot, because the logamatic is combined with a heatpump, which the logamatic is unaware of. I'm quite happy with CAN bus in this aspect.

[flyingflo]

It was one of the most important achievements in this project back then, when I figured out how to send config over the bus.

:trophy: :smile:

[silfax]

Well, for me it's not that important, monitoring being the main purpose. The boiler works standalone and I seldom alter its settings. However, it would have been nice to succeed implementing your project and I've not given up on it. I'll give it another spin as soon as I will have enough time. I still find it a more stylish approach than piggy-backing the MEC2 bus. But for the moment I have the info I wanted and I will take some time to see how I can best use this data. Thank you for making this project available and for your support.