Hi floyduww;
Never thought about the second bluetooth! Will try experiment tomorrow and report back!
@floyduww
āMeater +ā been used.
Iām using an Ipad as a slave (IP .72) and iPhone as master (.160). With Bluetooth OFF using the Meater Link on the slave and invoking the app on the slave, I too donāt seem to be receiving any different data than what @matticas has been seeing. Iām not sure how the slave can be receiving any data other than via Wifi, although as you stated earlier it not all the possible/available data. I donāt have the tools to determine which port the data is being received on, but It doesnāt appear to be 7878.
Also, what I have noticed is that @ byte 9 ādevā is x04 which I assume is the ID for the āMeater +ā device.
On a separate note, I donāt receive any MQTT topics or data at my Broker relater to Meater + device.
len(packet)=2
len(packet[0])=47
len(packet[1])=2
('192.168.1.72', 7878)
b'\n\x13\x08\xca\xa8\x01\x10\x0c\x18\x04 \x04)lG\xbfT\xa4\xe9\xeb%\x12\x18\x10\x01"\x07iPad5,3*\x052.5.12\x0413.6'
0a 13 08 ca a8 01 10 0c 18 04 20 04 29 6c 47 bf 54 a4 e9 eb 25 12 18 10 01 22 07 69 50 61 64 35 2c 33 2a 05 32 2e 35 2e 31 32 04 31 33 2e 36
{'offset': 61, 'end': 62, 'bc': 0, 'data': b'', 'batt': 0, 'sig': '', 'cooking': '', 'm_temp': 24, 'a_temp': 24, 'version': '', 'targ_temp': 17, 'cook_name': '', 'meat_type': ''}
{'offset': 65, 'end': 66, 'bc': 0, 'data': b'', 'batt': 0, 'sig': '', 'cooking': '', 'm_temp': 24, 'a_temp': 24, 'version': '', 'targ_temp': 17, 'cook_name': '', 'meat_type': ''}
{'offset': 69, 'end': 70, 'bc': 0, 'data': b'', 'batt': 0, 'sig': '', 'cooking': '', 'm_temp': 24, 'a_temp': 24, 'version': '', 'targ_temp': 17, 'cook_name': '', 'meat_type': ''}
{'offset': 73, 'end': 74, 'bc': 0, 'data': b'', 'batt': 0, 'sig': '', 'cooking': '', 'm_temp': 24, 'a_temp': 24, 'version': '', 'targ_temp': 17, 'cook_name': '', 'meat_type': ''}
1 Like
Is it possible to capture all UDPās ? Without defining a port number?
Since the code is not receiving any probe data it will not send anything to mqtt. And I still have no clue how Meater+ (or single probe) data gets sent between 2 devices running the app aka Meater Link.
@matticas With a tcpdump it will show all traffic tcp and udp regardless of port. And for me I saw none of it, but have not been able to test since my bluetooth off idea.
will try now, give me 20min
(iām hoping my remote TCPdump works on wifi AP)
here is my basic tcpdump:
ssh USER@AP_IP_ADDR 'tcpdump src 192.168.10.16 -w -' >block.dump
1 Like
This was from Wireshark; master phone = .74, slave = .24.
Started dump, opened master app, turned on probe, opened slave app, setup cook, finish dump.
+---------+---------------+----------+
21:35:46,145,485 ETHER
|0 |ff|ff|ff|ff|ff|ff|ce|33|42|dc|41|69|08|00|45|00|00|60|9f|30|40|00|40|11|d9|6a|c0|a8|01|4a|ff|ff|ff|ff|1e|c6|1e|c6|00|4c|0c|e2|0a|13|08|ca|a8|01|10|0c|18|01|20|01|29|9a|6d|69|fa|f1|60|f8|29|12|2d|0a|10|2c|ef|e7|37|91|78|20|ee|7f|7d|dc|cb|a1|16|11|5e|10|02|22|0e|47|6f|6f|67|6c|65|20|50|69|78|65|6c|20|35|2a|03|32|2e|35|32|02|31|31|
+---------+---------------+----------+
21:35:52,163,013 ETHER
|0 |ff|ff|ff|ff|ff|ff|ce|33|42|dc|41|69|08|00|45|00|00|58|a2|e2|40|00|40|11|d5|c0|c0|a8|01|4a|ff|ff|ff|ff|1e|c6|1e|c6|00|44|aa|b7|0a|13|08|ca|a8|01|10|0c|18|01|20|02|29|9a|6d|69|fa|f1|60|f8|29|12|25|0a|08|7f|7d|dc|cb|a1|16|11|5e|10|02|22|0e|47|6f|6f|67|6c|65|20|50|69|78|65|6c|20|35|2a|03|32|2e|35|32|02|31|31|
+---------+---------------+----------+
21:35:58,169,383 ETHER
|0 |ff|ff|ff|ff|ff|ff|ce|33|42|dc|41|69|08|00|45|00|00|4e|a4|b2|40|00|40|11|d3|fa|c0|a8|01|4a|ff|ff|ff|ff|1e|c6|1e|c6|00|3a|7a|e3|0a|13|08|ca|a8|01|10|0c|18|01|20|03|29|9a|6d|69|fa|f1|60|f8|29|12|1b|10|02|22|0e|47|6f|6f|67|6c|65|20|50|69|78|65|6c|20|35|2a|03|32|2e|35|32|02|31|31|
+---------+---------------+----------+
21:36:04,151,141 ETHER
|0 |ff|ff|ff|ff|ff|ff|ce|33|42|dc|41|69|08|00|45|00|00|4e|a8|27|40|00|40|11|d0|85|c0|a8|01|4a|ff|ff|ff|ff|1e|c6|1e|c6|00|3a|7a|db|0a|13|08|ca|a8|01|10|0c|18|01|20|0b|29|9a|6d|69|fa|f1|60|f8|29|12|1b|10|02|22|0e|47|6f|6f|67|6c|65|20|50|69|78|65|6c|20|35|2a|03|32|2e|35|32|02|31|31|
Will PM file of AP dump
Edit; the packets were broadcast to 255.255.255.255 on 7878
Doing another test without internet connected, Just want to check random data to an AWS server
Got you! For what its worthā¦ one observation Iāve just seen while running your code. There is an error on line 214. Not sure what this is attributed toā¦ seems to be related to BLOCK_UDP_PORT being already in use. Any ideas?
Ok, this has me f-d. Zero change when no internet connected, literally only 2 packets from my phone on the AP yet I set up the cook, change the temp multiple times and yet saw no data on the network, and the slave phone responded instantly. 
That was my first thought, Iāve checked but will review that again. Thanks
Just downloaded the APK and started sniffing through. Appears to use MQTT with itās own broker I assume. Here is one of the files inside the APK;
0=MQTT Catalog
101=<init> ClientID={0} ServerURI={1} PersistenceType={2}
103=cleanSession={0} connectionTimeout={1} TimekeepAlive={2} userName={3} password={4} will={5} userContext={6} callback={7}
104=> quiesceTimeout={0} userContext={1} callback={2}
105=< exception
106=Subscribe topicFilter={0} userContext={1} callback={2}
107=Unsubscribe topic={0} userContext={1} callback={2}
108=<
109=<
110=<
111=< topic={0} message={1}userContext={1} callback={2}
112=<
113=<
114=>
115=URI={0}
116=URI={0}
117=>
118=<200=internalSend key={0} message={1} token={2}
204=connect failed: rc={0}
207=connect failed: not disconnected {0}
208=failed: not connected
209=connect failed: unexpected exception
210=failed: called on callback thread
211=failed: already disconnected
212=connect failed: unexpected exception
213=fail: token in use: key={0} message={1} token={2}
214=state=CONNECTING
215=state=CONNECTED
216=state=DISCONNECTING
217=state=DISCONNECTED
218=state=DISCONNECTING
219=failed: already disconnecting
220=>
221=>
222=>
223=failed: in closed state
224=failed: not disconnected
250=Failed to create TCP socket
252=connect to host {0} port {1} timeout {2}
260=setEnabledCiphers ciphers={0}
300=key={0} message={1}
302=existing key={0} message={1} token={2}
303=creating new token key={0} message={1} token={2}
305=> {0} tokens
306=key={0}
307=key={0} token={1}
308=<>
309=resp={0}
310=>
311=>
312=>
400=>key={0} timeout={1} sent={2} completed={3} hasException={4} response={5} token={6}
401=failed with exception
402=key={0} response={1}
403=> key={0}
404=>key={0} response={1} excep={2}
406=key={0} timed out token={1}
407=key={0} wait max={1} token={2}
408=key={0} wait max={1}
409=wait key={0}
410=> key={0}
411=>key={0} response={1} excep={2}
500=Attempting to reconnect client: {0}
501=Automatic Reconnect Successful: {0}
502=Automatic Reconnect failed, rescheduling: {0}
503=Start reconnect timer for client: {0}, delay: {1}
504=Stop reconnect timer for client: {0}
505=Rescheduling reconnect timer for client: {0}, delay: {1}
506=Triggering Automatic Reconnect attempt.
507=Client Connected, Offline Buffer available, but not empty. Adding message to buffer. message={0}
508=Client Resting, Offline Buffer available. Adding message to buffer. message={0}
509=Client Reconnected, Offline Buffer Available. Sending Buffered Messages.
510=Publising Buffered message message={0}
511=outbound QoS 0 publish key={0} message={1}
512=QoS 0 publish key={0}
513=Persisted Buffered Message key={0}
514=Failed to persist buffered message key={0}
515=Could not Persist, attempting to Re-Open Persistence Store
516=Restoring all buffered messages.
600=>
601=key={0} message={1}
602=key={0} exception
603=clearState
604=inbound QoS 2 publish key={0} message={1}
605=outbound QoS 2 pubrel key={0} message={1}
606=outbound QoS 2 completed key={0} message={1}
607=outbound QoS 2 publish key={0} message={1}
608=outbound QoS 1 publish key={0} message={1}
609=removing orphaned pubrel key={0}
610=QoS 2 publish key={0}
611=QoS 2 pubrel key={0}
612=QoS 1 publish key={0}
613= sending {0} msgs at max inflight window
615=pending send key={0} message {1}
616=checkForActivity entered
617=+1 inflightpubrels={0}
618=key={0} QoS={1}
619=Timed out as no activity, keepAlive={0} lastOutboundActivity={1} lastInboundActivity={2} time={3} lastPing={4}
620=ping needed. keepAlive={0} lastOutboundActivity={1} lastInboundActivity={2}
621=no outstanding flows and not connected
622=inflight window full
623=+1 actualInFlight={0}
624=Schedule next ping at {0}
625=key={0}
626=quiescing={0} actualInFlight={1} pendingFlows={2} inFlightPubRels={3} callbackQuiesce={4} tokens={5}
627=received key={0} message={1}
628=pending publish key={0} qos={1} message={2}
629=received key={0} token={1} message={2}
630=received bytes count={0}
631=connected
632=reason {0}
633=disconnected
634=ping not needed yet. Schedule next ping
635=ping sent. pingOutstanding: {0}
636=ping response received. pingOutstanding: {0}
637=timeout={0}
638=notifying queueLock holders
639=wait for outstanding: actualInFlight={0} pendingFlows={1} inFlightPubRels={2} tokens={3}
640=finished
641=remove publish from persistence. key={0}
642=Timed out as no write activity, keepAlive={0} lastOutboundActivity={1} lastInboundActivity={2} time={3} lastPing={4}
643=sent bytes count={0}
644=wait for new work or for space in the inflight window
645=removed QoS 2 publish/pubrel. key={0}, -1 inFlightPubRels={1}
646=-1 actualInFlight={0}
647=new work or ping arrived
648=key{0}, msg={1}, excep={2}
649=key={0},excep={1}
650=removed Qos 1 publish. key={0}
651=received key={0} message={1}
659=start timer for client:{0}
660=Check schedule at {0}
661=stop
662=no message found for ack id={0}
700=stopping
701=notify workAvailable and wait for run
703=stopped
704=wait for workAvailable
705=callback and notify for key={0}
706=notify spaceAvailable
708=call connectionLost
709=wait for spaceAvailable
710=new msg avail, notify workAvailable
711=quiesce notify spaceAvailable
713=call messageArrived key={0} topic={1}
714=callback threw exception
715=new workAvailable. key={0}
716=call onSuccess key={0}
717=call onFailure key {0}
719=callback threw ex:
720=exception from connectionLost {0}
800=stopping sender
801=stopped
802=network send key={0} msg={1}
803=get message returned null, stopping}
804=exception
805=<
850=stopping
851=stopped
852=network read message
853=Stopping due to IOException
854=<
855=starting
856=Stopping, MQttException
Edit; still canāt see packets on network. Convinced iām not doing the dump correctly. Work on this later tonight.
I believe that app sends data to the meater cloud via mqtt. And the meater cloud uses AWS.
But I disconnected my internet and the appās were still talking to each other?
@matticas More fun with tcpdump. I think we have both been watching the wrong interfaces on our wireless AP. I donāt have a second device for meater link at the moment but could see different traffic between my FireTV sticks. The default tcpdump only watches eth0. However if both devices are wireless traffic does not need to go through eth0. For me wireless traffic would be seen on br0. Use the ā-i br0ā flag in tcpdump to change interfaces.
@floyduww thanks for this info. I have ubiquiti APās and at the time of test both phones were connected to the same AP, and the remote TCPdump (via wireshark) could choose interface, which I chose ath0. The other option been eth0. I figured all traffic would be routed via the wireless interface and therefore capture it. My only other option is to have one device on the other AP (about 50m away) and see if I notice anything different.
Still, even with the internet modem turned off, the appās were communicating instantly and I couldnāt see any packets. I sent a help request to Meater, maybe theyāll help?? Maybe if I explain the HA community and growth, been integrated may increase sales?
I too use Ubiquiti. I ran ip addr (or ifconfig) to find all available interfaces. And ran tcpdumps until I only saw wireless to wireless traffic, which I found on br0. I just got a second device and finally saw the traffic. It starts with the broadcast and the does direct IP to IP on port 7878. I have not pulled out all the traffic to find the initial handshake.
So I ran 2 tests, one with the modem connected to the interwebz, one without. Also, the master was on itās own AP, the slave on the common AP.
The one with working internet, the app pings an AWS server 54.214.59.105, confirmed from packets, IP lookup, and my pihole DNS requests for api.cloud.meater.com
The second test without www, heaps of UDPās were found on port 7878, some broadcast, but many direct. Can I send you the wireshark file to go through? I canāt see the target temp changes I was messing with.