[REQUEST] Water flow metering reading of IEC 62056-21 protocol smart water meters via photodiode/infrared optical eye reader header?

[Hedda]

Describe the problem you have/What new integration you would like

Like to get water flow metering from smart water meters with IR eye via hardware similar to Home Assistant Glow or SlimmeLezer.

Optical photodiode/infrared read and write header hardware for IEC 62056-21 protocol (formerly IEC 61107 / IEC 1107) like these:

https://www.mysensors.org/build/ir

http://jheyman.github.io/blog/pages/WirelessWaterMeter/

A hackerspace group in Denmark is selling these IR/photodiode optical reading heads for about $14 US (Google translate as test written in Danish) and they wrote a note that using magnets is required as the IR port transmitter / reader eye does not activate unless it sense a magnet:

https://wiki.hal9k.dk/projects/kamstrup

https://github.com/Hal9k-dk/kamstrup

I believe that a such IR reader adapter could be used with newer Kamstrup water meters with IR optical heads common in Europe.

Specifically, I myself live in Sweden where I believe that the Kamstrup MULTICA 21 / Kamstrup flowIQ 210x ultrasonic water meter is the most common model installed by the municipality's utility companies (e.i. local government agencies) in normal private residential houses here in Scandinavia (Sweden, Norway, Denmark, Finland, and Island) to track water usage for their service fees.

https://www.kamstrup.com/en-en/water-solutions/smart-water-meters

https://www.kamstrup.com/en-en/water-solutions/smart-water-meters/multical-21

They currently also have Kamstrup flowIQ 2200 "advanced model with acoustic leak detection":

and Kamstrup flowIQ 3100 "Commercial and industrial" model

https://www.kamstrup.com/en-en/water-solutions/smart-water-meters/flowiq-2200

https://www.kamstrup.com/en-en/water-solutions/smart-water-meters/flowiq-3100

Please describe your use case for this integration and alternatives you've tried:

I believe many new water meters offer such two-way bidirectional infrared port (IR receiver and sender header) for communication?

https://www.mysensors.org/build/ir

http://jheyman.github.io/blog/pages/WirelessWaterMeter/

Kamstrup seems to only provide some technical documentation about all their products here but nothing about their protocols:

https://products.kamstrup.com/index.php

Kamstrup apparently calls their DLMS implementation for Kamstrup Meter Protocol (KMP) it has been reverse-engineered here:

https://github.com/bsdphk/PyDLMS

https://github.com/RuntimeError123/hass-mc66c

https://github.com/KenanV/KamstrupMultical66

https://github.com/Hal9k-dk/kamstrup/tree/master/Software%20eksempler/kamstrup_multical402

https://github.com/Hal9k-dk/kamstrup/tree/master/Software%20eksempler/kamstrup_powermeter

https://github.com/bsdphk/PyKamstrup

https://frack.nl/wiki/Stadsverwarming

https://forum.mysensors.org/topic/3525/district-heating-city-heating-stadsverwarming-mysensor-ir-sender-receiver/

https://www.domoticz.com/forum/viewtopic.php?t=11333

As I understand most of those optical probes should work with optical infrared waves be compliant with the international standard IEC 62056-21 (formerly IEC 61107 / IEC 1107) or ANSI C12.18 communications protocols for energy metering for reading utility meters?

https://github.com/pwitab/iec62056-21

https://en.wikipedia.org/wiki/IEC_62056

https://en.wikipedia.org/wiki/Smart_meter#Protocols

Kamstrup official (and expensive) optical read-out head tools are called 6699-099 (USB) and 699-102 (9F D-sub plug serial)

https://www.termonet.rs/pdf/Kamstrup/Optical%20Read-out%20(IR)%20Head%20-%20Data%20Sheet%20-%20English.pdf

Additional context

FYI, most of the older and newer Kamstrup electricity meters look to feature a similar or same type of bi-directional optical header, so the hardware could probably be repurposed for other meters as well

