Meater wire free probe intergration.


 
D

Dean A

New member
Hello all,

Has anybody got the single probe version of the 'meater' wire free thermo probe yet, if so what their thoughts are.

I am not an owner of one since I have backed a 4 probe 'block' version (not shipping yet) and have little details to share except for what is on the indiegogo backers page. I believe the single probe version is being shipped however.

My main question is aimed towards the heatermeter gurus out there - whether or not this sort of device could be integrated with my beloved heater meater units. Shoving a probe in some meat and not worrying about all those wires seems like a dream; rotisserie, foil wrapping nirvana!! :D
 
I know Bryan has at least 1. there's a Meater thread from the kickstarter timing that I bumped a couple months ago.
I bought 2. My one-word review is 'meh'.
I have a big steel keg - My phone has to be within a few feet to hold signal.
No way to calibrate - at room temp, my 2 probes read 8*F different. At higher temp, they get closer, but it still is annoying.
Not looking good for use with heatermeter (or anything other than the meater app) - Bluetooth protocol is funky (per Bryan)
 
I haven't spent much time on it other than to pair the Meater probe with a bluetooth dongle under Linux to see what the protocol looked like. I assumed they'd just use the UART (serial) profile but they have their own custom HID for the protocol so Linux has no driver for it. I assume that means they have their own custom bluetooth-level protocol in addition to the on-the-wire protocol. I'm fairly good at reverse engineering protocols if I can get bit/byte-level dumps, but because I can't even get that due to a custom bluetooth HID, I didn't put any further effort into it. They've also said there will be an open API at some point, but I believe they intend it to poll their cloud services rather than allow other devices to integrate directly with it.
 
I know this thread is old, but for anyone wanting to continue looking in to things, I have the meater block. I set my wireless card to promiscuous mode in wireshark and started capturing packets sent from my meater block. I have a dump of the packets captured. For reference I will paste a few below. What I have been able to gather is that each probe can be found in each of these dumps with the following regex:

08 ([a-f0-9]{2} ){2}10 [a-f0-9]{2} [a-f0-9]{2} 18

I have also identified that the time stamp starts at the 158th hex value and is comprised (as far as I can tell right now) of the 158th and 159th hex values. Some of the values appear to be excess-128 numbers like the seconds of the timestamp and the first number of each of the probe values. I also believe these values are little endian values of a sort.

I'm not the best at reversing this sort of thing so it's been a slow process which is why I am sharing what little I have gleaned from the dump I gathered. Here are a few of the packets, each packet is separated be a couple lines:

ff ff ff ff ff ff d0 d9 4f 80 0f d0 08 00 45 00
01 2f 15 7b 00 00 80 11 62 36 c0 a8 01 65 ff ff
ff ff 1e c6 1e c6 01 1b c5 ad 12 90 02 0a 29 08
ca a8 01 10 07 18 01 20 32 2a 1d 42 4c 4b 2d 31
2e 30 2e 31 36 2e 31 2d 46 42 36 44 37 30 37 37
45 37 31 37 37 46 44 34 12 45 08 da b6 c8 c0 b5
bc e0 f5 35 10 01 18 01 20 5a 28 00 32 21 08 00
10 01 18 f1 0b 20 04 28 0e 30 05 42 07 08 05 10
01 18 d8 04 48 9b b9 86 ca e9 e7 9e 95 81 01 3a
0e 08 bc 05 10 c8 05 18 d4 08 20 01 28 80 19 12
2f 08 fb cc eb a7 c0 fc 85 b8 5f 10 02 18 01 20
5a 28 00 32 0d 08 00 10 00 18 90 07 20 00 28 00
30 00 3a 0c 08 ae 05 10 ae 05 18 00 20 01 28 00
12 2f 08 e5 c7 ee 96 c2 d9 e1 f3 1a 10 03 18 01
20 5a 28 00 32 0d 08 00 10 00 18 90 07 20 00 28
00 30 00 3a 0c 08 b0 05 10 bc 05 18 00 20 01 28
00 12 30 08 a6 b1 ae f6 dd c6 b6 b7 80 01 10 04
18 01 20 5a 28 00 32 0d 08 00 10 00 18 90 07 20
00 28 00 30 00 3a 0c 08 be 05 10 be 05 18 00 20
01 28 00 18 01 20 00 28 66 30 02 38 03


