Fredrik Öhrström

Do you want an option to change the "timestamp":"...utc...timestamp....." to "timestamp":"....local...timestamp..." so that visually the content corresponds with the file segmentation? Or should we split the files based on UTC...

Can you run with --debug loglevel=debug so that we can see what it says/gets from the dongle?

In the first probe we receive garbage: (cul) probe response "{g11a!1!q!1!J%!!!a!1!!" and the second attempt nothing. After the restart we get the expected response after the probe: (cul) probe response...

Aha! Can you try to change the source code in wmbus_amb8465.c with this diff: ``` - int rssi_len = (rssi_expected_ && data[1] == (0x80|CMD_DATA_IND)) ? 1 : 0; + int...

Add the new case and keep the old case (0) in the source. It must be there since transparent telegrams without ff03 will have msgid==0. It should looke like: ```...

CMD_DATA_IND is defined to be 3.

Thanks for the report and testing help! Permanent fix push to github. https://github.com/wmbusmeters/wmbusmeters/commit/6e3bac97d480748e6d548b47f7728246828c8e66

It seems like there is a one of bug here: checkAMB8465Frame "FF034A44C5143955052500047A31003025EE5793BF2A3D278935AFBD10B1A84F3D96268900C9EEB858FE5E3C2CABBE80BE2BFFEB9A2388771D44227773BA5A0CC503FD0C05010002FD0B2011122E" (amb8465) not enough bytes yet, partial command response 78 79. It thinks it is missing a single byte!...

From the analyze you can see that it only sends full m3 values. (Volume m³) contrary to the temperature for which it sends 1 decimal. (Flow temperature 10⁻¹ °C)

The meter itself tracks smaller values, my guess is they made a mistake configuring the wmbus telegrams this hydrus meter. This config should be for huge industries consuming multiple m3...