PS: Off-topic but FYI; some if not all of these models of Kamstrup water meters can also be read remotely via Sigfox network RF (Radio Frequency) but that communication traffic is most of the time encrypted, at least if the water meter itself is owned and operated by a utility company or a service provider.

https://www.kamstrup.com/en-en/water-solutions/water-meter-reading

https://www.kamstrup.com/en-en/water-solutions/water-meter-reading/usb-meter-reader

If the case is that the RF radio communication is not encrypted then there look to be projects that can work with that:

https://github.com/adams-okode/kamstrup-integration

https://github.com/weetmuts/wmbusmeters

https://github.com/tobiasrask/wmbus-client

[Hedda]

This might be related the the request for SML (Smart Message Language) protocol for reading smartmeter?

https://github.com/esphome/feature-requests/issues/1041

There is a lot collected about workings of SML (a.k.a. "D0 interface") smartmeters with IR two-way here:

https://github.com/volkszaehler/libsml

https://www.msxfaq.de/sonst/bastelbude/smartmeter_d0_sml.htm

[ajvdw]

Have a look at my solution for reading pulse from a sensus620 watermeter. With minor adjustments you can use the same hardware solution....

[Hedda]

@ajvdw These mentioned Kamstrup MULTICA 21 / Kamstrup flowIQ meters don't generate a pulse that represents a metering value.

IR port on these Kamstrup MULTICA 21 / Kamstrup flowIQ communicate via a bi-directional protocol over that IR port (serial-based?).

You can not compare these to for example Kamstrup electricity meters (like their OMNIPOWER meters) which have both a pulse diod where the pulses can just be counted as well as the more complex IR port for their bi-directional protocol similar to MULTICA/flowIQ:

See example this project about building IR sender and receiver hardware to both read and write https://wiki.hal9k.dk/projects/kamstrup

[ajvdw]

It's not about the pulse. The hardware that I have designed can easily be adjusted to communicate via IR. It already contains an IR sender and receiver. You only have to connect the IR sender to a datapin in order to send data to the Kamstrup. Receiving is already possible. Then you can use softserial to implement the protocol.

Op ma 25 okt. 2021 om 15:19 schreef Hedda @.***>:

@ajvdw https://github.com/ajvdw These mentioned Kamstrup MULTICA 21 / Kamstrup flowIQ meters don't generate a pulse that represents a metering value.

IR port on these Kamstrup MULTICA 21 / Kamstrup flowIQ communicate via a bi-directional protocol over that IR port (serial-based?).

You can not compare these to for example Kamstrup electricity meters (like their OMNIPOWER meters) which have both a pulse diod where the pulses can just be counted as well as the more complex IR port for their bi-directional protocol similar to MULTICA/flowIQ:

[image: image] https://user-images.githubusercontent.com/6320001/138702295-e57ef8a1-d42b-4794-93eb-f4719de0433d.png

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/esphome/feature-requests/issues/1402#issuecomment-950921427, or unsubscribe https://github.com/notifications/unsubscribe-auth/AET5LMIIVOXSZFQDOE2XXWLUIVKMLANCNFSM5DULRVRA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

-- Met vriendelijke groeten,

Arie Johan van de Werken

[coltju]

Check out https://github.com/golles/Home-Assistant-Sensor-MC66C

Im using this for my block heating sensor, which uses the same tech.

[evlo]

Hi, i'm looking at projects regarding this, either esphome (preferably)

OP did nice summary of the things I also found.

What i understand that IEC 62056-21 is quite widely used in this environment, and sometimes called "S0" (probably something from DIN). I even seems basically UART RS485, just trough optical IR diode(s). BTW I remember ages ago IR was used by laptops and cellphones to transfer data.

I think not a lot people know about this and all the projects I found so far about this are quite old/cumbersome or me or at least quite hard to follow.

So I was wondering if i understand it correctly that all need is this https://www.aliexpress.com/item/33005112599.html - connect it using "dupont" cables to nodemcu32 ana i should be able to read the data if speed set to 9600 baud or slower?