ff ff ff ff ff ff d0 d9 4f 80 0f d0 08 00 45 00
01 2f 15 82 00 00 80 11 62 2f c0 a8 01 65 ff ff
ff ff 1e c6 1e c6 01 1b ae a0 12 90 02 0a 29 08
ca a8 01 10 07 18 01 20 33 2a 1d 42 4c 4b 2d 31
2e 30 2e 31 36 2e 31 2d 46 42 36 44 37 30 37 37
45 37 31 37 37 46 44 34 12 45 08 da b6 c8 c0 b5
bc e0 f5 35 10 01 18 01 20 5a 28 00 32 21 08 00
10 01 18 f1 0b 20 04 28 0e 30 05 42 07 08 05 10
01 18 d8 04 48 9b b9 86 ca e9 e7 9e 95 81 01 3a
0e 08 d4 05 10 d4 05 18 d4 08 20 01 28 83 19 12
2f 08 fb cc eb a7 c0 fc 85 b8 5f 10 02 18 01 20
5a 28 00 32 0d 08 00 10 00 18 90 07 20 00 28 00
30 00 3a 0c 08 ae 05 10 ae 05 18 00 20 01 28 00
12 2f 08 e5 c7 ee 96 c2 d9 e1 f3 1a 10 03 18 01
20 5a 28 00 32 0d 08 00 10 00 18 90 07 20 00 28
00 30 00 3a 0c 08 b0 05 10 b0 05 18 00 20 01 28
00 12 30 08 a6 b1 ae f6 dd c6 b6 b7 80 01 10 04
18 01 20 5a 28 00 32 0d 08 00 10 00 18 90 07 20
00 28 00 30 00 3a 0c 08 bc 05 10 c8 05 18 00 20
01 28 00 18 01 20 00 28 66 30 02 38 03


ff ff ff ff ff ff d0 d9 4f 80 0f d0 08 00 45 00
01 2f 15 8a 00 00 80 11 62 27 c0 a8 01 65 ff ff
ff ff 1e c6 1e c6 01 1b 9d 81 12 90 02 0a 29 08
ca a8 01 10 07 18 01 20 34 2a 1d 42 4c 4b 2d 31
2e 30 2e 31 36 2e 31 2d 46 42 36 44 37 30 37 37
45 37 31 37 37 46 44 34 12 45 08 da b6 c8 c0 b5
bc e0 f5 35 10 01 18 01 20 5a 28 00 32 21 08 00
10 01 18 f1 0b 20 04 28 0e 30 05 42 07 08 05 10
01 18 d8 04 48 9b b9 86 ca e9 e7 9e 95 81 01 3a
0e 08 e6 05 10 f2 05 18 d4 08 20 01 28 86 19 12
2f 08 fb cc eb a7 c0 fc 85 b8 5f 10 02 18 01 20
5a 28 00 32 0d 08 00 10 00 18 90 07 20 00 28 00
30 00 3a 0c 08 ac 05 10 ac 05 18 00 20 01 28 00
12 2f 08 e5 c7 ee 96 c2 d9 e1 f3 1a 10 03 18 01
20 5a 28 00 32 0d 08 00 10 00 18 90 07 20 00 28
00 30 00 3a 0c 08 b0 05 10 b0 05 18 00 20 01 28
00 12 30 08 a6 b1 ae f6 dd c6 b6 b7 80 01 10 04
18 01 20 5a 28 00 32 0d 08 00 10 00 18 90 07 20
00 28 00 30 00 3a 0c 08 bc 05 10 c8 05 18 00 20
01 28 00 18 01 20 00 28 66 30 02 38 03


