Thermoworks RFX Meat Probes and MEATER

[datcomputerguy]

I fell down a rabbit hole yesterday and developed some stuff that you might want to encorporate.
I had been using MEATER for years but their probes kept having issues and so I tried Thermoworks RFX. It was delivered the night before and I was doing my cook yesterday. I was very disappointed in the app, probably because I was spoiled by the fancy flashy gimmicks of MEATER.
So I started with using your HACS integration to get the data and tried to make helpers and it was getting messy so I edited your code to make something that is closer to MEATERish functionality.

Wanted to share what I made so far:
modified files.zip

This still has some things that need to be fixed:

• rate needs to filter out steep drops
• eta needs to have upper bounds defined and show calculating or something when the rate or data is bad
• need to use minimum temp not average (to match thermoworks)
• probably could add some other inputs to generate alarms etc.
• remove debug statements when trying to chase down conversion issues.

Also going to work on making a custom card to combine and recreate the rough idea I made here using multiple card blocks:

[a2hill]

Thanks for the code!

I haven't really given much thought to the dashboarding bits of this as my core use case for developing the integration was about triggering automations in response to temperature changes.

That being said I am interested in pulling something like this in as I understand that there is a desire from RFX owners to not have to use the ThermoWorks app.

I'm a little tied up right now, but I'll take a look at what you've got here soon.

[taw123]

Actually automations is part of what I was thinking as well....

For example a UI that would have a pick list for type of Meat to cook, and next to it channel number, followed by "doneness" (with this beeing PRE-SET to a USER selected default per type of meat- I love all my meat mooing... or better yet as the french would say "Blu")

Then USING that user input would set the channel label for each associated probe along with the Alarm values on the device (in my case Signals). Finally HA would set up notification temps for each active probe entered (user configurable of course, but defaults for 25, 50, 75, 80, 95, 100%).

Finally an option to cancel all notifications, by probe and all probes.

A bit anal but was a chief for years bore becoming an engineer. What do folks think?

[taw123]

@datcomputerguy
One quick question is Ambient temp intended to be the Pit temp? That's what I use my channel 4 probe on my Signals for.

[taw123]

Additional UI cross-pollination from my other attempt to try to get data Locally (rather than rely on polling ThermoWorks cloud servers for data)... Direct radio access via 433 MHz for RDX

Ideally I'dd love to pull this data via wifi LOCALLY rather then have to poll servers in the cloud that ThermoWorks may chose to block us from if load becomes too noticeable....

[a2hill]

Local would be great! You should check out this thread, getting the gateway to run ESPHome might be another way to get at the data

#11

[taw123]

My thoughts off the top of my head, though I have given this some thought previously while searching for a viable solution (your's is CLEARLY the most viable I have seen over the years).

I would not be likely to flash it with ESPhome as I would in all likelihood force it to be a local ONLY device, as I doubt the interfaces to Thermoworks cloud are well enough defined to all for an ESPhome based solution to ALSO push to Thermoworks...

So for me the best solution for Signals would be stock firmware with perhaps a proxy server of some sort running as an integration in Home Assistant. IF that could be done then one could have a local interface via HA, and then the same data published as normal to ThermoWorks (the classic man in the middle attack).... A lot of work for Signal, which is in a sense obsoleatee for me as I plan to go to RDX if and when it will do what I want... (BASICALLY a Smoke with paring to RDX (showing multiple probes with alarms on tthe "gateway" something they are sort of working on))

A better solution be an out of band solution given the multiple transmitters of RDX... I would implement a 433Mhz receiver that would ALSO pair with each of the probes and assuming that tthe connection is NOT exclusive then I would have both a connection via 433 Mhz directly to each probe from HA, and a connection from the individual probes to the Gateway. IDEALLY for power consumption I'd try to see if the probe transmissions can be synchronized like a beacon (since I assume there is no provision of broadcast/multicast in the 433 hmz protocol- though I have yet too look as I don't yet have a RDX device).