Hey Magma1447,
did you get any further decoding the UDP packets ?
Ive started hacking on the UDP packets, and a little on the BTLE packets also, with the goal of building a BTLE > UDP relay so I can keep my phone on me while cooking 
Anyways, if you have any progress please share it !
my code is currently at https://github.com/jaybinks/esp32_meater but its purely just me hacking right now, nothing thats real useful.
Ok… update on this the UDP traffic is using googles protocol buffers.
i’ve made some progress reading the data.
@JayBinks Sadly I didn’t really get anywhere. I didn’t manage to figure out the protocol. I am still very interested in it though.
I wonder if Meater would answer an email if one asks for some pointers to their protocol. If one proposes to release an open source plugin for Home Assistant and/or Meater to MQTT it would potentially make their product more interesting to a fairly big crowd. One probably have to sell the idea a bit though.
I would personally be interested in making a diagram in Node-red that posts the data to MQTT. A plugin for Home Assistant would work for me as well.
If you figure out the protocol, I will pick up where I left my stuff again. I will take a look at your repo to see where you are.
@JayBinks I notice that you remove your repository. Did you get anywhere?
It sounds reasonable that the udp packages would use protocol buffers, but I can’t manage to parse them. Maybe I don’t have knowledge enough of protocol buffers since I have never used it myself, but I had the idea that maybe it was prefixed with some other data. I therefore tried to parse it with different offsets.
Example:
for a in $(seq 1 200) ; do echo "4500 0152 1234 0000 4211 46c5 0a10 0584 0a10 04ff 1ec6 1ec6 013e 0000 0a13 08ca a801 100c 1801 2049 29b0 8ba1 9198 4062 d31a 9e02 0800 1003 1a1c 1a1a 09b0 8ba1 9198 4062 d310 6418 0220 012a 0976 2e32 2e30 2e31 2e33 1a3d 0a3b 0950 e020 ac52 88aa a111 b08b a191 9840 62d3 1801 2008 2861 3001 3a07 0800 1000 1890 0742 0c08 dc06 108e 0718 0020 0128 004a 0876 312e 302e 355f 311a 3d0a 3b09 8d96 32e8 919a f9cd 11b0 8ba1 9198 4062 d318 0220 0928 3f30 013a 0708 0010 0018 9007 420c 08e6 0510 fe05 1800 2001 2800 4a08 7631 2e30 2e35 5f32 1a3d 0a3b 0954 4006 df4a 5f88 c011 b08b a191 9840 62d3 1803 2009 284b 3001 3a07 0800 1000 1890 0742 0c08 e205 10fa 0518 0020 0128 004a 0876 312e 302e 355f 331a 3d0a 3b09 4b3f 62e5 99a1 7626 11b0 8ba1 9198 4062 d318 0420 0928 3530 013a 0708 0010 0018 9007 420c 08e6 0510 fe05 1800 2001 2800 4a08 7631 2e30 2e35 5f34" |tr -d ' ' |xxd -r -p |cut -b $a- |protoc --decode_raw ; sleep 1 ; done
protoc never managed to parse it though.
By using tcpdump -A it’s quite clear how the message looks and where each probes data is (I have block, so four probes). Example:
E..R.4..B.F.
...
........>..
.........
).....@b............ [email protected].. .* v.2.0.1.3.=
; P. .R.........@b... .(I0.:........B......... .(.J.v1.0.5_1.=
; ..2...........@b... (A0.:........B......... .(.J.v1.0.5_2.=
; [email protected]_........@b... (C0.:........B......... .(.J.v1.0.5_3.=
; K?b...v&......@b... (50.:........B......... .(.J.v1.0.5_4
There are a very few bytes that changes when I try to affect the temperature of the probe. It’s actually only 3-4 bytes that changes and I assume 1-2 of those are temperature. I don’t have imagination enough to turn it into a value though. Also I find them changing too much. My wild guess is that there is also some form of counter or timestamp being sent.
I have another idea of approach. If one enables Cloud for the Meater, it sends the data to an MQTT server on the Internet. Why not just subscribe to that one?
It uses TLS though, and if I understand it correctly I need an authorized client certificate. That sounds like something I should be able to extract from the APK? But I can’t find it. Maybe my knowledge about Android is too low.
I have my Meater+ working with Home Assistant and am currently building a Docker image for my current solution which I will also test with the Meater Block. Alongside this, I am writing an ESPHome integration.
The meater is looking more and more like my father’s day gift this year. How do you like it so far? I’d be interested in testing out your integration if and when I get it. Is it communicating locally with HA or hitting meater’s cloud?
It would be a fantastic fathers day gift. I’ve just got my Meater Block up and running too.
I’m using a Raspberry Pi and a modified version of nathanfaber/meaterble python script to connect to the Meater probe locally, due to this the app won’t work due to the connection limitation. I then pass this data over MQTT. The long term goal would be to work with Meater to make an official integration that allows you to still use their app but still be able to receive tip and ambient temperature in Home Assistant.
Sorry folks, it will be back, but I did hide it.
I just have to tidy up some bits before I put it public again, ill try and do that today.
Im happy to discuss / share what ive found.
But it is 100% protocol buffers, I’ve managed to reverse engineer the proto file sufficiently to send and receive discovery and update packets. in fact I almost have a fully functional esp32 solution, that connects to the probes over BT and sends the data over UDP to your phone (on WIFI).
MQTT to their cloud would be nice, but im trying to navigate away from any potential legal minefields, and I feel like extracting certificates from the APK, and connecting to their cloud is a little more next level. Im much more comfortable reverse engineering unencrypted UDP packets and emulating that protocol.
Regarding using their MQTT. In the end I realized they didn’t have self-signed certificates, I just failed to use my MQTT client correctly with SSL. I have only used it on LAN before and haven’t cared about SSL. This works just fine:
mosquitto_sub -h cloud.meater.com -p 8883 -u 'my-email-address-' -P 'my-meater-password' -t 'MEATERCloud/Devices/some-id-I-dont-know/MASTER' --verbose -d --capath /etc/ssl/certs/
My issue is that I can’t figure out from the code which topics they use. They use some form of unique ID per device/account, and I can’t manage to follow the code to understand it. I have tried everything that looked unique on the stickers of my device without success.
Subscribing to wildcards seems to be disabled, because that surely doesn’t work. If just subscribing to topic test, and then making a publish to that topic, it sure works.
But. If I am not wrong, it’s publishing the same packages to MQTT as it sends via UDP/BT anyway. So the understanding of the protocol is needed regardless. I haven’t been able to confirm this yet though. But, it opens up for three variants to get the same data:
To me Bluetooth is the least attractive option, due to the range issues. I also find it less interesting when using Meater Block.
Man getting this into HA would be so awesome…you guys are the real MVPs
Any updates?
I was able to reverse the probe temperature but I am having a time with the ambient/grill temperature. I used a BLE sniffer to capture the communication between my Meater and an iPhone. Bytes 0 and 1 appear to be a little-endian 16 bit Integer. Here is a Wireshark capture value from yesterday Value: 9e01240009000800. 9E01 decodes to 414.
From the Android decompile I pulled the code
public static int toFahrenheit(int i) {
return ((((i * 9) + 3) / 5) / 16) + 32;
}
Which coverts the integer to 78 Fahrenheit.
Apption Labs released the first version of the MEATER Cloud REST API.
https://github.com/apption-labs/meater-cloud-public-rest-api
I see already some wrappers on github - https://github.com/Sotolotl/meater-python
Someone who can build a custom component for this, i’m willing to help where needed but im a programming n00b
Awesome, you beat me too it - Just received mine today and had already started looking at reverse engineering the BLE - want to integrate it into my home automation system. I have started listening to your github thread…
Any updates on this?
Would really like to see this happen as well! (and a Traeger integration too )
for suresies