ff ff ff ff ff ff d0 d9 4f 80 0f d0 08 00 45 00
01 2f 15 8c 00 00 80 11 62 25 c0 a8 01 65 ff ff
ff ff 1e c6 1e c6 01 1b fd e0 12 90 02 0a 29 08
ca a8 01 10 07 18 01 20 35 2a 1d 42 4c 4b 2d 31
2e 30 2e 31 36 2e 31 2d 46 42 36 44 37 30 37 37
45 37 31 37 37 46 44 34 12 45 08 da b6 c8 c0 b5
bc e0 f5 35 10 01 18 01 20 5a 28 00 32 21 08 00
10 01 18 f1 0b 20 04 28 0e 30 05 42 07 08 05 10
01 18 d8 04 48 9b b9 86 ca e9 e7 9e 95 81 01 3a
0e 08 82 06 10 8e 06 18 d4 08 20 01 28 88 19 12
2f 08 fb cc eb a7 c0 fc 85 b8 5f 10 02 18 01 20
5a 28 00 32 0d 08 00 10 00 18 90 07 20 00 28 00
30 00 3a 0c 08 ac 05 10 ac 05 18 00 20 01 28 00
12 2f 08 e5 c7 ee 96 c2 d9 e1 f3 1a 10 03 18 01
20 5a 28 00 32 0d 08 00 10 00 18 90 07 20 00 28
00 30 00 3a 0c 08 b0 05 10 bc 05 18 00 20 01 28
00 12 30 08 a6 b1 ae f6 dd c6 b6 b7 80 01 10 04
18 01 20 5a 28 00 32 0d 08 00 10 00 18 90 07 20
00 28 00 30 00 3a 0c 08 be 05 10 be 05 18 00 20
01 28 00 18 01 20 00 28 66 30 02 38 03
 
Last edited:
Here is a link to view the data with the regex applied so you can see the temps from the 4 probes:

https://regex101.com/r/rblAab/2

Each of the probes has a leading 08 (possibly a position of sorts) followed by the internal/external thermistor values then a 10 in the middle followed by the other internal/external thermistor values and finally ending with an 18.

The hex 08, 10 and 18 are constants and are increments of 8 (decimal) so I am guessing they have some positional significance, but are not part of the temperature readings themselves.
 
Last edited:
ok, so what I have been able to figure out is that each thermistor's value is 16 bits. The first 8 bits is an excess-128 value that increments the following 8 bits. The timestamp is similarly encoded. Here is a simple javascript function that shows how to convert these values to an int:

function convert(hex) {
var incrementor = parseInt(hex.substring(0, 2), 16) - 128;
var count = parseInt(hex.substring(2, 5), 16);
return (count * 128) + incrementor;
}

pulled the two temps from the thermistors of one of my probes along with the timestamp and ran them through that little function above, then plotted the values in a chart. The following image shows my plotted values and times with the chart from the meater app highlighting the same time range that my data matches.

QYEMPta.png


It looks like they are smoothing and possibly decimating the data in their map, but I would say the two charts are close enough to call this progress.
 
Last edited:
Interesting. So are you sniffing TCP/IP packets going to and from the Meater servers or is this bluetooth BLE sniffing?
 
I was sniffing wifi packets and they appear to be UDP, not TCP. My block is sending UDP packets over port 7878 and they look like they are multi cast packets, so I wrote a simple program for an ESP32 chip to connect to my router and grab those packets off of that 7878 port. I should be able to start consuming this information.

My ultimate goal is to couple this ESP32 chip with a digital pot that can inject the temperature values into my blower so that I can get rid of the need for my blower wire as well. I already have that half of the equation worked out, so once I wrap up this stuff with the Meater block I should have a working prototype and no more wires going in to my smoker!
 
LKSpencer said:
I was sniffing wifi packets and they appear to be UDP, not TCP. My block is sending UDP packets over port 7878 and they look like they are multi cast packets, so I wrote a simple program for an ESP32 chip to connect to my router and grab those packets off of that 7878 port. I should be able to start consuming this information.

