Decoding Flowis water meter

[vierundvierzig]

Originally topic was started on wmbusmeters project.

Now I am in place that it should be decode from the beginning using rtl_433. I can grab some sample files from today: sample_files.zip

I tried to analyze them but it says nothing to me...

Any help will be greatly appreciated!

[merbanan]

Use -S unknown.

[StKob]

"rtl_433 -f 868M -s 1000k -X 'n=name,m=FSK_PCM,s=10,l=10,r=5000' -S unknown" ?

[zuckschwerdt]

In that case it needs to be known because you added a decoder (-X). So: rtl_433 -f 868M -s 1000k -R 0 -X 'n=name,m=FSK_PCM,s=10,l=10,r=5000' -S known

[StKob]

I used for a parameters what was in this issue higher up. Ok, so that would be good?

[merbanan]

Timestamp decoding added to https://github.com/merbanan/rtl_433/pull/2357.

[merbanan]

A decoder for this device has now been merged. Reopen if you figure out more parameters.

[StKob]

I compiled it using VS2019. Starting with "rtl_433.exe -f 868M -s 1000k -R 237 -S known" Alarms number is increasing constantly. Am I using this right? Error while compiling?

rtl_433_1.zip rtl_433_2.zip rtl_433_3.zip rtl_433_4.zip

[StKob]

"alarm",         "Alarm",     DATA_INT,    b[11],
"backflow",      "Backflow",  DATA_INT,    b[12],

Shouldn't this be b[14] and b[15] ?

[zuckschwerdt]

At least the protocol description is off with V 32b: Volume in m3 and B C ... 15 does not sound right?

[StKob]

@merbanan Would you take a look at this?

[merbanan]

Should be fixed now.

[asquelt]

I have one meter with revision v24.8.00 (manufactured 3/22, serial starts with 2404) which reads fine and the other one with v24.C.06 (manufactured 2/23, serial starts with 2405) which does not show up in decoder. I know its serial number. @merbanan What should I run to gather only relevant data for you to update decoder?

There is some radio dump, I'm not sure if any of them are Flowis...

root@k3s3:~# docker inspect rtl443 -f '{{ .Args }}'
[-f 868M -s 1000k -R 237 -X n=name,m=FSK_PCM,s=10,l=10,r=5000]

root@k3s3:~# docker logs rtl443|grep codes|cut -d: -f2-| curl -XPUT -T- https://ze.psu.je/my_radio_traffic.txt
https://ze.psu.je/vGQlo/my-radio-traffic.txt

my-radio-traffic.txt

[asquelt]

some more data from active period (now). my serial is: 240536163 (there may be others in the dump too, as entire residential had them installed this week)

my-radio-traffic-2.txt

[merbanan]

Some decodes looks like flowis but you really need to single out the non working sensor for me to be able to do anything. Take a laptop and connect the rtl_sdr to it. Remove the antenna and then run rtl_433 -S unknown when next to the meter. You might need to adjust the gain value to be able to get a proper signal.

The idea is to only receive the non working transmissions and store them in a file for debugging purposes.

[asquelt]

ok, I'll try to connect myself to the shaft tomorrow :) as they seem quiet during weekends.

[asquelt]

attaching captures w/o antenna. i hope this helps.

flowis2023.zip

serial number 240536163 meter shows 0.459/0.460 during captures.

[asquelt]

