Hi Daniel,
Thanks for explaining! Since I don’t have the skills to build that cirquit, I googled and found M-Bus splitters that would allow me to add my own M-Bus master to query the meter. I found two products: Elvaco M-Bus Splitter and STV Electronic MSP-32. But their price tag is quite high…
But at least I know why it didn’t work!
Thanks, Andreas
Hi Andreas,
if there are less than 5 slaves connected, I could assist you, to design some not-so-complicated interface. It should be possible to create this even on a bread-board, using a few standard components and two USB-serial-converters (one for sniffing TX and one for RX).
Regards,
Daniel
Hi Daniel,
That would be great, I have some electronics stuff at home because I wanted to start playing with electronics, but didn’t find the time. There is just one slave on the master, so that should be fine! It would really be great to have some kind of simple and open hardware to read m-bus data this way and it sounds like a fun project to me! Is github the best way to do this? I’m @ajuch on github.
Thanks, Andreas
Hi Andreas,
I will simply post some drawings here. But you are free to create a project on GitHub, pimp my schematics a bit and post it there.
Alternative B is easier (you need to switch the grounding and signal at the shunt resistor compared to A), but it is more susceptible to noise, especially with loose hanging wires (better twist the pair of wires from the shunt). Maybe you could also increase the shunt resistor to 33 Ohms or more, to get higher voltages (e.g. 330 mV@10mA@33 Ohms instead of 100 mV@10mA@10 Ohms).
For Alternative A, the OpAmp needs to be quite fast, low supply-voltage and include the negative rail (GND) on input and output. Not easy to find these days and could be expensive.
Comparators often have an Open-Drain-Output to negative (GND) and need a pull-up to provide a meaningful output. So the LMx93 (293, 393,…) does. The good-old LM393 should do well in this application, is available in PDIP bread-board-friendly packaging and usually dead-cheap (<0.5$). Other comparators with better than 5us rise/fall-time should also do well for 2400 baud or less. Additionally, you can supply it with voltages from 2 to 32V (or up to 38V for some types). Maybe you need to add a 15pF output capacitance to the output of the comparator (at least the datasheet tells to do it).
Depending on your USB-serial converter, you can supply the parts with 3.3 or 5V (re-check the divider ratios, depending on your supply voltage).
But most importantly, the supply of the circuit should be isolated from the stuff connected on M-Bus. Best would be to first test with some laptop running on batteries, not connected with any cables (power, network,…) and supply the circuit from the USB-converter (many provide a 5V output and accept 5V levels on RX, but the 10K pull-ups will protect also 3.3V inputs). Remeber the 24/36V of the M-Bus. USB and serial converter will not love it, when directly feeded into 
If this all works well, you can think about adding opto-couplers or an USB galvanic isolator or other stuff to avoid ground-loops, short circuits and such stuff…
A more sophisticated circuit could adapt to the steady-state/standby current and adjust it’s trip-point accordingly, but this would make things much more complicated and would also not help you to get up and running quickly.
PS: You need to find out the polarity of the M-Bus. M-Bus usually is build in a way, that it does not care about polarity. Adding stuff to also make my circuit polarity-agnostic would add quite some more stuff and complexity.
PPS: The OpAmp has its positive input on the down-side input.
Hope this helps and have some fun
Regards,
Daniel
Hi Daniel,
Thanks a lot! I’ll try to build the Slave → Master circuit, alternative B first and I just ordered the parts. When I have everything, I’ll try to build the circuit!
Br, Andreas
Hi Andreas,
great! Keep me informed, maybe I’ll design the more universal one with a PCB some time and post it here 
Regards,
Daniel
Hi Daniel,
I received the components on wednesday and have spent quite some time figuring out how to connect them. My idea is to extend the M- side from the bus to place it near the raspberry that I want to use for the software side (maybe some simple python program). This way I could keep the distance from the shunt resistor very short (and since M-Bus should work over very long wires, I hope the inequal length of the M- and M+ cables is no problem).
I’ve drawn an image on how I would connect everything but I’m not entirely sure it’s correct.
Could you please have a look at this and tell me if I have any obvious mistakes in it?
Thanks, Andreas
Hi Andreas,
yes, extending the M-Bus wires is the right way to go and it should not influence the M-Bus itself noticeably.
Your schematic does not look accurate. The 15 pF should not connect in series to the output. Instead it should connect between comparator output and ground. It looks like a mixture between my to alternatives.
You should simply connect the resitor devider (fixed + variable) between VCC and Grund and the tap of the variable resistor to the negative input of the comparator. The positive should go to the right pin of your shunt. The left pin of the shunt goes to ground.
Shall I draw a new, clean version with only this single alternative to make it a bit more clear?
Hope my answer does not confuse you too much.
Regrds,
Daniel
Hi Daniel,
Looks I misunderstand your symbols. I really don’t know a lot about electronics. I was already wondering why the 3V3 was connected to M-…
I think I can get it right with your answer now, I don’t want to take too much of your time. If it’s just a 5min sketch for you, I’d really appreciate a sketch, just to confirm I understood it right this time… But it’s not urgent at all, I don’t have a lot of spare time at the moment…
Thanks again, Andreas
OK, here is the correct drawing:
To get also the master->slave communication, you would need an additional USB-serial-converter and the upper part of my previos schematics.
You could use the spare comparator (Pins 5,6,7 = Out2, In2+ & In2-) for that:
Regards,
Daniel
Hi Daniel,
Thanks a lot for the correct drawing! It helped me to finish the circuit on a breadboard. I have a second FT232, but I’ll wait with master’s TX until I get slaves TX working…
I connected the circuit and at first I didn’t get any data. After measuring voltages, I noticed that I connected OUT1 wrong and I just put in RX from the FT232 board without +3v3 supply and no GND just to try. And suddenly the FT232 board started to blink and it seems I can receive data! I’ll rewire it correctly tomorrow and maybe start with the software side. Maybe I can get some measurements already…
Thanks a lot for your help, it’s really amazing what can be done with so simple parts…
Andreas
Hi Andreas,
you are welcome 
Hope you can finish it with master TX also.
Just a note on the unconnected inputs of the second comparator. If you encounter wired behaviour, this comparator could be oscillating.
So wire it for master TX better sooner than later. You don’t need to connect the output, just give the inputs some voltage-difference to work with (specs require between 0…1.3V @3.3V Supply).
Regards,
Daniel
Hi Daniel,
Just came across your discussion.
I would love seeing you to integrate M-Bus for ESPHome!
Actually, that is what I am looking for quite some time.
I have a Sharky 775 energy meter with MBus communication. I see the MBus works - I was able to read some data with a MBus Master.
But I’d really like to use such an " TTL UART serial port zu MBUS Master converter" with an ESP32 to integrate the MBus with ESPHome … but I don’t know where to start.
For some electricity meters, someone did the job already: GitHub - alekslt/HANToMQTT: ESP32/ESP8266 HAN (M-Bus Metering Data) to MQTT
But the solution should be more general. There are many more sensors with MBus available.
Let me know, if you find the time. Maybe, I can help with my little skills.
Best Regards,
Martin
Hi all,
be sure, I’ll come back to this topic, not far in the future. Currently I’m heavily working on my heating system to integrate an air-to-water heat-pump to save some oil until I can start the renovation of my house in 2-3 years. And I will install up to 6 heat meters with M-Bus connectivity. Therefor I have a real need to continue on that topic, as soon as my heating system works as expected. It’s just about 50 meters of pipes and fittings away 
Regards,
Daniel
Hey Daniel,
that sounds like lots of fun. Hope it will work out all well. My MBus is for the solar heating.
BTW: I found this source here: GitHub - DomiStyle/esphome-dlms-meter: ESPHome component to read out DLMS smart meters via M-Bus
And I can get it compile for ESPhome.
Now I’ll try to play around to get a simple temperature/humidity MBus sensor to work.
Difficulty I have is with the decription of the payload from the MBus. How should I know the decoding of the payload…
It would then look like this in yaml:
sensor:
- platform: template
id: mbus_temperature
name: mbus_temperature
unit_of_measurement: "°C"
accuracy_decimals: 1
device_class: "temperature"
state_class: "measurement"
But I will wait for you to join the party!
Martin
Hi Martin,
usually, the M-Bus is quite standardized and manufacturers implement few specific things (with one exception, but on that, later…).
I think, to get a good clue on the M-Bus, you should have a look in here:
It is mostly written for a 3-phase electricity meter, but with a general description like on Documentation – M-Bus, you will never find your way into M-Bus. It’s way to complex to understand all the possibilities…
The most simple implementation of a M-Bus component for ESPhome would be, to have some very basic functions (like primary and secondary address search) for initial configuration and only meant to write to ESPhome log. For the real use of the component, the straight forward way to get it running is to simply read out ALL data (DIF: Global Data Request, p.18) of configured meters (defined by their primary or secondary addresses) and start to match the VIFs, because these are standardized.
The slave in the above document can only be parametrized to send selected sets (not single VIFs) for export (p.19) in a manufacturer specific way. This works with some SND_UD telegram. With REQ_UD2 data request, you will get one (that never occurs ) or multiple telegrams from RSP_UD containing the selected parameter identifier (DIF/E, VIF/E) and values. This global data request could be very lengthy, but to my knowledge, there is no standardized way for selecting parameters easily. And meters will always send their complete set, if not configured.
In a second development iteration, you could provide a way to set the primary address of a slave, designated by its secondary address. This is to shorten the communication.
Third iteration step would be a possibility, to provide some or more initial SND_UD telegrams, to configure the meter, e.g. for higher baud rates, manufacturer specific selection of transferred data,…
Sensors could easily filter the values according to their DIF, DIFE,VIF and VIFE.
OK, that’s all for today.
I should write an introductory blog post on the M-Bus…
All stuff you can find is way to complex to understand in my opinion.
Regards,
Daniel
PS: On your specific question: The code from DLMS meter is very specific to a certain type of meters. I believe it will be not easy to adjust it to your own meter. Maybe my previous post gives you an idea about the problems.
I fully agree 
Hi guys,
your wish is my command
Here is a first draft of my blog post:
It should clarify many things already.
But now it time to watch some news and take some rest
Regards,
Daniel