My ultimate goal is to couple this ESP32 chip with a digital pot that can inject the temperature values into my blower so that I can get rid of the need for my blower wire as well. I already have that half of the equation worked out, so once I wrap up this stuff with the Meater block I should have a working prototype and no more wires going in to my smoker!
Click to expand...

Hey,

How have you made out with this? Their cloud service has been driving me mad but the probes themselves are good. I'm trying to collect via the BLE service, I want to remove the block entirely and just pump the data into MQTT. I believe I have found the data in service 2 characteristics 1. I am working on decoding the temperature now. Once this is working, I intend to use an ESP32 or a RPI to listen for all the probes and send them to MQTT for more general integrations.

This one of my probes going from around room temp to boiling (partial dump here):
I believe the first two bytes are the tip and the next two are the ambient, perhaps similar to what you have discovered in the wifi payload.
Still collecting the data now for additional analysis but I have high hopes of getting this working.

Code: 
bytearray(b'\xc0\x01\x0b\x00\x1f\x00\n\x00')
bytearray(b'\xc2\x01\x0b\x00\x1f\x00\n\x00')
bytearray(b'\xc4\x01\x0b\x00\x1f\x00\n\x00')
bytearray(b'\xc8\x01\x0b\x00\x1f\x00\n\x00')
bytearray(b'\xca\x01\x0b\x00\x1f\x00\n\x00')
bytearray(b'\xcd\x01\x0b\x00\x1f\x00\n\x00')
bytearray(b'\xd0\x01\x0b\x00\x1f\x00\n\x00')
bytearray(b'\xd3\x01\x0b\x00\x1f\x00\n\x00')
bytearray(b'\xd5\x01\x0b\x00\x1f\x00\n\x00')
bytearray(b'\xd9\x01\x0b\x00\x1f\x00\n\x00')
bytearray(b'\xdd\x01\x0b\x00\x1f\x00\n\x00')
bytearray(b'\xe0\x01\x0b\x00\x1f\x00\n\x00')
bytearray(b'\xe3\x01\x0b\x00\x1f\x00\n\x00')
bytearray(b'\xe8\x01\x0b\x00\x1f\x00\n\x00')
bytearray(b'\xec\x01\x0b\x00\x1f\x00\n\x00')
bytearray(b'\xf1\x01\x0b\x00\x1f\x00\n\x00')
bytearray(b'\xf5\x01\x0b\x00\x1f\x00\n\x00')
bytearray(b'\xfd\x01\x0b\x00\x1f\x00\n\x00')
bytearray(b'\x01\x02\x0b\x00\x1f\x00\n\x00')
bytearray(b'\x05\x02\x0b\x00\x1f\x00\n\x00')
bytearray(b'\t\x02\x0b\x00\x1f\x00\n\x00')
bytearray(b'\r\x02\x0b\x00\x1f\x00\n\x00')
bytearray(b'\x11\x02\x0b\x00\x1f\x00\n\x00')
bytearray(b'\x14\x02\x0b\x00\x1f\x00\n\x00')
bytearray(b'\x18\x02\x0b\x00\x1f\x00\n\x00')
bytearray(b'\x1b\x02\x0b\x00\x1f\x00\n\x00')
bytearray(b'\x1e\x02\x0b\x00\x1f\x00\n\x00')
bytearray(b'!\x02\x0b\x00\x1f\x00\n\x00')
bytearray(b'%\x02\x0b\x00\x1f\x00\n\x00')
bytearray(b'*\x02\x0b\x00\x1f\x00\n\x00')
bytearray(b'-\x02\x0b\x00\x1f\x00\n\x00')
bytearray(b'0\x02\x0b\x00\x1f\x00\n\x00')
bytearray(b'3\x02\x0b\x00\x1f\x00\n\x00')
bytearray(b'6\x02\x0b\x00\x1f\x00\n\x00')
bytearray(b'9\x02\x0b\x00\x1f\x00\n\x00')
bytearray(b'<\x02\x0b\x00\x1f\x00\n\x00')
bytearray(b'?\x02\x0b\x00\x1f\x00\n\x00')
bytearray(b'D\x02\x0b\x00\x1f\x00\n\x00')
bytearray(b'G\x02\x0b\x00\x1f\x00\n\x00')
bytearray(b'J\x02\x0b\x00\x1f\x00\n\x00')
bytearray(b'N\x02\x0b\x00\x1f\x00\n\x00')
bytearray(b'V\x02\x0b\x00\x1f\x00\n\x00')
bytearray(b'Z\x02\x0b\x00\x1f\x00\n\x00')
bytearray(b'^\x02\x0c\x00\x1f\x00\n\x00')
bytearray(b'b\x02\x0b\x00\x1f\x00\n\x00')
bytearray(b'f\x02\x0b\x00\x1f\x00\n\x00')
bytearray(b'k\x02\x0c\x00\x1f\x00\n\x00')
bytearray(b'o\x02\x0b\x00\x1f\x00\n\x00')
bytearray(b's\x02\x0b\x00\x1f\x00\n\x00')
bytearray(b'w\x02\x0b\x00\x1f\x00\n\x00')
bytearray(b'z\x02\x0b\x00\x1f\x00\n\x00')
bytearray(b'\x7f\x02\x0b\x00\x1f\x00\n\x00')
bytearray(b'\x82\x02\x0b\x00\x1f\x00\n\x00')
bytearray(b'\x85\x02\x0c\x00\x1f\x00\n\x00')
bytearray(b'\x8d\x02\x0b\x00\x1f\x00\n\x00')
 