https://onemeter.com/cs/specifications/ found this, not esp, but maybe they just convert ir uart to bt uart? https://www.fiedler.company/sites/default/files/dokumenty/cenik_2022_v104b.pdf here they sell 3d printed assembled optical diodes with correct IEC 62056-21 4.3.2 magnetic ring etc. https://www.fiedler.company/en/products/smart-metering-remote-meter-readings/sensors-and-transducers-meters/elm1-converter-electric (suspiciously simillar to https://wiki.hal9k.dk/projects/kamstrup solution ...)

EDIT: found this https://www.aliexpress.com/item/1005003509520122.html but it is USB

this one is RS232 https://www.aliexpress.com/item/1005003328350869.html

[evlo]

I think the main issue is sending /?!\r\n / HEX: 2F3F210D0A to poll the meter, otherwise maybe the default SML component might work.

[evlo]

Most likely what my meter spits out is not actually SML, but called IEC62056-21 or sometimes d0 - i think it goes like d0 is the port, IEC62056-21 is the definition of the IR communication, SML is the "extended" protocol and OBIS codes are what each code mean, so even though meter uses IEC62056-21, d0 and OBIS it is most likely not SML, but just IEC62056-21 compliant (which contains basic protocol, but not exactly SML - sml seems to me that it might be IEC62056-21 for multiple meters on the same bus)

This is used by more meters then just water, very similar to SML, but i think separate component is need for easiest implementation. What I wrote in my previous post about using SML component is not true

example:

[jakobschou]

Hopefully somebody could figure out to get some cheap optical probe like this to work: https://a.aliexpress.com/_mK4qGxM so we dont need to solder something ourselves.

It seems that it is possible to do with other Kamstrup meters: https://github.com/golles/ha-kamstrup_403 (Somebody is using https://a.aliexpress.com/_mPY7OYe and getting it to work, though there needs to be attached magnet aswell https://a.aliexpress.com/_mOYY7d4 to get the IR sensors working on the Kamstrup meter)

