Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support Watermeter (Kamstrup Multical 21) #333

Open
copystring opened this issue Sep 18, 2022 · 41 comments
Open

Support Watermeter (Kamstrup Multical 21) #333

copystring opened this issue Sep 18, 2022 · 41 comments

Comments

@copystring
Copy link

Hello everyone,

so a while I try to get my water meter in my smart home. The water meter is placed outside in a metal shaft 2 meters deep. Wifi reception is obviously bad but could be worked around with a long cable for the antenna or similar.
The model is a Kamstrup Multical 21.
There are various ways to get to the data of the water meter. My first choice in via WMBUS however this needs an AES-Key which my provider will not hand out to me for privacy reasons.

So I looked for alternatives.
First I tried the pulse adapter
The way this one works is after pressing the button in the pulse adapter every 10 liters a pulse is send which could be used by for example a esp8266 or so to send it off to mqtt.
Problematic is the fact that sometimes a pulse is missed. Maybe by bad wifi signal or so. This is tedious to correct because I'd have to get the water out of its shaft every time to manually sync the current meter value with my smart home.

After a lot of research I found this device: Poweropti Powerfox PA201901
This can be put on my water meter which communicates via the bidirectional IR-LEDs.
I bought this and tried it out. It can actually read the current meter value with those LEDs. Nice!
Looking at the datasheet I found out Powerfox supports SML-Protokoll and IEC1107. IEC1107 is the same as IEC 61107 right? I believe it go renamed.

There is a similar topic here but I don't know how reliable the information is. Assuming the water meter is in fact using IEC1107/IEC 61107 /?!\r\n (in HEX 2F3F210D0A) needs to be send. I bought an IR read write head and connected to an FTDI which is used by ioBroker.smartmeter setup like this:

image

Sadly no data is returned.
I also have a oscilloscope (RIGOL DS1054) hooked up to TX and RX of the IR read write head while it was on powerfox to receivce what powerfox is sending. This is also connect to my PC with pulseview but not sure where to go from there.
How do I use that data?

Yeah I could just use powerfox in the end but that's not cool. I want to directly use the IR read write head on the meter. Also it costs a yearly fee after 2-3 years.

Let me know if I'm on the right track with this and if so how we can get this working.

Thank you

Felix

@Apollon77
Copy link
Owner

Okm,, in fact usage questions are hetter discussed in Forum then on GitHub, bit some infos:

1.) the signon sewuence you told is the default, so remove the one you entered because so it will send wrong stuff
2.) You said the protocol is SML, so why you choose D0 as protocol? select SML please :-)
3.) Remove the hard coded baudrate ... or where you got it from? Because SML by default uses 9600baud ..... SO if enter that
4.) 500 D0 wakecharts is a bit too much ... and agin it is SML ... remove also.

Ideally remove the instance and create new one to get back defaults. Then only change protol to SML and bare minimum changes. Thenset the instace to debug loglevel and show the log - there you see whats received

@copystring
Copy link
Author

I'm sure it's not SML. The poweropti supports SML and IEC1107.
The baudrate is the one pulseview guessed when analyzing the sent data. I also tried 9600 before.
The 500 wakes are roughly what the poweropti it sending after starting it up.

@Apollon77
Copy link
Owner

Ok, then show a debug log please and we will se what the device sends out

@copystring
Copy link
Author

That's the thing. There is nothing coming back with the setting I chose.
No or too long answer from Serial Device after last request.

@copystring
Copy link
Author

OK. I guess I made a mistake. I changed the SignOn message from ?!\r\n to ?. Still no luck

Check my oscilloscope again and compared the WakeUp message.
This is the WakeUp Message sent by powerfox:
DS1Z_QuickPrint4

This is the WakeUp sent by this adapter:
DS1Z_QuickPrint1

Looking closely you can see the baud rate must be wrong.

Maybe the signal captured by the oscilloscope is inverted because what powerfox is sending (TX) is RX on the read write head?
What this adapter is sending would then be TX on the read write head.
Does that make sense?

@evlo
Copy link

evlo commented Sep 24, 2022

NOT THE ANSWER, BUT SUGGESTION YOU MIGHT LOOK INTO
some meters I interacted with need wakeup signal at 300baud and correct parity etc.

for IEC62056-21 meters this usually works
baud_rate: 300
data_bits: 7
stop_bits: 1
parity: EVEN

IEC 61107 I dunno, sorry for not having an answer for you, but I think it might worth a try

RX/TX you can try swapping, also first thing to try, if you did not tried yet, is to try interface with the mirror or even white piece of paper, if it reads back what it sends.

Again, this is not an answer just some suggestions, that will hopefully be helpful as i struggled getting everything working with similar interface and similar meters for the first time.

