Wait, they exposed and API? I didn’t realize they had done that so I am starting to dig into it, what will certainly follow is my notes / questions.
@martyndix I see you’re already ahead of me here your panel has used it as an optional cloud fallback for map/plan reads since v1.2.0. I pulled this API/SDK apart and the results speak to what several people asked for in this thread, so here’s the full inventory.
What it gives you, please correct me if I am wrong
Login with your Yarbo account, list devices, then live MQTT telemetry: 43 defined fields covering battery (capacity, health, voltage, current, all six cell temps), working state, error codes, stuck, person/obstacle detection, plan status with detailed error codes, pause reason (manual vs low battery vs stuck), WiFi/4G/HaLow signal and which is active, RTK quality and satellite count, position and heading, ambient temp, rain sensor, head type/serial, and firmware versions. On demand you can pull a full status snapshot, GPS reference origin, the map, and all saved plans. Commands: standby/working, start plan by ID (including at a %), pause, resume, stop, return to charge, lights, sound/volume, child lock, geofence, obstacle settings, blade height and speed, chute angle.
@jason.michas your GeoJSON request is exactly half-answered I think…
Export already exists, officially: convert_map_to_geojson() turns the map into a proper FeatureCollection,work areas, no-go zones, no-vision zones and geofence as polygons, pathways/sidewalks/deadends as linestrings, charging stations as points, converted to real lat/lon, with zone IDs and names preserved in the properties. That is genuinely everything you need for the read side of a map editor.
Import does not exist. I checked all 24 command topics in the SDK and not one of them writes, saves or uploads map data. Plans are the same, readable and startable by ID, not creatable or editable. So the half of your idea that’s blocked is exactly the half that matters, and it’s blocked deliberately.
@rgloverii, @Stoneslinger76 on local control, don’t get your hopes up here I see no way this is coming anytime soon, but I WISH!
The official SDK is cloud only. REST login to Yarbo’s servers, then MQTT over TLS to their brokers. It is not a local path and can’t be configured into one.
More to the point: it’s actually more limited than what martyndix already built. The topic structure is identical on both paths, but his local panel sends commands the official SDK simply doesn’t expose – manual drive (cmd_vel), buzzer, plan deletion, controller hold. None of those exist in the SDK’s command list. So on the local-vs-cloud question, local is already the more capable route.
@martyndix one lead on your map upload problem.
That gap cuts both ways. The fact that local MQTT accepts del_plan and cmd_vel while the cloud SDK exposes neither means the robot’s real command surface is wider than the official library admits. It doesn’t prove a map-write command exists — but it does mean “the SDK doesn’t have it” isn’t evidence that it’s impossible. If such a command is in the firmware, local is far likelier to accept it than cloud, since the cloud broker enforces a server-side permission list (the SDK’s own source notes that unrecognised topics get rejected by the EMQX ACL). Worth aiming your reverse engineering at the local broker rather than the cloud one.
On the camera: nothing in the SDK either. 43 telemetry fields, 24 commands, zero video. Your read that Yarbo hasn’t opened it up looks right.
Other limits worth knowing: commands are fire-and-forget (published at QoS 0, every command documented as returning no confirmation you have to poll status to see whether it took), auth is your account password with no API keys or read-only tokens, only one device type is defined, and the docs are largely in Chinese (thank you google translate). It’s Python so Windows is fine, @Stoneslinger76.
So based on what I see and as I think through this the best idea I’ve come up with for the SDK is below, and I’d like a sanity check before I start from the group.
Record telemetry over time and map it. Nothing out there keeps history that I have seen; every tool shows live state and then forgets it. But the SDK gives you RTK status and satellite count alongside position, plus your yard as GeoJSON. Record those across a few sessions and you get a colour-graded map of where RTK actually degrades in your specific yard. “You lose fix on the north side of the garage, every pass, nine sessions running” is a lot more useful than “it went funny near the trees.”
To be clear on scope, and I don’t want to tread on what martyndix is building: this is a data layer, not another control panel. No driving, no commands, nothing that overlaps with the tools already out there. It just sits and listens, writes to a plain documented SQLite file, and ships with a simple map view so it’s useful on its own. Anything else a panel, Home Assistant, Grafana can read that file if it’s wanted. It’d run on local MQTT by default, so no cloud account needed.
Main unknown: how often does the robot push position updates? At roughly once a second this works nicely; at every 30 seconds it probably doesn’t. Does anyone know? Then it does not look like any API keys are around so you would have to use your own login, something to know for initial access. EDIT - it does look like for this we can just use the yarbo local IP and we can get this data via its own broker.
And is RTK diagnosis actually the pain worth solving here, or would you point me at something else first? I sure have seen a lot of people have issues on this, including me, so it feels like it might be useful for us and maybe even Yarbo.
Thoughts? Am I off my rocker? @martyndix - you have been closest, thoughts?