Though this setup is using pykamstrup (https://github.com/golles/ha-kamstrup_403/tree/main/custom_components/kamstrup_403) which I dont know if it is the right/same protocol for water meters with IEC62056-21, but maybe it could be changed to pyDLMS (https://github.com/bsdphk/PyDLMS). Here is also some code for the old IEC1107 protocol which maybe could be useful, since the original Kamstrup Optical read-out head seems to be only compliant with this protocol...

Hopefully somebody could fork kamstrup_403 and make it work with Kamstrup Multical 21/FlowIQ 2200 - I just dont have the knowledge to do so.

[evlo]

maybe take a look at

• https://github.com/evlo/esphome_ZPA-ZE312
• https://github.com/jplitza/esphome_components

using pretty much same thing

[cfeenstra1024]

If this meter uses the 'Kamstrup Meter Protocol' (KMP) we might be able to use the Kamstrup Multical40x component for ESPHome I've created recently.

If you have the hardware to connect an ESP to the optical interface, I can create a version for ESPHome that can be used to request available parameters. You can then test with your meter. If that works, I can extend the ESPHome component functionality.

I don't have this meter myself, but I do have the Kamstrup Multical 403 (district heating meter) which works well with the created component in ESPHome. I noticed that both meters mention a 'METERTOOL HCM' that can be used with the optical interface in their data sheets. This makes me think they might use the same protocol.

Some info about the component:

• ESPHome component for Kamstrup multical 40x
• Electronics and housing I've created for use with the Multical 40x
• Documentation

[onkelbeh]

I just printed an adapter to hold an IR adapter on the meter, I am going to give it a try soon.

[glance-]

I can report that I've had success talking to a flow IQ 2200 using https://github.com/ErikErnst/kamstrup and 1200 baud.

I haven't found which variables the water meter uses yet, but I have read the time / date and serial number from the meter using a ir eye.

[jakobschou]

I can report that I've had success talking to a flow IQ 2200 using https://github.com/ErikErnst/kamstrup and 1200 baud.

I haven't found which variables the water meter uses yet, but I have read the time / date and serial number from the meter using a ir eye.

What IR interface did you use?

[glance-]

Some random one from flee-bay a couple of years back. The only issue I've found is that the physical form factor of flow IQ 2200 isn't the "standard" one so i had to do some tail then error and when it finally worked apply some tape to keep the ir eye on place. "Normal" devices have a embedded metal plate and some registring features to keep the ir eye in the right place.

[copystring]

You can send 803f100100444dc00d which the meter responds for example with 403F1000442804430000215DA390 In my case the meter has a volume of 8.541m³ which is 215D. To get this number, take 0000215D and convert to decimal (8541). Divide it by 1000, and you get the correct volume of 8.541

[copystring]

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

[aquaticus]

Hi All,

I created a component for IEC62056-21 meters. It can exchange data with utility meters. Mostly for electricity but also water, thermal and other meters.

It supports both bidirectional and unidirectional communication.

• bidirectional - you need optical interface with IR diode and phototransistor that can send and receive data. This is for modes A,B, and C.
• unidirectional - only IR phototransistor is required. This is for mode D - meter periodically sends data to the interface.

The component does not support binary encoded data (HDLC)..

Hardware required: Optical interface connected to serial port.

IEC 62056-21 term is used for multiple protocols (with the same hardware layer but different data encoding). The component supports meters that provides ASCII encoded data, something like that:

1-0:15.8.1(00000009999.567*kWh)
1-0:15.8.2(00000000000.000*kWh)
1-0:15.8.3(00000000000.000*kWh)
1-0:15.8.4(00000000000.000*kWh)

Detailed description of the component: https://aquaticus.info/iec62056.html

PR to ESPHome: https://github.com/esphome/esphome/pull/4388

[copystring]

Hi @aquaticus,

does this support only obis codes?

[aquaticus]

@copystring Not sure I understand the question. The component can only interpret information sent as OBIS codes.

[copystring]

Correct me if I'm wrong, but the way I see it, the Multical 21 does not use OBIS codes.

[aquaticus]

Just realized Multical 21 probably does not use IEC 62056-21 protocol. I was a bit mislead by the log in one of the comments. In that case the component cannot be used with Multical. And yeah, it seems Multical uses different data model than OBIS.

[glance-]

where 0044 stands for the current meter value

I can attest for this. This works also by using readvar from https://github.com/ErikErnst/kamstrup and asking for value 68 (0x44).

280443 is decoded as 0x28 means m^3, 04 means 4 byte value and 43 means how to convert the value, aka 0x40 it's a negative exponent, and 0x03 it should be ^-3 , all according to above referenced code.

[glance-]

Btw, 74 (0x4A) gives you l/h.

[jakobschou]

@glance- So to understand - have you figured out how to connect to the meter with the IR-to-USB, and get readings from it, that can be pushed to etc. Home Assistant?

[jakobschou]

I have found this fork that should work with the ir-to-usb with HA:

https://github.com/kristianschneider/ha-multical_21

[mroek]

@glance- I am very interested in your findings, as I also have a flowIQ 2200 in my house (installed by the municipality). The meter sends data using Wireless M-bus, but unfortulately it is encrypted, and the municipality does not want to provide me with the encryption key.

My question to you is whether you know if the data obtained through the optical eye is also going to be encrypted in my case. Do you know whether your meter also sends encrypted data wirelessly? If so, it probably means that the optical data is not encrypted.

Second question is if you have verified that you can poll the meter whenever you want, or if it imposes some limit on the optical interface to preserve battery life?

Third question is if you know whether a magnet is necessary to activate the optical interface on the meter or not. There is no metal plate for the magnet to attach to, so the official Kamstrup optical eye needs a plastic bracket that attaches to the meter to hold the optical eye in place. It could still need a magnet to activate the optical interface, though.

I guess you just used a Linux-machine to run the software you linked to (https://github.com/ErikErnst/kamstrup), but I suppose it should be possible to adapt the necessary parts of the software to run on an ESP to provide a wireless reader of sorts.

[mroek]

I have a flowIQ2200 (like @glance- ), but there is absolutely no way I can get it to talk to me. I've just DIYed a reading head (3D-printed multiple brackets for the IR leds), and I have added magnets in all kinds of orientations, but the optical interface is just completely dead.

The IR-leds I used was just something I had lying around, and I don't know their peak wavelength, but I doubt that the problem is there. If I point my IR-leds at each other, I will receive a correct echo in a serial terminal, so the circuit (even if just cobbled together on a breadbord) seems fine.

Kamstrup sells a bracket for mounting their optical eye, and due to the design of the meter, the optical eye doesn't really touch the face of the meter, instead it rests against the outer rim. I assume there are light guides in the braket to ensure a good optical connection to the meter. What this also means, is that the magnet sensor in the meter must be located inside the outer rim, and I am fairly certain this is correct. Reason is I found this text in a Kamstrup document:

It is possible to toggle through all views by means of the Kamstrup meter reader head, part no. 6699- 099, placed on the optical eye at the meter front. For more details on the meter reader head/optical eye, please see chapter 11 Tools and programs. The magnet needs to be removed, and applied again on the optical eye, to switch display view.

I found a position for the magnet where I could get the meter to change the views, so it seems natural to think that this is also the position used to turn on the optical port. However, still nothing. Very frustrating.

There is also a statement that the polarity of the magnet is important, and I did notice that the above mentioned change of display views only works with the magnet oriented with the south pole towards the meter. This is opposite to what the 62056-21 standard says (for the reading head):

Magnetization: axial, north pole directed towards the tariff device.

It seems unlikely that my meter has a permanently disabled optical port, I can't find any order codes for such an option. And just to make it clear, I am sending KMP telegrams, like mentioned by @copystring further up in this discussion.

Edit: Another curious thing that I just discovered is that if I just start a loop of readings without any magnet attached, and then place the magnet on the spot where I can get it to change the display view, the displacy just briefly flickers to another view and then returns to normal. This is a clear indication that it does register something at the IR port, because if I don't send anything, the display views can be cycled as described in the tech doc.

[mroek]

Ok, so I finally have success! Turns out that there was indeed a problem with my receiver circuit. It wasn't sensitive enough to trigger on the IR signal from the meter.

I came up with the idea to have only my TX LED connected and sending repeated requests, and then I pointed my phone camera to the TX led of the meter. It showed something was sent, which of course prompted me to increase the sensitivity of the receiver circuit.

After that, I did get sensible data from the meter. Would be nice to have an ID for some more registers, because there are plenty of them. There's a long list in that Kamstrup document I found, but it just names them, there's no telling the address/ID.

[mroek]

I left my reader polling at 30 seconds interval, and at some point (maybe a couple of hours) the meter stopped responding. :-(

Not sure if there is some internal counter/timer to limit readouts over the optical interface to preserve battery, but it is still bad news, as it means it is not a viable method to monitor the water consumption over time. Unless of course there is an acceptable polling rate that the meter will tolerate. I also noticed that it would shut down the optical interface if it wasn't polled, even if the magnet was left in place.

Will be interesting to see if it starts responding again tomorrow, but it would be really bad design if it doesn't.

[mroek]

It did start responding again this morning, so it clearly has some battery saver function to prevent polling on the optical interface from depleting the battery. That's annoying, and I have no clue how much polling will be allowed. It does not reset at midnight either, because I tried reading it after midnight, and it was still dead. I checked the internal clock in it this morning, and it was impressively accurate (only about 1 minute off from real time).

It might have some function to count the ON-time of the TX LED (easy enough, given a fixed baud rate, so it can just count the number of transmitted 0 bits and multiply by the bit time), and stop responding after some limit has been reached. However, it must also take time into consideration somehow, and in theory it should be possible to poll continuously if the rate of polling is within the limit. I wish they could just tell us how this works, since reverse-engineering the mechanism takes a lot of time.

It might just start a countdown of 24 hours at the first poll (assuming it has been idle for more than 24 hours), and then when the ON-time limit of the LED has been reached, it will stop responding until the 24 hour countdown has elapsed. That would be a resonable implementation, and if that is indeed how it works, it makes sense to only poll for the values one needs, and not "nice-to-have" values.

Edit: I just realized that if my theory above is correct, then the countdown time period is probably something like 12 hours, not 24 hours. Reason being that my meter stopped responding around 17:00, and it was responsive again around 08:00 the morning after. That's less than 24 hours, so I'm guessing 12 hours (if indeed that is how it works internally).

[aquaticus]

@mroek Every battery powered meter applies limits for reading. The producer guarantees device will work for specific time on battery, typically 3-5 years. They compute battery lifespan by assuming max readings per day, so the power consumption is known. The number of readings is typically in user manual but guess you have no access to it. For example Maddalena meter I got limits readings to 4 a day.

[mroek]

@aquaticus Yes, I get that there are (and must be) limits, but it is difficult to get a handle on how this is applied for the flowIQ 2200 that I have. As mentioned, I was able to read multiple registers at a 30 second interval for at least a couple of hours continuously yesterday, but today it seems to have gone silent after just a few reads. And it also seems to deactivate the optical interface even if there is a magnet attached, so the only way to wake it again is to remove and reattach the magnet. That does not work if it has gone all silent, though.

Very frustrating to not have a proper document to refer to. I've asked Kamstrup for some info, but I have not had a reply yet.

[mroek]

The battery saving function of the flowIQ 2200 basically makes it useless. This morning I did a test where I polled it every 5 minutes, and only requesting one register. It returned 12 values (maybe a couple of more that I didn't catch in my log) before becoming unresponsive. Now, that might mean it is possible to read one value every second hour, but there's another big issue:

The optical interface also times out even if the magnet stays attached, and my tests indicates that this timeout is somewhere between 5 and 10 minutes. That means it is not possible to attach an optical head and then just poll it at a slow enough rate to avoid the polling limit (which is still unknown, just fairly low). The head must be removed and reattached to reactivate the optical interface, which is of course useless. Automating that function is of course also possible (with a servo or possibly an electromagnet), but it really makes for a clumsy solution.

A final note is that I suspect there could even be a global counter for the responses for the optical interface. That would explain why I could read a bunch of values at 30 second intervals the first time I got this working, simply because no readings had been done since the meter was installed a couple of years ago. However, now I have spent my quota, and it will just slowly refill itself.

[aquaticus]

• Maybe number of readings is limited per week or month. Reading every 30s could block the meter for a couple of days.
• Maybe the meter must be wake up by sending special sequence. Detecting magnetic field could be a one time activation.
• The reader my limit the time it is active, say to 5s, so total transmission time must be less than active time.

The above are just guessing based on other readers I played with.

[mroek]

If the magnetic field is just left in place, the meter will stop responding even if there are more "reads" available. To get responses again, the magnetic field must be removed and reapplied. However, there could exist a special (and secret) wake-up sequence, of course. It would make some sense if there was, because if service personnel wanted to read for example the logs, it would be dumb if there was no way for them to get any output because there was no quota left due to the user (i.e me) had been reading it until it stopped responding.

There is absolutely no doubt that there is a limit to the available readings, but as of yet it is impossible to know how said limit works. Could be per day, per week, it's anyone's guess, really. Or indeed transmission time. However, as we know, I was able to do a fairly large amount of readings when I first got it working, so clearly there was a number of allowed readings that had accumulated over time. That probably means it is not an amount per week, becuse if it was, then I should have been completely blocked by now. I am not, but the number of allowed readings seems to be very low by now. Probably maybe 10 per day, or something.

One observation I have made that is mildly interesting is that even if the meter has stopped responding, the optical receiver is active (thus a special wakeup sequence could exist). I know this because if you remove and reattach the magnet, you can cycle the display views. The current view will revert after a number of seconds. However, if I send something to the meter in that period, the view reverts immediately. In other words, it does read even if it does not respond.

[mdrmdrmdr]

After numerous tries with (wrong) ChatGPT suggestions and other websites, I finally could read register x0044 (total volume so far) from my Kamstrup flowIQ 2200 (got it installed just 2 weeks ago) using the code from the Kamstrup repository on GitHub.

But I also see the "stop responding" issue. This indeed makes it quite useless for e.g. once per hour readouts. I really hope that there is some solution to get around this "feature".

Does anybody know if using the official Kamstrup IR head shows the same behaviour?

[mroek]

Does anybody know if using the official Kamstrup IR head shows the same behaviour?

The optical head doesn't really do anything except convert the data stream to IR light, so I highly doubt that it would make any difference whatsoever. It is possible that the Kamstrup software has some kind of secret sequence to allow it to talk to the meter even after it has stopped responding to normal register reads, but again, that will be a feature in the software, not in the reading head.

Using the official Kamstrup software is probably the only way of finding out if there is a way of getting the meter to respond again, but the software isn't publicly available, and on top of that I suspect it isn't useable without a Kamstrup account.

@mdrmdrmdr Where in the world are you located? Maybe you could get access to the encryption key for your meter, and listen to the radio transmissions from the meter instead?

[mdrmdrmdr]

@mdrmdrmdr Where in the world are you located? Maybe you could get access to the encryption key for your meter, and listen to the radio transmissions from the meter instead?

In wonderful Upper Bavaria :-) I doubt that I could get the encryption key. And I'd need to dive into the 868 MHz communication of the flowIQ. I already have a 868 MHz gateway for a differential temperature meter for Homegear, but don't know if this could be used to sniff the Kamstrup radio transmissions.

[mdrmdrmdr]

I also placed the question regarding the "stop responding" issue here.

[mroek]

@mdrmdrmdr If you can get access to the encryption key, getting the data from the 868 MHz wireless M-bus is simple enough. You'd just need a suitable radio dongle, and then you could use https://github.com/wmbusmeters/wmbusmeters/ to get the data. I did that, and I can see that my meter sends data, I just can't read it because I haven't got the encryption key.

[SzczepanLeon]

Here https://forum.arturhome.pl/t/komponent-do-esphome-umozliwiajacy-odczyt-miernikow-wm-bus-i-transmisje-wyniku-do-ha/7548 is nice discussion about wM-Bus and ESPHome.

[mdrmdrmdr]

Thanks, I'll try that. Do you have a suggestion for a good USB radio dongle? The key should be know by the local water people, right? They don't give me the impression that they would understand my question about the key...

[SzczepanLeon]

Thanks, I'll try that. Do you have a suggestion for a good USB radio dongle?

Discussion above is about ESP + CC1101. No USB dongles, just ESPHome + external component.

[mroek]

@mdrmdrmdr Ask them to give you the KEM file for your meter (serial number of your meter is needed). They'd need to log onto the Kamstrup servers to get the file, but they may well refuse. I have had no success so far with my water meter company (the municipality), they just point to GDPR in their refusal.

[mroek]

Thanks, I'll try that. Do you have a suggestion for a good USB radio dongle?

Discussion above is about ESP + CC1101. No USB dongles, just ESPHome + external component.

I actually have a CC1101 and an ESP, and I used this code to test: https://github.com/CentauriDK/esp-multical21 However, since I don't have the key, I can only see that telegrams are received from my meter, I can't use it for anything.

[mroek]

As for a dongle, I purchased this (pretty cheap) one: https://www.aliexpress.com/item/1005002623914698.html

Seems to work OK, but again, quite useless without the key.

[mdrmdrmdr]

Your link responds with "Sorry, the page you requested can not be found:("

[mroek]

@mdrmdrmdr Very odd. The link works for me, both in Chrome and FF.

[mdrmdrmdr]

Ah, a second small font comment says: "Unfortunately, this item is currently unavailable in your location."