Worst case you can use this https://github.com/jomjol/AI-on-the-edge-device . But if it is in the shaft in the ground it will get foggy and might hard to get proper reading. At leas tmine

Reading bit more
This first edition IEC 62056-21 cancels and replaces the second edition of IEC 61107 published in 1996 and constitutes a technical revision.

@Apollon77
Copy link
Owner

@copystring Regarding the sign on message ... I told you at the beginningnthat the string is wrong ... If you just now changed it then please re-read anything I posted

@copystring
Copy link
Author

OK. I'm sorry. I did read what you wrote. I wasn't sure where to start and if I understood your comment(s) correctly.

Seems like I'm getting closer.
Deleted all data points. Made a new instance. Checked the baud rate again. It is actually 300 not 1200.
This is my setup now:
image

With this the messages look identical on the oscilloscope to the ones sent by powerfox. Powerfox is sending exactly 30 times 00 as WakeUp and after that 3 times 2F3F210D0A as SignOn.
2F3F210D0A = /?!\r\n

So I set the SignOn message to ?!\r\n. I also tried ? and ?!
But no data is returned with any of those.

@Apollon77
Copy link
Owner

Please leave the Signon message alone and simply leave empty ... then it is exactly sent correct because you just need the default, but just once.

@copystring
Copy link
Author

Ok. Same settings as above but with SignOn empty: No or too long answer from Serial Device after last request.

@Apollon77
Copy link
Owner

Please show a debug log. Thank you

@Apollon77
Copy link
Owner

As said: We only send the signon once ... mabe the 30 wakeup chars are then not enough?

@copystring
Copy link
Author

Maybe. Changed the 30 to 500.
Here's the log: https://pastebin.com/KUAEiVYf

@Apollon77
Copy link
Owner

Please post a DEBUG log ... Silly is not helpful in this case. Thank you

@Apollon77
Copy link
Owner

(and increasing 30->500 is most likely also not helpfull .. try 60 or such

@copystring
Copy link
Author

Oh. I thought it's the same but more.
Here it is with 60: https://pastebin.com/YTAUzkSX

@Apollon77
Copy link
Owner

In fact the extended Log from the library was only acivated by debug log and not sentry .. so check log and you see what is sent out, So signon is as expected ( yes the linebreak is sent too), but the device do not respond.

Hhmmm ... when the infos on https://wiki.volkszaehler.org/hardware/channels/meters/warming/kamstrup_multical_401 are correct then this is a mega szrange device ( if the 21 is same as 401 described there, but maybe worth a try).

Try setting the serial connection parameter s to 7E1 or 7E2... But even then it is NOT D0 as protocol!!

Or it is a different device then documentted there

@copystring
Copy link
Author

Yes line break is sent out correctly.
I've read about the 401 a lot but this is different than the 21. I tried to use that idea before. Didn't work.

7E1 and 7E2 made no difference.
I'm confident that powerfox is sending out more than just ?! with the line breaks.
Checking serial communication shows 1E and 51 sent out as hex value after ?!

Check this out sent by powerfox: https://pastebin.com/jq83RDEt

@Apollon77
Copy link
Owner

... and it is not even sending out \r\n ... 0D 0A ?! ...

@copystring
Copy link
Author

Yeah.. well it seems like the software or serial port does not really see it. My scope does see more though.
Sometimes it sends only 0D
image

Other times 0D 0A
image

So yeah ... 🤷‍♂️

@Apollon77
Copy link
Owner

YOu could try to contact manufactorr and ask for detailed specs :-)

@copystring
Copy link
Author

Hehe yeah I had that same idea. I guess I might actually do that but it would not surprise me if I'll get no answer.

@copystring
Copy link
Author

Okay. Well I did not get in touch with the manufacturer seeing it's a 5€ fee a year to use their service I doubt they'd help.

Anyway. I managed to make the water meter to give a response by sending this: 80 3F 01 05 8A 0D
This is the response: 40 3F 01 12 01 10 01 92 73 0D

Looks like something to me. Now what do I do with that? 🤷‍♂️

@copystring
Copy link
Author

Right. So I went and attached the read write head to the powerfox and waited for it to send 80 3F 01 05 8A 0D where I responded via the read write head with 40 3F 01 12 01 10 01 92 73 0D
Powerfox then seemed to recognized this as being connected to the water meter while it actually was connected to the read write head.
Powerfox then sends 80 3F 10 01 00 44 4D C0 0D and the water meter responds with 40 3F 10 00 44 28 04 43 00 00 21 5D A3 90 0D
After that powerfox sends this 80 3F 02 35 E9 00 00 0D and water meter responds with 40 3F 02 04 6F C5 98 38 B7 0D

Here's the log:

