Problem with protocol 224 GEO minim+ energy monitor

[Tobiasonline]

Hi,

i have the GEO minim+ and can't decode Data from it. If I run rtl_433 -f 868.29M I receive nothing.
a quick search in the protocol file I have seen a example Flex decoder who gets me raw data every 3 sek:

`
~ $ rtl_433 -f 868.29M -s 1024k -Y classic -X 'n=minim+,m=FSK_PCM,s=24,l=24,r=3000,preamble=0x7bb9'
rtl_433 version 22.11-77-gb57a894f branch master at 202302031151 inputs file rtl_tcp RTL-SDR
Use -h for usage help and see https://triq.org/ for documentation.
Trying conf file at "rtl_433.conf"...
Trying conf file at "/home/pi/.config/rtl_433/rtl_433.conf"...
Trying conf file at "/usr/local/etc/rtl_433/rtl_433.conf"...
Trying conf file at "/etc/rtl_433/rtl_433.conf"...

New defaults active, use "-Y classic -s 250k" for the old defaults!

[Protocols] Registered 202 out of 234 device decoding protocols [ 1-4 8 11-12 15-17 19-23 25-26 29-36 38-60 63 67-71 73-100 102-105 108-116 119-121 124-128 130-149 151-161 163-168 170-175 177-197 199 201-215 217-228 230-232 234 ]
[SDR] Found 1 device(s)
[SDR] trying device 0: Realtek, RTL2838UHIDIR, SN: 00000001
Found Rafael Micro R828D tuner
[SDR] Using device 0: Generic RTL2832U OEM
[R82XX] PLL not locked!

---

time : 2023-02-04 13:48:11
model : minim+ count : 1 num_rows : 1 rows :
len : 94 data : fb068105300000003442961c
codes : {94}fb068105300000003442961c

---

time : 2023-02-04 13:48:11
model : minim+ count : 1 num_rows : 1 rows :
len : 387 data : dac1352a0000000000000000000001400000000000000000aaaaaaaaaa00f616eef0aaffff00000000aaffaaaa0040ea0
codes : {387}dac1352a0000000000000000000001400000000000000000aaaaaaaaaa00f616eef0aaffff00000000aaffaaaa0040ea0

---

time : 2023-02-04 13:48:14
model : minim+ count : 1 num_rows : 1 rows :
len : 94 data : fb068105300000003442961c
codes : {94}fb068105300000003442961c

---

time : 2023-02-04 13:48:14
model : minim+ count : 1 num_rows : 1 rows :
len : 386 data : dac1352a0000000000000000000001400000000000000000aaaaaaaaaa00f616eef0aaffff00000000aaffaaaa0040ea0
codes : {386}dac1352a0000000000000000000001400000000000000000aaaaaaaaaa00f616eef0aaffff00000000aaffaaaa0040ea0

---

time : 2023-02-04 13:48:17
model : minim+ count : 1 num_rows : 1 rows :
len : 94 data : fb068105300000003442961c
codes : {94}fb068105300000003442961c

---

time : 2023-02-04 13:48:17
model : minim+ count : 1 num_rows : 1 rows :
len : 386 data : dac1352a0000000000000000000001400000000000000000aaaaaaaaaa00f616eef0aaffff00000000aaffaaaa0040ea0
codes : {386}dac1352a0000000000000000000001400000000000000000aaaaaaaaaa00f616eef0aaffff00000000aaffaaaa0040ea0

---

time : 2023-02-04 13:48:20
model : minim+ count : 1 num_rows : 1 rows :
len : 94 data : fb068105300000003442961c
codes : {94}fb068105300000003442961c

---

time : 2023-02-04 13:48:20
model : minim+ count : 1 num_rows : 1 rows :
len : 387 data : dac1352a0000000000000000000001400000000000000000aaaaaaaaaa00f616eef0aaffff00000000aaffaaaa0040ea0
codes : {387}dac1352a0000000000000000000001400000000000000000aaaaaaaaaa00f616eef0aaffff00000000aaffaaaa0040ea0
`

the other two flex decoder examples (for sensor and display unit) won't work:
raw sensor data: rtl_433 -f 868.29M -s 1024k -Y classic -X 'n=minim+ sensor,m=FSK_PCM,s=24,l=24,r=3000,preamble=0x7bb93f'
Data format string:
ID:24h VA:13d 3x UP:24d CRC:16h

raw display data: rtl_433 -f 868.29M -s 1024k -Y classic -X 'n=minim+ display,m=FSK_PCM,s=24,l=24,r=3000,preamble=0x7bb9ea'
Data format string:
ID:24h PWR:15d 1x 64x WH:11d 5x 64x 48x MIN:8d HRS:8d DAYS:16d 96x CRC:16h
rtl_433 -f 868.29M -s 1024k -Y classic -X 'n=minim+ sensor,m=FSK_PCM,s=24,l=24,r=3000,preamble=0x7bb93f'

I think there is something wrong with the preamble? I'm not very good at reading raw data, maybe someone can help me?

Regards, Tobias

[zuckschwerdt]

@UnscrewLater can you take a look?

It seems the 4 bytes header here are dac1352a and fb068105 is thay maybe a serial number and not the device class?
Codes look consistent otherwise?

{94}fb068105 300000003442961c
{387}dac1352a 0000000000000000000001400000000000000000aaaaaaaaaa00f616eef0aaffff00000000aaffaaaa0040ea0
{94}fb068105  300000003442961c
{386}dac1352a 0000000000000000000001400000000000000000aaaaaaaaaa00f616eef0aaffff00000000aaffaaaa0040ea0
{94}fb068105 300000003442961c
{386}dac1352a 0000000000000000000001400000000000000000aaaaaaaaaa00f616eef0aaffff00000000aaffaaaa0040ea0
{94}fb068105 300000003442961c
{387}dac1352a 0000000000000000000001400000000000000000aaaaaaaaaa00f616eef0aaffff00000000aaffaaaa0040ea0

[zuckschwerdt]

OK, of the four header bytes suspected to be magic numbers the last one is actually the packet length. 05 or 2a. The first three are still not clear but show some pattern, seen so far:

3f 06 29 05
fb 06 81 05

and

ea 01 35 2a
da c1 35 2a

I'll fix the decoder now.

[zuckschwerdt]

Should be fixed with b671f4b now.

[Tobiasonline]

i confirm, solution works for me. Thank you!