RT-700 LocalTuya Control — What Finally Worked for Me
Bringing this thread back from the dead because I finally got an RT-700 (Bull) working properly. There were a few questions in this thread that never really got answered, so hopefully this helps the next person.
Short version: Use the xZetsubou fork of LocalTuya, not rospogrigio’s. The local key is no longer in the old cache location, and you need to set hvac_mode_dp on the climate entity or it will sit at unknown.
The LocalTuya fork matters
There are two LocalTuya repos. They use the same HA domain, so you can only have one installed, and they don’t behave the same.
I originally used rospogrigio’s because that’s what most of the older guides point to. Reading worked fine — temperatures and probes showed up — but writes did nothing.
I could set the temperature and nothing happened. Turn it off and nothing happened.
I was also getting the entities going unavailable for a second or two every 60 seconds, with this in the log:
Disconnected - waiting for discovery broadcast
I spent a lot of time thinking Recteq had blocked local writes in a firmware update. That turned out to be wrong.
I switched to xZetsubou/hass-localtuya and the first write gave me an actual error pointing to the problem. The 60-second disconnects also stopped completely.
So if you’re following an older guide and writes silently do nothing, check which LocalTuya fork you’re using before blaming the grill.
Getting the local key
This also came up earlier in the thread.
The old path that is referenced in a lot of guides is:
/sdcard/Android/data/com.ym.rectecgrill/cache/1.abj
That file isn’t there in current versions of the Recteq app.
The key is now stored in the app’s private storage:
/data/data/com.ym.rectecgrill/shared_prefs/tuya_Home.xml
You need root access to get to it.
Rather than relying on a specific filename or path, I found it easier to search the app’s data:
adb root
adb shell 'grep -rl "localKey" /data/data/com.ym.rectecgrill/ 2>/dev/null'
Then pull the file and parse the XML/JSON to get the key.
One thing that caught me: don’t pipe the file through cat or tr while extracting it. That can mangle the bytes and make a perfectly good key look corrupted.
My key actually contained a literal ? twice, along with {, <, and >. I initially thought it was bad until I checked the bytes and confirmed it was a valid 16-byte ASCII key.
Also, you do not need to unpair the grill from the Recteq app to do this. You can use the Recteq app on another device or an emulator to access its storage without changing the grill’s pairing.
Does the RT-700 actually work?
Yes.
I’m able to control:
- Power / remote start
- Target temperature
- Current grill temperature
- Both meat probes
- Feed rate
I’m also able to start the grill from an HA dashboard button. I verified that the state actually changed on the grill itself and wasn’t just changing optimistically in the HA UI.
Protocol is 3.3 on port 6668.
Datapoints
The current firmware on my RT-700 exposes these:
| DP | What it is | Access |
|---|---|---|
| 1 | Power / remote start | Read/Write |
| 102 | Target temperature °F | Read/Write |
| 103 | Current grill temperature °F | Read |
| 104 | Feed rate | Read |
| 105 | Probe A °F | Read |
| 106 | Probe B °F | Read |
| 107 | Unknown | Read |
| 109 | Unknown | Read |
| 110 | Unknown | Read |
| 111 | Unknown | Read |
DP 103 returns null when the grill is off. That’s normal.
Fan control
For the RT-700, I don’t see a fan datapoint.
Those ten DPs appear to be everything the grill exposes. The fan doesn’t appear to be independently controllable through LocalTuya; fan control is handled by the grill’s controller.
If anyone sees an additional DP on a different RT model, I’d be interested in seeing it.
DP104 is the feed rate
This took me longer than it should have.
DP104 is the 1-AUG setting from the grill controller menu.
The range is 30–250.
The grill controller displays the full value, while the app displays it divided by 10.
For example:
Controller: 65
App: 6.5
The app also won’t let me set it below 6.5, so anything lower has to be set directly on the grill controller.
If you want LocalTuya to display it like the app, set the sensor scaling to:
0.1
That gives you 3.5 instead of 35, for example.
It’s a setting, not a live reading, so don’t expect it to change while you’re cooking.
Climate entity configuration
There are two things that can trip you up here.
1. You need hvac_mode_dp
If you only configure the id, the climate entity can end up with:
hvac_modes: null
and remain unknown.
The temperature DPs can be reading perfectly, but Home Assistant doesn’t know how to map the on/off state.
This is what worked for me:
id: "1"
hvac_mode_dp: "1"
hvac_mode_set: {"off": false, "heat": true}
target_temperature_dp: "102"
current_temperature_dp: "103"
min_temperature: 180.0
max_temperature: 500.0
temperature_unit: "fahrenheit"
temperature_step: "1"
precision: "1"
target_precision: "1"
heuristic_action: true
2. Make sure your temperature limits are actually Fahrenheit
After switching LocalTuya forks, my min/max values silently reverted to the Celsius defaults of 7 and 35.
That resulted in:
ServiceValidationError: Provided temperature 235.0 is not valid. Accepted range is 7 to 35
That’s Home Assistant rejecting the value before the command ever reaches the grill.
It’s easy to mistake that for the grill rejecting the command.
The important parts are:
min_temperature: 180.0
max_temperature: 500.0
temperature_unit: "fahrenheit"
The temperature_unit setting tells LocalTuya what units the device is actually using. It’s not just a display preference.
If you’re converting an old LocalTuya configuration
If you’re coming from rospogrigio’s version, some of the configuration field names are different.
For example:
min_temperature
instead of:
min_temperature_const
And:
hvac_mode_set: {"off": false, "heat": true}
rather than the older string format.
DP references are also just:
"1"
rather than something like:
"1 (value: True)"
Using the old format caused my setup to fail with:
'str' object has no attribute 'copy'
One other tip: after saving the configuration, check the actual entity state. The config flow can report success even when the entity itself failed to set up. I got caught by that more than once.
The Fahrenheit issue from earlier in the thread
The old problem where setting something like 230 resulted in the grill trying to go to 600 is a unit-conversion issue.
What fixed it for me was explicitly telling LocalTuya that the device uses Fahrenheit and giving it the correct Fahrenheit range:
temperature_unit: "fahrenheit"
min_temperature: 180.0
max_temperature: 500.0
My Home Assistant installation uses imperial units, so I haven’t tested the opposite scenario where HA is configured for Celsius but the grill itself is Fahrenheit.
The probe sensors are normal HA sensor entities, so their displayed units can be adjusted separately.
If anyone is running a metric HA setup with an RT-700, I’d be interested in hearing how the climate entity behaves.
If you’re using an Android emulator to get the key
I also ran into a couple of things here that weren’t obvious from the older guides.
Use an Android 11 image, not Android 10.
The Recteq app is ARM-based. With an x86_64 Android 10 image, the app may show as unsupported because there isn’t the ARM translation you need.
Android 11 / API 30 worked for me and also gave me the adb root access I needed.
Once installed, I initially ran into this crash when trying to log in:
java.lang.UnsatisfiedLinkError: dlopen failed:
".../com.google.android.gms/.../x86_64/libcronet.<ver>.so"
is for EM_X86_64 (62) instead of EM_AARCH64 (183)
The problem was Google Play Services trying to load its x86_64 Cronet library while the Recteq app was running as ARM under translation.
The workaround that worked for me was:
adb shell pm disable-user --user 0 com.google.android.gms
adb shell pm clear com.ym.rectecgrill
After that I was able to log into the Recteq app and retrieve the key.
Once you have the key, delete the emulator or at least close the Recteq app. Tuya devices only allow one local connection at a time. A forgotten emulator, phone app, or another local Tuya script can grab the connection and make Home Assistant look broken.
One last thing about the HA UI
The Home Assistant climate card is optimistic.
You can press Off and the tile immediately shows Off, even if the grill never actually received the command. The next poll can then change it back.
I got fooled by this more than once.
When troubleshooting, don’t rely on what the tile says. Check the actual device state, raw_state, or the recorder history.
Also remember the single local connection limitation. Your phone’s Recteq app, an emulator, or a tinytuya script can all grab the connection and make the LocalTuya integration look like it’s randomly disconnecting.
Credit
This thread, along with goldbattle’s gist, helped me figure out the original DP mapping. SDNick484’s repo was also what pointed me toward the fact that these grills are Tuya-based.
Just keep in mind that some of those older references are now several years old and parts of the app/integration have changed.
Hopefully this saves someone else a day of chasing the wrong problem.
If anyone gets this working on another Recteq model, I’d be interested to know whether the DP numbers are the same, especially whether DP104 is the feed rate on yours.