Data sent: 80 3F 01 05 8A 0D 
Data received: 40 3F 01 12 01 10 01 92 73 0D 
Data sent: 80 3F 10 01 00 44 4D C0 0D 
Data received: 40 3F 10 00 44 28 04 43 00 00 21 5D A3 90 0D 
Data sent: 80 3F 02 35 E9 00 00 0D 
Data received: 40 3F 02 04 6F C5 98 38 B7 0D 

Can we do something with that?

@copystring
Copy link
Author

So this must be the IEC1107 protocol with a baud rate of 1200.
I found this project https://github.com/ErikErnst/kamstrup on the internet and played around with it for a bit.
Using it I was able to read out the current date and time of the water meter.

You said this'd be better to discuss on the iobroker forum right? Maybe I should take it there.

@Apollon77
Copy link
Owner

If it is a different protocol then ioBroker Forum will not help ;-) I need to look into it when I find time

@Aikawa24
Copy link

Aikawa24 commented Oct 8, 2022

hi copystring,

ive the same Multical 21 and try to get it read with esphome and homeassistant,

I tried the multical401 files that sends "175,163,177" in multical401.h file and "\xAF\xA3\xB1" in the logfile over the optic head.

[01:39:36][D][multical:168]: ERR(TIMEOUT): 1.722248
[01:39:36][D][text_sensor:067]: 'Multical Last Status': Sending state 'ERR(TIMEOUT)'
[01:39:37][D][uart_debug:158]: >>> "\xAF\xA3\xB1"

can you post your config where you get the time and date from the meter ?

thx

@copystring
Copy link
Author

copystring commented Oct 9, 2022

You can send 80 3F 10 01 03 EA 4C B7 0D to get the current time for example. However this data still needs to be decoded.
You sent AF A3 B1. Multical 21 can't work with that. It expects something that begins with 80 3F

hi copystring,

ive the same Multical 21 and try to get it read with esphome and homeassistant,

I tried the multical401 files that sends "175,163,177" in multical401.h file and "\xAF\xA3\xB1" in the logfile over the optic head.

[01:39:36][D][multical:168]: ERR(TIMEOUT): 1.722248 [01:39:36][D][text_sensor:067]: 'Multical Last Status': Sending state 'ERR(TIMEOUT)' [01:39:37][D][uart_debug:158]: >>> "\xAF\xA3\xB1"

can you post your config where you get the time and date from the meter ?

thx

@Aikawa24
Copy link

Aikawa24 commented Oct 9, 2022

thank you,

if I replace the byte sendmsg1[] = { 175,163,177 }; with byte sendmsg1[] = { 128,63,16 }; which should be hex 80 3F 10
I get only [19:02:03][D][uart_debug:158]: >>> "\x80?\x10" as result

@bagges
Copy link

bagges commented Nov 9, 2022

thank you,

if I replace the byte sendmsg1[] = { 175,163,177 }; with byte sendmsg1[] = { 128,63,16 }; which should be hex 80 3F 10 I get only [19:02:03][D][uart_debug:158]: >>> "\x80?\x10" as result

What connection settings did you use? I tried with 1200 and 300 7E1 and 8N1.

@onkelbeh
Copy link

onkelbeh commented Nov 10, 2022

As I have read somewhere, the meter uses two different speeds for send/receive. The kamstrup meter might use a reed relay to shutdown their transmitter if there is no magnets detected in the reading eye

As an alternative if a modbus is present: talked to a Kamstrup salesman (in Augsburg) yesterday, they are selling Wmodbus receivers, already paired to your device, for around 100€ plus a surcharge for quantities below minimum. You need to tell them the serial of your meter and the designated modbus id. Multical 21 modbus protocol is well documented. It delivers 2 temperatures, some alarms and the counters. My local water supplier offered to order for me with their next bigger order to avoid the extra charge.

@copystring
Copy link
Author

Multical21 uses baudrate 1200. Confirmed with oscilloscope.

@Bascht74
Copy link

@onkelbeh Hi, I am interested in that solution, because I have modbus working already. Any news about your order by the local water supplier? Do you have a name or order number?
Thx for any hints.
The devices are great for the water companies but not for the end users...

@onkelbeh
Copy link

No, did not continue yet. In fact, they try to make me believe they are stupid (as I asked for the Modbus key), and I dont want to honor that. Heard about other suppliers giving out the Wmodbus key to end users. I got the pins of the power meters from the same company, from an other (very friendly) department.

