Support Watermeter (Kamstrup Multical 21)
copystring opened this issue · comments
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:
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
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
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.
Ok, then show a debug log please and we will se what the device sends out
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.
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:
This is the WakeUp sent by this adapter:
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?
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.
@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
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:
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.
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.
Ok. Same settings as above but with SignOn empty: No or too long answer from Serial Device after last request.
Please show a debug log. Thank you
As said: We only send the signon once ... mabe the 30 wakeup chars are then not enough?
Maybe. Changed the 30 to 500.
Here's the log: https://pastebin.com/KUAEiVYf
Please post a DEBUG log ... Silly is not helpful in this case. Thank you
(and increasing 30->500 is most likely also not helpfull .. try 60 or such
Oh. I thought it's the same but more.
Here it is with 60: https://pastebin.com/YTAUzkSX
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
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
... and it is not even sending out \r\n ... 0D 0A ?! ...
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
Other times 0D 0A
So yeah ... 🤷♂️
YOu could try to contact manufactorr and ask for detailed specs :-)
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.
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? 🤷♂️
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?
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.
If it is a different protocol then ioBroker Forum will not help ;-) I need to look into it when I find time
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
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
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
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.
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.
Multical21 uses baudrate 1200. Confirmed with oscilloscope.
@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...
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
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.
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.
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
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?
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.
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.
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.