LKSpencer said:
I was sniffing wifi packets and they appear to be UDP, not TCP. My block is sending UDP packets over port 7878 and they look like they are multi cast packets, so I wrote a simple program for an ESP32 chip to connect to my router and grab those packets off of that 7878 port. I should be able to start consuming this information.
Click to expand...

Hi, @LKSpencer. I just found this after I basically went through this night doing the same steps that you described. Did you happen to do anymore with this in code? I'm trying to decide if I'm going to go through the long and tedious task of pinpointing what each of these byte markers show by changing one thing in the app and doing a diff in the packets. I can see custom cook and temperature data easily enough but I can't decide on the rest if it's worth it.

For my uses I can just as happily get the data from their cloud by reversing that. Please let me know if you done anymore with the UDP packets that could save me (and us over at the Hubitat community) some time. I will do the same if I decide to figure out and document the rest of the UDP packet data structure. I may not though because I'm sure the cloud API will be tons easier to understand and I already have a working MITM.

#choices... local integration or easy integration
 
Hey, I took a bit of a break on this project. I am poking at it a bit more. I actually had some pretty solid code that was able to read the temperatures accurately using the steinhart hart formula. I generated the coefficients for the formula based off of set temperatures using a heat gun set to 250° F and the actual meater app to make sure I had it dialed in to that temperature and that it was holding steady. The get the coefficients you actually need three readings, so I used an ice bath and boiling water for the other two.

So what changed? Well, the packets changed which broke some of the regular expressions I was using to parse the data. I had expressions that would figure out which probe was on and a few other things too. The bytes of data that changed were (I believe) bytes related to times, dates, or smoking sessions.

The good news is that I have some old full packet data which I can use to help me figure this out and I am going to start logging packets for different cooks based off of the set temperature, the type of animal, and the selected cut of meat. That should give me a lot more information about what's stored in those packets and can help us dial this in.

Funny thing is I am using a raspberry by and javascript with node to sniff the packets now instead of an ESP32. I actually created a custom pi hat too for this project.
 
LKSpencer said:
Hey, I took a bit of a break on this project. I am poking at it a bit more. I actually had some pretty solid code that was able to read the temperatures accurately using the steinhart hart formula. I generated the coefficients for the formula based off of set temperatures using a heat gun set to 250° F and the actual meater app to make sure I had it dialed in to that temperature and that it was holding steady. The get the coefficients you actually need three readings, so I used an ice bath and boiling water for the other two.

So what changed? Well, the packets changed which broke some of the regular expressions I was using to parse the data. I had expressions that would figure out which probe was on and a few other things too. The bytes of data that changed were (I believe) bytes related to times, dates, or smoking sessions.