@merbanan since it appears to be encrypted in 2023 units (probably using static key, given offline nature of official readers) is it viable to include a key in Flowis module (or provide an option for user to include a key if it's known) or is it outside of the scope of this project?

[merbanan]

If it is a static key then we can include it in the module. If it is configurable then we add it as an option.

[merbanan]

Try playing with the gain (-g). Now we get what looks like flowis data but the signal clips and that causes decode errors.

This is the decoded data:

codes : {241}c000044061c8e9c009801001880744000000000000000000000000013c100 codes : {282}0f8e2d391c38118016308560ec1f7c0e81ccc010000000000a10100809e00000074fc00 codes : {235}0f8e0c391c3810302630a160e3601000000000000000000000000337202 codes : {241}c044447569c8e1c089811245aa0744000000000000000000000000001e080 codes : {281}03f8ed391c3901901e340760ec048c1e81ccc000000000000850500809e00000078f600 codes : {233}0f8e0c381c3811302630a060e360000000000000000000000000166e400 codes : {243}c045555d61c0e9c089801247880740000000000000000000000000004f110 codes : {282}0faf8c391d3911900630e1e0ec197c1e05ccc010000000000870500809e000000f1f804 codes : {160}1302630a560e3601000000000000000000000000 codes : {234}0fafad391d3911302630a560e3601000000000000000000000000f37000

You can see the sync value in there for some values rows. And the data doesnt look encrypted to me.

[asquelt]

I've checked every gain value between 10..500 and there are no 2405 meters appearing in decodes (only 2404 ones). Please if anyone manages to capture them, let me know in comments what hardware and settings you use. For now I consider my unit to be faulty.

[zuckschwerdt]

I've checked every gain value between 10..500

If you are using a RTL-SDR with R820T then possible gain values in rtl_433 are 0..50 (i.e. dB not deci-dB)

[merbanan]

@asquelt it is possible that new meters have different payload that needs changes to the decoder. To me the signals looks similar but I have not manually decoded a message.

@zuckschwerdt maybe we can add some kind of metric in the output or filename to help people to set a proper gain? A clip detector would be nice to have.

[zuckschwerdt]

We do know the RSSI in dBFS (it's the OOK envelope) and we show it with -M level. We would need to specify how many samples above what threshold to consider "clipping". I see three cases here: (near) DC there will be multiple I/Q samples on nearly a straight line -- this is not clipping. One of I/Q might hit near maximum and make a nearly a straight line -- this is clipping "badly" at -0 dBFS. Since we basically just add I+Q we could get positive dB -- this is not necessarily clipping but beyond -0 dB.

For now though: the upcoming new Spectrogram (preview: https://triq.org/spectrogram-next/ ) indicates clipping (on the I/Q view and relative to the selected Gain) with color.

[vierundvierzig]

Let's take this part: 25 93 6c 5c In binary system: 00100101 10010011 01101100 01011100 Reverse and join: 01011100011011001001001100100101 And split again: 010111 0001 10110 01001 001100 100101 010111: 23 0001: 1 10110: 22 01001: 9 001100: 12 100101: 37

A small change to this. I think first figure is for summer time. 0 means winter, 1 means summer. For now it reads 110111 which is 55 and it is obviously wrong year. It should be 1 for summer and 10111 for 23 (year).

[StKob]

EU is using DST. Time was changed last Sunday of March.

[asquelt]

i can confirm this error. my Flowis readouts contain wrong date too.

rtl_433/rtl443/devices/1/Flowis/240431631/device_time 2055-05-12T15:08:33
rtl_433/rtl443/devices/1/Flowis/240428416/device_time 2055-05-08T15:54:52
rtl_433/rtl443/devices/1/Flowis/240421671/device_time 2055-05-08T13:09:08
rtl_433/rtl443/devices/1/Flowis/240421668/device_time 2055-05-12T15:04:01
rtl_433/rtl443/devices/1/Flowis/240431556/device_time 2055-05-12T15:03:55
rtl_433/rtl443/devices/1/Flowis/240431622/device_time 2055-05-12T15:02:39
rtl_433/rtl443/devices/1/Flowis/240427832/device_time 2055-05-12T15:02:12
rtl_433/rtl443/devices/1/Flowis/240421673/device_time 2055-05-12T15:02:45
rtl_433/rtl443/devices/1/Flowis/240431841/device_time 2055-05-12T15:03:43
rtl_433/rtl443/devices/1/Flowis/240508787/device_time 2055-04-25T13:54:00
rtl_433/rtl443/devices/1/Flowis/240538301/device_time 2055-04-06T08:54:52
rtl_433/rtl443/devices/1/Flowis/240427834/device_time 2055-04-28T10:37:53
rtl_433/rtl443/devices/1/Flowis/240426533/device_time 2055-03-28T11:51:42
rtl_433/rtl443/devices/1/Flowis/240431851/device_time 2055-03-28T11:52:54
rtl_433/rtl443/devices/1/Flowis/240428430/device_time 2055-04-04T10:55:02
rtl_433/rtl443/devices/1/Flowis/240428425/device_time 2055-05-05T15:55:16
rtl_433/rtl443/devices/1/Flowis/240431589/device_time 2055-03-28T11:51:27
rtl_433/rtl443/devices/1/Flowis/240426584/device_time 2055-05-03T10:53:53
rtl_433/rtl443/devices/1/Flowis/240536163/device_time 2055-05-01T08:44:59
rtl_433/rtl443/devices/1/Flowis/240538249/device_time 2055-05-01T11:34:52
rtl_433/rtl443/devices/1/Flowis/240539499/device_time 2055-05-02T15:41:25
rtl_433/rtl443/devices/1/Flowis/240473634/device_time 2055-04-25T13:46:22

[grumar]

Solved :) I don't know how to write it on BitBench but this is my idea, i.e:

{249}2aaaad391d3911501a6b1510e8125936c5c7c0100a00e0000a5010003900870 [2023-01-22 09:12:40] (* Note that it is a time of receiving by rtl_433)

Let's take this part: 25 93 6c 5c In binary system: 00100101 10010011 01101100 01011100 Reverse and join: 01011100011011001001001100100101 And split again: 010111 0001 10110 01001 001100 100101 010111: 23 0001: 1 10110: 22 01001: 9 001100: 12 100101: 37

My apologies for contacting you here. @vierundvierzig, did you manage to run this on lora32 device? It looks like I've stuck on the same issue as yours.

[rudsomlima]

Ok, I will do my best to record messages. And I will read information via dedicated device for this meters, so we will know what values we are looking for.

PS. I have small radio device for 868MHz, TTGO LoRa OLED. I'm trying to receive those packets via RadioLib library, but no success. Do you know that library? Could you point me what I should set? My settings for now:

  int state = radio.beginFSK();
  state = radio.setFrequency(868.0);
  state = radio.setBitRate(1000);
  state = radio.setFrequencyDeviation(150.0);
  state = radio.setRxBandwidth(250.0);
  state = radio.disableAddressFiltering();
  state = radio.setPreambleLength(4);
  uint8_t syncWord[] = {0xd3, 0x91, 0xd3, 0x91};
  state = radio.setSyncWord(syncWord, 4);

Hi, Were you able to get data using RadioLib and LilyGo v1.6.1? Could you post the code? Thanks (https://github.com/jgromes/RadioLib/discussions/820)

[asquelt]

i got one more meter with id starting with 2406 (manufactured in 6/2023, v24.9.00 on sticker) and it also doesn't decode with this code (with any gain combination).

for now it seems it works perfectly with old meters only (2404).