I would settle on cloud for something like this.
1 Like
So I'm assuming this hasn't gone any further? I asked the meater people before seeing this thread and they said it was on the road map... But who knows how long.
I'd be happy with cloud integration. One option is to have an Android device using tasker and autoinput do a ui query and return the values shown in the meater app on the device page. This works but needs the string to be modified due to it returning the result with spaces and °c in it but that can be changed... Just seems a little of a dodgy way for me so only did initial trials. Still need to get those values into hubitat.. Which perhaps a http post from tasker may work I guess using maker api in hubitat
need one of these that are zigbee or zwave or wifi with a gateway but i imagine that would eat too much battery. zigbee should work.. then we can integrate with hubitat and have alexa/google tell us when the meat is done. i see they have a wifi gateway .. ive asked support if they have a published api
i could easily write a device handler for this.. using the api.. not sure i want to spend that much though. however i would rather not go into the cloud since it is local.. but i imagine you cannot query the device it just sends it data every so often into the cloud.
So.. it CAN be done, we just need to find someone with the time to do it?
I decided to grab the data from the app (ui query) using tasker as curiosity got the better of me.
It works OK and sends the variables to hubitat through the maker api, but doing this needs to keep the meater app in the foreground.
However I use an Android tablet near my smoker that sends the data to the meater cloud anyway as the Bluetooth range without their repeater is pour. So that tablet is already acting like a repeater near the smoker anyway so leaving the hubitat app open and the screen on is not a big deal... However still a bodgy way of doing it... Just my coding knowledge isn't good enough to work with an api just yet.
I backed it in kick starter in the early days when they were somewhat more affordable.. I have used my single probe a lot and I too was wondering if I'd get my moneys worth. The battery life of the probe is good and the data is reliable. Just the price and the limited range without the repeater they now have (didn't have that originally on kickstarter campaign) are the negatives. The latter can be easily worked around with with a repeater or a second device that sends the data to the cloud.
Waay off topic, but I had my carotid arteries cleaned out a few years ago. One was 80% blocked and the other was 70% blocked. My vascular surgeon said it was plaque buildup from years and years of eating meat.
Something to think about. Had a TIA and was fortunate there was no loss of motor skills nor slurred speech.
2 Likes
if some one wants to send me one i dont think it needs to be on the wifi device to write the app. i can try to write a driver. you pay shipping and ill send it back when done.. my understanding is both bluetooth and wifi are in the same cloud so it doesnt matter.. For me id only buy the block so i dont rely on bluetooth that is why its so expensive..
I'm assuming that no one integrated the meater probe into hubitat seeing this went quiet? The api seems like a good way for me... Which means using a device getting it to cloud which is fine for me.. But likely beyond my current capabilities, well more how much time I'd need to spend on it without a good guide.
1 Like
Seems like there's a lot of info here and achievable. And if I was more of a programmer it may have been a walk in the park ha ha.. I have some idea.. So maybe I'll have a crack... Maybe I'll realise it's too much effort... I haven't even written a basic app for hubitat so likely in over my head. Edit: seems like this is likely a driver.. Hmm
1 Like
Ok so after a little effort looking at the api page above and reading a little about http get in hubitat... I've got no where ha ha. Never written a driver before, have barely had any experience with http get. So a little over my head I think. I copied some driver code for a http get in hubitat and edited it but can't get it to work.
I'm sure it's a simple thing seeing the api is clearly documented. Just a little outside my knowledge for now and have a feeling it'll take a long time for me to get my head around.
All I want ideally is to http get to the meater cloud, grab the temperature of the probe (and then I'll grab the other attributes available) and put them in a device states.. Can't be that hard right.. Hmm. Http get, parse the json reeponse to different states.. Done ha ha
I’ve got a MEATER+ and am going to look into this. First pass, it looks straightforward. Will update if/when I’ve got something working.
2 Likes
Thank you
Great, thanks. My basic attempts have led me to realise I need to read/learn much more before I could pull this off.
@frmWink2Hubitat @peterbrown77.pb
See how this works for you:
Install:
- Add Parent Device code and Child Device code on the Device Code page
- Add virtual device of type "Meater Parent Device"
- Fill in the email field and the password field in the Preferences section of the Meater Parent Device
- Click Save Preferences
That should do it. A child device will be created under the parent device for each Meater probe that you have on your account. A child device will be "on" if the corresponding Meater probe is online, and "off" if the probe is offline. The parent device will be "on" if any child device is on. Each child device should have these attributes:
Let me know how this works for you. If it works well for you, I'll release it more widely.
4 Likes
Wow just wow. I have a smoker I'll be doing tomorrow so I'll be sure to check it out then. My other temp probe for meat using an esp8266 was questionable for accuracy last cook (and hard to deal with wires) so this is great timing..
Well I haven't tried a cook yet but your drivers work well for me. Thanks so much for sharing. The probes aren't cheap, but they are so hand for smokers, rotisserie etc.
The previous way I used to get them into hubitat was pretty unreliable, which was a tablet with tasker than read the screen values and past them into hubitat. Wasnt reliable and practical as the screen had to stay on.
This is heaps better and means I use my meater again for the smoker as the rest of the smoker is tasmota based (temp control by a pwm fan and thermocouple for feedback). But to have the food probes wireless is much more practical, and on some cases the only way.
What sort of use cases do you use your integration for anyways? The way I’m looking forward to using this is announcing cook progress on my Sonos speakers everywhere, including on my landscape speakers, so I don’t miss a phone notification. But I’m guessing you’ve got some good ideas about how else to use this.
My uses are mainly monitor internal temp (and now cook time remaining seeing meater had that) on a dashboard. That same dashboard sets the tasmota (looking at changing that to hubduino) device target temp to change speed for a pwm fan to fuel the charcoal burning smoker when needed. A few other settings to adjust the sensitivity/gain of the fan response.
I'll also do similar for the rotisserie but that pushes cold air in to keep temperatures right rather than using the air to fuel the fire/heat.
I may even move the temp feedback to come from the meater ambient temp instead of the thermocouple attached the tasmota/hubduino device..
All my logic/program are in hubitat rules rather than on the esp device seeing timing isn't critical
1 Like