Currently I try to read from the IR interface (https://github.com/onkelbeh/kamstrup/blob/master/Software%20eksempler/kamstrup_multical402/kamstrup_multical402.ino), will cost me a bit of playing to get the code packed into ESPHome.

The guy from Kamstrup I talked with was Jeffrey Shirley +49 821 29722710

@stale
Copy link

stale bot commented Mar 18, 2023

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs within the next 7 days. Please check if the issue is still relevant in the most current version of the adapter and tell us. Also check that all relevant details, logs and reproduction steps are included and update them if needed. Thank you for your contributions.
Dieses Problem wurde automatisch als veraltet markiert, da es in letzter Zeit keine Aktivitäten gab. Es wird geschlossen, wenn nicht innerhalb der nächsten 7 Tage weitere Aktivitäten stattfinden. Bitte überprüft, ob das Problem auch in der aktuellsten Version des Adapters noch relevant ist, und teilt uns dies mit. Überprüft auch, ob alle relevanten Details, Logs und Reproduktionsschritte enthalten sind bzw. aktualisiert diese. Vielen Dank für Eure Unterstützung.

@stale stale bot added the wontfix label Mar 18, 2023
@copystring
Copy link
Author

copystring commented Mar 31, 2023

I digged a bit further and found this:
Sending 803f100100444dc00d returns 403F1000442804430000215DA390
Take 0000215D and convert to decimal (8541). Divide it by 1000, and you get the correct volume of 8.541 in my case.

@stale stale bot removed the wontfix label Mar 31, 2023
@copystring
Copy link
Author

Sending 803f100100444dc00d can be split like this:
| start byte | destination address | CID | requested var | CRC | end byte |
| 80 | 3f10 | 01 | 0044 | 4dc0 | 0d |

on the receiving side:
| start byte | destination address | requested var | don't know what this is | data | CRC | end byte |
| 40 | 3F10 | 0044 | 280443 | 0000215D | A390 | 0d |

where 0044 stands for the current meter value

function crc16xmodem(data) {
  let crc = 0x0000;

  for (let i = 0; i < data.length; i++) {
    crc = crc ^ (data[i] << 8);
    for (let j = 0; j < 8; j++) {
      if ((crc & 0x8000) !== 0) {
        crc = (crc << 1) ^ 0x1021;
      } else {
        crc = crc << 1;
      }
    }
  }

  crc = crc & 0xffff;

  return crc;
}

const data = Buffer.from('3F10010044', 'hex');
const checksum = crc16xmodem(data);
console.log(checksum.toString(16));

can be used to calculate the correct checksum

@mdrmdrmdr
Copy link

Just posted a readout success here.

Anybody here in this discussion who has a solution for "stop responding" issue discussed in the above linked thread?

@stale
Copy link

stale bot commented Aug 12, 2023

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs within the next 7 days. Please check if the issue is still relevant in the most current version of the adapter and tell us. Also check that all relevant details, logs and reproduction steps are included and update them if needed. Thank you for your contributions.
Dieses Problem wurde automatisch als veraltet markiert, da es in letzter Zeit keine Aktivitäten gab. Es wird geschlossen, wenn nicht innerhalb der nächsten 7 Tage weitere Aktivitäten stattfinden. Bitte überprüft, ob das Problem auch in der aktuellsten Version des Adapters noch relevant ist, und teilt uns dies mit. Überprüft auch, ob alle relevanten Details, Logs und Reproduktionsschritte enthalten sind bzw. aktualisiert diese. Vielen Dank für Eure Unterstützung.

@stale stale bot added the wontfix label Aug 12, 2023
@stale
Copy link

stale bot commented Sep 17, 2023

This issue has been automatically closed because of inactivity. Please open a new issue if still relevant and make sure to include all relevant details, logs and reproduction steps. Thank you for your contributions.
Dieses Problem wurde aufgrund von Inaktivität automatisch geschlossen. Bitte öffnet ein neues Issue, falls dies noch relevant ist und stellt sicher das alle relevanten Details, Logs und Reproduktionsschritte enthalten sind. Vielen Dank für Eure Unterstützung.

@stale stale bot closed this as completed Sep 17, 2023
@Apollon77 Apollon77 removed the wontfix label Sep 17, 2023
@Apollon77 Apollon77 reopened this Sep 17, 2023
Copy link

stale bot commented Mar 17, 2024

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs within the next 7 days. Please check if the issue is still relevant in the most current version of the adapter and tell us. Also check that all relevant details, logs and reproduction steps are included and update them if needed. Thank you for your contributions.
Dieses Problem wurde automatisch als veraltet markiert, da es in letzter Zeit keine Aktivitäten gab. Es wird geschlossen, wenn nicht innerhalb der nächsten 7 Tage weitere Aktivitäten stattfinden. Bitte überprüft, ob das Problem auch in der aktuellsten Version des Adapters noch relevant ist, und teilt uns dies mit. Überprüft auch, ob alle relevanten Details, Logs und Reproduktionsschritte enthalten sind bzw. aktualisiert diese. Vielen Dank für Eure Unterstützung.

@stale stale bot added the wontfix label Mar 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

8 participants