The good news is that I have some old full packet data which I can use to help me figure this out and I am going to start logging packets for different cooks based off of the set temperature, the type of animal, and the selected cut of meat. That should give me a lot more information about what's stored in those packets and can help us dial this in.

Funny thing is I am using a raspberry by and javascript with node to sniff the packets now instead of an ESP32. I actually created a custom pi hat too for this project.
Click to expand...

About the packets changing... In fact, since my post I have talked to somebody at Meater and they also confirmed that the UDP packet structure changed and is potentially going to keep changing so it could be a bit of a moving target. I still think it might be worthwhile to pursue though.

I haven't done anymore with it since the last time I looked at it. I'm building an integration for the block into Hubitat so that Hubitat users can trigger events off of the temperatures or whatever. We could TTS messages over speakers or flash lights when cooks are approaching done, etc. At present I can't actually subscribe to UDP broadcasts on that platform so some of this is a bit academic but I will probably be able to eventually. At that point, I think we would probably prefer the local integration over using the cloud APIs. I think in the meantime I have decided to go after a cloud integration.
However, down the road is there a possibility that you are going to make any of that code public once you figure it out again? I would love a link to the repository if you do. If you want the cloud integration code that I end up creating it will be in github in the hubitat-codahq repository under the codahq user. I have no current timeline though. The Meater integration is a bit lower priority than a few other projects I'm working on right now.
 
yeah, I actually am not surprised about the packets changing. The cool thing though is that the regex I had above is still accurate to represent the thermometer temperatures.

If my guess is right, they will mostly be changing packet data as they add different cuts of meat.

Currently each set of data per probe (of mine) ends with a version number and then the probe number. example: v1.0.5_1

the probe data all start with a 1a and then if you have a cook setup for them a 54 or 55 then 0a then 52 or 53 then 09 followed by 8 hex values that represent the mac address of the probe in little endian followed by 11 followed by the mac address of the meater block followed by 18 followed by the probe number.

example:
Code: 
1a 54 0a 52 09 xx xx xx xx xx xx xx xx 11 xx xx xx xx xx xx xx xx 18 01

It looks like they separate chunks of data by 08 10 18 20 28 30 but at the start of each probe they are instead using 09 11 18 as separators per the example above.

The selected meat from what I have gathered so far can be found with the following expression
Code: 
(?<=08 [a-fA-F0-9]{2} 10 [a-fA-F0-9]{2} 18 ([a-fA-F0-9]{2} ){2}20 )([a-fA-F0-9]{2} ){1,2}(?=2a 00 32 07)

I believe the desired end temp can be found with a similar expression as it appears to be in the same area as the selected meat
Code: 
(?<=08 [a-fA-F0-9]{2} 10 [a-fA-F0-9]{2} 18 )([a-fA-F0-9]{2} ){2}(?=20 ([a-fA-F0-9]{2} ){1,2}2a 00 32 07)
 
WBegg said:
Great project! My only concern is why?
Click to expand...
I thought I was pretty clear on why. I want to remove all the wires from my smoker. My blower currently has to have a wire going to the smoker and I intend on using the data from the meater to push those temp values to my blower so it can regulate my smoker temps without wires going in to my smoker.
 
There are three states a probe can be in that I've seen:

1) not cooking
2) cooking
3) finished cook (not the same as not cooking)

The following is information I've been able to figure out about each value out of the values from a single probe. Keep in mind that a single packet from the meater block will start with non probe data as I've outlined previously, followed by 4 chunks of data, one for each probe.

Code: 
NOT COOKING
   bc    cs    probe mac address -- -|    block mac address -- -|    p#    ?     ?     ?  -- -|    adj?  on?   temp? ?  -|    m tmp    a tmp    pt    ?     ct       probe version  -| _  p#
