Gather data from Kamstrup 403 using cable (City grid)

Energy
,
#1

Hi,

I’m trying to collect data of our heat usage. We have city grid (fjärrvärme) at home, and a Kamstrup Multical 403 device.

I’ve found an integration for this device in HACS, but it requires an optical eye. Our heat provider was kind enough to plug in a cable to the Kamstrup meter, stating that it’s working just as the pulses from the IR, which the optical eye reads.

I’ve also found forum posts about the reader and mbus, but I guess that this pulse cable is not mbus (?).

IMG_20230131_092056
IMG_20230131_0920561800×4000 384 KB

Now, I have no idea how to go from here. I have an esp not in use, I have serial to USB devices laying around. I guess they would be possible to use in some way, but I don’t know how to connect them.

In a Swedish forum I asked the same question, and got a answer, though as stated as a question, that it would work just like P1/Han-ports on electric meters.

Sure enough, but how would I start? From my understanding the meter need an electric current to start sending pulses back. Around 5V. Then I have to connect the other cable to something that reads the pulse, and gets that into home assistant.

Any ideas would be helpful.

I do also have an Pi3 and a zero laying around if that would be helpful. The serial to USB is a PL2303 and some other like device.

See attachment for a documentation of the meter, I’ve got. Unsure about what data to go by.

#2

Maybe amsleser.no
Ask the developer for specific questions.

#3

You mean that amsleser.no is the creator of the reader module and hence knows about how to get the data?

#4

Yes.
The maker of the Amsleser HAN module has developed the module based on an ESP device to get the data into HA.
I can not find his report on his process, but he has learnt a lot about how to read out the Kamstrup meters.

#5

I see. I’ll give it a go. Thank you.

Also, if I understand you correctly, it is indeed the same as reading a HAN port? So I could try to connect the two wires I have to the pins on an esp, and set it up in esphome as a pulse counter, just to start?

#6

The amsleser HAN module is an ESP board.
The HAN module can report in different ways and it can be encrypted, but your provider should hand out that information.

The big deal with the amsleser HAN module is that it can work with the little power that comes from the meter, but if you have a power socket close by, then you already solved one big hurdle. :slight_smile:

#7

Still trying to figure this one out.

I have set up the following in my esphome YAML

uart:
  id: uart_bus
  rx_pin: 
    number: RX
    #inverted: true
    mode:
      input: true
      pullup: true
  rx_buffer_size: 4096
  baud_rate: 1200
  data_bits: 8
  parity: NONE
  stop_bits: 1

I have connected the ESP to the following:
5V to VIN and RX on the ESP and to one of the cables on the multical meter.
G to - and the other cable on the multical meter.

#8

Still on it.

I’m still learning this stuff but I found that the Multical 403 might use a transistor to do a short to ground as pulse.

I figured this meant that I had the connections all wrong. So now I have the following connection hooked up.

  1. Positive 5V from power adapter to one of the pulse cables and VIN on the esp8266.
  2. Negative from the power adapter to ground on esp8266.
  3. The other pulse cable to RX on the esp8266.

Then I thought this might result in me having to add an invert in my esphome yml.

I also added a simple pulse counter sensor in my yml config.

While having the RX pin inverted I do have some kind of pulse found, shown in logs. It doesn’t change, though. Leaving inverted false I get no pulse.

Hence, I guess I’m getting somewhere.

Also I’m using code for a Multical 402, though used for a optical head reader. The serial codes ought to be the same, however. (Right…?)

#9

On the road again.
I added the debug to UART and now I have output. But it is hex, not in ASCII.

#10

If the value starts with 0x then try do add | int(base=16) in the end.
If it does not start with 0x then concatenate that onto it.

#11

Here is a the output I’m getting. By the looks of it, it isn’t the same as I thought that I would get, as other have from Multical units.

Maybe a wiring issue.

06:35:17][D][uart_debug:114]: >>> 80:3F:10:01:00:3C:B2:5F:0D:80:3F:10:01:00:44:4D:C0:0D:80:3F:10:01:00:56:7F:B3:0D:80:3F:10:01:00:57:6F:92:0D:80:3F:10:01:00:59:8E:5C:0D:80:3F:10:01:00:50:1F:75:0D:80:3F:10:01:00:4A:AC:0E:0D
#12

Added some more debugging functions from the esphome doc, as adding a \n delimiter and here is the output. Looking more like what I thought it would.

07:10:29][D][uart_debug:158]: >>> "\x80?\x10\x01\x00<\xB2_\r\x80?\x10\x01\x00DM\xC0\r\x80?\x10\x01\x00V\xB3\r\x80?\x10\x01\x00Wo\x92\r\x80?\x10\x01\x00Y\x8E\\\r\x80?\x10\x01\x00P\x1Fu\r\x80?\x10\x01\x00J\xAC\x0E\r"
#13

I changed the direction of UART Debug FROM BOTH to RX, and now I have nothing in the logs. I guess they means that the previous hex was actually from the esp. Giving up and getting an optical head instead.