Thank you, that is great… I would like to get one of this probes, but I didn’t need the 4 probes pack, but would like to integrate into home assistant and nodered… The only option with wifi is the block. With this solution that is great!
Tks
Thanks for taking the time to test it.
I just read the release notes for next version of Home Assistant and it seams that this meater integration won’t be included yet. Any way for us regular users to test this integration without compiling Home Assistant from source? Like downloading it as “custom component” or similar?
Thanks and best regards.
You can download it from @Sotolotl’s branch here and add it as a custom component.
1 Like
How? Just copying the folder will do nothing.
Copy the meater folder from the components directory in the branch above and put it in your custom_components folder and restart.
Works now - had to restart twice - very cool!
Thank you @floyduww and Sotolotl
I have a meater plus
I installed the Sotolotl meater integration
It asked me to login to my meater account, so is that integration working by fetching data from the cloud?
I am also running Meater app on my phone,
I am running the docker container for the Meater MQTT app
However I see the following in the MQTT
Which suggests that the App’s mqtt connection is working, but it’s not able to connect to the phone
How does it connect to the phone? What are the requirements?
the HASS integration is showing the correct temperatures
But I suspect the meater mqtt app is not getting the correct data
0a1308caa801100c18032001292a00000000000000
Move along
-----------------
len(packet)=2
len(packet[0])=21
len(packet[1])=2
('10.1.1.8', 7878)
0a1308caa801100c18032001292a00000000000000
---meater_link---
device {
part1: 21578
part2: 12
device_type: 3
inc: 1
device_mac: 42
}
0a1308caa801100c18032001292a00000000000000
Move along
-----------------
len(packet)=2
len(packet[0])=21
len(packet[1])=2
('10.1.1.8', 7878)
0a1308caa801100c18032001292a00000000000000
---meater_link---
device {
part1: 21578
part2: 12
device_type: 3
inc: 1
device_mac: 42
}
Can you shed some light please?
Thanks
Are your phone and docker container on the same class C network. My app sees it’s own broadcasts and that is what you are seeing there.
Thanks @floyduww
Yes, docker host and my phone are on the same class C network
And the docker container network settings is set to host
I am able to ping from the container to the phone, I know that doesn’t mean much, other than prove that it is reachable from the container.
On your docker host can you do a tcpdump watching for source port 7878. My only thought is that something is blocking the traffic.
When I run tcpdump src port 7878 it’s binding to interface veth669d6cd
/meater # tcpdump src port 7878
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on veth669d6cd, link-type EN10MB (Ethernet), capture size 262144 bytes
But that interface is not the right interface
ifconfig shows that it should be enp37s0
veth669d6cd Link encap:Ethernet HWaddr 92:35:56:16:B4:BE
inet6 addr: fe80::9035:56ff:fe16:b4be/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:46563 errors:0 dropped:0 overruns:0 frame:0
TX packets:44042 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:4399511 (4.1 MiB) TX bytes:13758167 (13.1 MiB)
enp37s0 Link encap:Ethernet HWaddr 10:1F:74:E3:4D:50
inet addr:10.1.1.8 Bcast:10.1.1.255 Mask:255.255.255.0
inet6 addr: fe80::bc14:875f:714f:90c1/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:73073866 errors:0 dropped:0 overruns:0 frame:0
TX packets:23322283 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:32823258148 (30.5 GiB) TX bytes:4680878069 (4.3 GiB)
If I do tcpdump src port 7878 -i enp37s0
I get
/meater # tcpdump src port 7878 -i enp37s0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp37s0, link-type EN10MB (Ethernet), capture size 262144 bytes
02:25:48.549294 IP probook.7878 > 255.255.255.255.7878: UDP, length 41
02:25:53.554583 IP probook.7878 > 255.255.255.255.7878: UDP, length 41
02:25:58.561293 IP probook.7878 > 255.255.255.255.7878: UDP, length 41
02:26:03.568666 IP probook.7878 > 255.255.255.255.7878: UDP, length 41
02:26:08.576206 IP probook.7878 > 255.255.255.255.7878: UDP, length 41
02:26:13.583093 IP probook.7878 > 255.255.255.255.7878: UDP, length 41
02:26:18.590699 IP probook.7878 > 255.255.255.255.7878: UDP, length 41
02:26:23.596501 IP probook.7878 > 255.255.255.255.7878: UDP, length 41
02:26:28.602374 IP probook.7878 > 255.255.255.255.7878: UDP, length 41
02:26:33.608991 IP probook.7878 > 255.255.255.255.7878: UDP, length 41
02:26:38.614944 IP probook.7878 > 255.255.255.255.7878: UDP, length 41
02:26:43.621917 IP probook.7878 > 255.255.255.255.7878: UDP, length 41
02:26:48.628963 IP probook.7878 > 255.255.255.255.7878: UDP, length 41
02:26:53.634275 IP probook.7878 > 255.255.255.255.7878: UDP, length 41
02:26:58.638940 IP probook.7878 > 255.255.255.255.7878: UDP, length 41
02:27:03.644313 IP probook.7878 > 255.255.255.255.7878: UDP, length 41
02:27:08.650270 IP probook.7878 > 255.255.255.255.7878: UDP, length 41
02:27:13.656888 IP probook.7878 > 255.255.255.255.7878: UDP, length 41
So it looks like there is no response back from the phone.
even running tcpdump on the router / gw
I don’t see the responses
sudo tcpdump -npi eth1 port 7878
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
21:33:34.134240 IP 10.1.1.8.7878 > 255.255.255.255.7878: UDP, length 41
21:33:39.141447 IP 10.1.1.8.7878 > 255.255.255.255.7878: UDP, length 41
21:33:44.147362 IP 10.1.1.8.7878 > 255.255.255.255.7878: UDP, length 41
21:33:49.154351 IP 10.1.1.8.7878 > 255.255.255.255.7878: UDP, length 41
21:33:54.160819 IP 10.1.1.8.7878 > 255.255.255.255.7878: UDP, length 41
21:33:59.167400 IP 10.1.1.8.7878 > 255.255.255.255.7878: UDP, length 41
21:34:04.173596 IP 10.1.1.8.7878 > 255.255.255.255.7878: UDP, length 41
21:34:09.179154 IP 10.1.1.8.7878 > 255.255.255.255.7878: UDP, length 41
Even on the phone itself, I don’t see anything
redfin:/ # tcpdump port 7878
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlan0, link-type EN10MB (Ethernet), capture size 262144 bytes
21:36:28.941667 IP 10.1.1.8.7878 > 255.255.255.255.7878: UDP, length 41
21:36:33.535731 IP 10.1.1.8.7878 > 255.255.255.255.7878: UDP, length 41
21:36:38.764930 IP 10.1.1.8.7878 > 255.255.255.255.7878: UDP, length 41
21:36:43.672387 IP 10.1.1.8.7878 > 255.255.255.255.7878: UDP, length 41
21:36:48.502715 IP 10.1.1.8.7878 > 255.255.255.255.7878: UDP, length 41
Meater app version 2.5
Is there a way to use the custom component without meater cloud? because the script above in this thread works with meater only in local network …
No. The component that Sotolotl has submitted a PR for is using the Meater API.
Is there any way to get the “Target” temperature? Or only internal and ambient is possible with the API?
Thanks and best regards
Yes, Target is provided by the API. As is Cook Peak, Elapsed Cook Time, Cook Time Remaining, Cook Status, and Cook Name.
1 Like
Thanks, do you happen to know if the integration supports it? From what I can see only Internal and Ambient temperature are created automatically. Can I set up some template sensors to extract the remaining data?
Only Ambient and Internal are exposed in the current PR. I’m not sure if adding the rest is on @Sotolotl’s radar or not, I have most of the code done to add the cook sensors but it’s his project.
1 Like
Meater should be integrated to ESPHome to get better range.
Is there any template to this? Is it with esp32?