1a 3d 0a 3b 09 a6 98 cb de 35 da 6e 80 11 d4 7f 17 e7 77 70 6d fb 18 04 20 09 28 37 30 01 3a 07 08 00 10 00 18 90 07 42 0c 08 9e 06 10 9e 06 18 00 20 01 28 00 4a 08 76 31 2e 30 2e 35 5f 34
COOKING
   bc    cs    probe mac address -- -|    block mac address -- -|    p#    ?     ?     ?  -- -|    adj?  on?   temp?    meat?    ?  -- -- -- -- -- -- -- -| session number?-- -- -- -- -- -|    m tmp    a tmp    pt -|    ?     ct       probe version  -| _  p#
1a 54 0a 52 09 5a 1b 12 58 e3 81 eb 35 11 d4 7f 17 e7 77 70 6d fb 18 01 20 09 28 41 30 01 3a 1d 08 01 10 01 18 95 07 20 10 2a 00 32 07 08 05 10 01 18 d8 04 39 4b 9f 85 96 db 63 55 60 42 0d 08 96 06 10 96 06 18 96 06 20 01 28 16 4a 08 76 31 2e 30 2e 35 5f 31
FINISHED COOK
   bc    cs    probe mac address -- -|    block mac address -- -|    p#    ?     ?     ?  -- -|    adj?  on?   temp? ?  -| session number?-- -- -- -- -- -|    m tmp    a tmp    pt -|    ?     ct -|       probe version  -| _  p#
1a 4a 0a 48 09 5a 1b 12 58 e3 81 eb 35 11 d4 7f 17 e7 77 70 6d fb 18 01 20 08 28 3d 30 01 3a 12 08 02 10 00 18 95 07 2a 00 39 a4 a7 ba fd 27 80 54 60 42 0e 08 b0 06 10 c8 06 18 ff 0f 20 01 28 a6 01 4a 08 76 31 2e 30 2e 35 5f 31

bc - byte count == number of bytes after this byte
cs - checksum == byte count - 2. NOTE: I might have bc and cs backwards, but the math is sound.
p# - probe number
adj - number of adjustments that have been made to the cook (not 100% sure but that's what it appears to be related to)
on - I believe this is the hex value indicating if the probe has an active cook going or not where 00 is no cook and anything else means it has a cook (I've seen 01 and 02)
temp - this appears to be the target temperature but it's not in the same range as the probe cooking numbers
meat - this can be 1 or 2 hex values, but it appears to be the value used for the meat and it ends where 2a 00 32 07 starts
m tmp - meat temperature
a tmp - ambient temperature
pt - peak probe temperature (I think)
ct - cook time - how long the cook has been going for. NOTE: this is also a little endian excess-128 value like the probe temperatures.
 
Last edited:
I made quite a bit of progress on my little project. My code can reliably pull the temperatures from the Meater block. I designed a simple PCB for a raspberry pi hat, had it manufactured and then soldered on all the parts when it got here. Now I can:
  • intercept the UDP packets
  • extract the resistance values from the packets
  • convert the resistance readings to temperature values
  • set the resistance on my pi hat's digital potentiometer to match the resistance my blower device would expect at that smoker temperature
  • compare my interpreted temperatures to the Meater app to make sure I am getting the real temperatures
  • compare my interpreted temperatures to the temperature I am sending to my blower
I wrote a simple web api layer to host up pulling the last 10 readings.
I also wrote a web layer to view the data in a nice easy to read display.

If my UDP intercepting code does not receive a packet after 60 seconds, it will tell the blower that the smoker temperature is really high so the blower does not attempt to continue stoking the fire. This is beneficial for two reasons:
  1. If the probes run out of battery and are no longer providing readings then it will essentially stop the blower preventing the risk of fire.
  2. If I end a cook via the Meater app, it will stop the blower preventing the risk of fire after the cook ended.
I also have it setup to launch all of these services when the pi turns on, so I don't really have to think about any of it.

I've done a single 1.5 hour cook, smoking a tri-tip and it worked perfectly. My next test will be a full brisket which I have in the fridge and will most likely go on the smoker tomorrow.log-viewer.pngMVIMG_20200625_175343.jpgMVIMG_20200627_091632.jpg
 
You must log in or register to reply here.

 

Back
Top