I did start playing with the concept I mentioned and already learned several things that the documentation is wrong about. Once I have something real and tested better I will let everyone know.
@mike1 - excellent work. Keep it up 
@mike1 - Good morning Mike,
Question - Of the data fields you have access to, are there ones for hours of usage, total hours of usage or total hours on the core?
I’m not worried about the calculated Work Plan (WP) hours.
Agree 100%. Every time I have to take the robot out to map something drives me nuts. We have a full-RTK system in place. Allow us to make map edits based on our crude Google Maps georegistration with the disclaimers blah blah. Or, allow us to properly georegister a high-res drone photo.
Good call on the drone photo!
Short answer: no. I’ve been through every field the Core broadcasts -
453 distinct ones across all the MQTT topics and there is no total-hours,
engine-hours or lifetime-runtime counter anywhere. Not on the Core, not on
the head. If Yarbo tracks it, they don’t publish it locally. NOTE - all of the data I can get my hands on is right from the core or the head itself, Yarbo cloud is not in the loop.
What does exist is a lifetime odometer, one per track:
odometer_left / odometer_right
These are genuinely cumulative so for mine only went backwards twice in 85,906
consecutive readings, so it’s a real counter and not a per-session thing.
Mine currently read 43,265 and 43,667. Also worth noting yarbo just replaced my core so its only a few weeks old.
The unit isn’t documented. I calibrated it against integrated wheel speed
and it comes out around 1.6 m per unit, which is suspiciously close to one
wheel revolution so that would put mine at roughly 69 km of lifetime travel.
I’d treat that as inferred, not gospel. It’s one machine and one method. If
you read yours and compare against a distance you actually know, that would
confirm or kill it fast, and I’d be glad to hear either way.
On the timing side there’s startTime, duration, totalTime, leftTime and
totalCleanArea, but those are all per work plan; the WP hours you said you
weren’t after. There’s also a clean_times field per mapped area (how many
times each zone has been cut), but it reads 0 on my machine, so it’s either
unpopulated or it resets.
The other way at it: since the robot won’t tell you, something watching it
can count. Over the last 50 hours mine has been awake and working for 27.5
of them, charging for 1.4, and travelled about 17.6 km. That’s genuine
hours-of-use — the catch being it only counts from when you start
recording. Nothing can reach back and reconstruct what happened before.
Now I am working on building a full package that a few people on here are doing some beta testing of the software I created already. I could add something to capture this, but it would be from the point you install the software and start tracking, it won’t go back in time.
I assume this is all back end tracking given the end of year recaps they sent out to some of the users back in January.
Hi
as a complement I posted this 3 weeks ago. This above has been made using the local mqtt feed that provides much more access.
But I built a full webapp using only the sdk to add features such as advanced scheduling, alternating perimeter, infinite mow (looping areas in a queue) a queuing system, auto resume after rain pause, and so on. I had to create a complete backend with its own managed database to add some « memory », and I confirm that indeed Yarbo doesn’t store anything (or they don’t expose it) and I found no way to modify a map or manually control the bot. You can however subscribe to the mqtt feed so you can plot on a map the Yarbo position, you can poll and your can send start stop pause resume commands. You can poll settings per area and change some of them. With that you can create an app that manages all of this…
Currently in the testing process. Still a lot of bugs and I discovered that their feed is not 100% up (meaning that sometimes I lose connection both in the Yarbo app and mine at the same time while the robot is still running and all is fine when connecting to the lan mqtt and via Bluetooth) so there seems to be some intermittent disconnnect on the cloud side.
Hi Mike,
That’s a really useful write-up — thank you. You’re not off your rocker, and I think you’ve got the SDK inventory right.
You’re correct that the official SDK is cloud-only, and that it’s actually narrower than local MQTT. The panel is local-first for that reason: live status, drive, lights, buzzer, pause/dock, plan start/delete, waypoints. Cloud is only an optional fallback for reading maps and plans when the robot doesn’t return them locally. Commands stay on the LAN.
On map upload: I agree “the SDK doesn’t have it” doesn’t prove the firmware doesn’t. I’ve been looking at the local broker for that, and I still haven’t found a write/save/upload command that the core will accept. Export/edit on the panel is there; putting it back on the robot is still blocked. If you (or anyone) spots a local topic that writes map data, I’d love to know.
Camera: same as you — nothing opened up that I’ve seen.
On your logging idea: please do it. It doesn’t tread on the panel. I show live state and then forget it, which is exactly the gap you’re describing. An RTK/satellite heatmap over a few sessions would be more useful than another control screen, and a plain SQLite file other tools can read is the right shape.
Position updates: I don’t have a guaranteed 1 Hz figure. The panel asks for telemetry about every 5 seconds. If you subscribe to the local MQTT feed rather than polling, you get a much denser stream — which it sounds like you’ve already confirmed. For a colour-graded map, subscribe locally; you shouldn’t need a cloud login for that.
Happy to stay out of each other’s way and swap notes. If the SQLite schema is documented, I’d be glad to point people at it from the panel docs when it’s ready.
Martyn
Quick update: v1.3.1 is on GitHub. If you already have the software installed it will show up as an update you can install direct from the web interface.
A few people have been trying the panel and sending really useful feedback, thank you. This release is aimed at the snags that came up:
-
Blank screens / “Failed to Fetch” — on a Mac, start with
./scripts/dev.shand leave that terminal open.php -Son its own was not enough and could hang the page. Existing Raspberry Pi installs should keep working as they are. -
Map looking rotated or flipped compared with the Yarbo app — that was an east/west mix-up in the coordinates. After you update, click Load saved mowing areas again. The phone app is not always north-up, so satellite view is the better check against the real yard.
-
Installer saying Python was installed when it wasn’t — that false success on Homebrew is fixed. The panel still runs without the optional Python bits.
If you installed with git clone, you can update from Settings → Panel updates. Zip downloads cannot do that.
As before: unofficial, use at your own risk, and be careful with manual drive.
Martyn
With Home Assistant you can create an odometer using the GPS coordinate movement. It’s pretty straight forward. I have a Lifetime and a Trip Odometer for maintenance.
input_number:
yolawnda_last_latitude:
name: YoLawnda Last Latitude
min: -90
max: 90
step: 0.0000001
mode: box
yolawnda_last_longitude:
name: YoLawnda Last Longitude
min: -180
max: 180
step: 0.0000001
mode: box
yolawnda_lifetime_distance_mi:
name: YoLawnda Lifetime Distance
min: 0
max: 100000
step: 0.000001
unit_of_measurement: mi
mode: box
yolawnda_trip_distance_mi:
name: YoLawnda Trip Distance
min: 0
max: 100000
step: 0.000001
unit_of_measurement: mi
mode: box
template:
- sensor:
- name: "YoLawnda Lifetime Distance"
unique_id: yolawnda_lifetime_distance
unit_of_measurement: "mi"
device_class: distance
state_class: total_increasing
icon: mdi:map-marker-distance
state: >
{{ states('input_number.yolawnda_lifetime_distance_mi') | float(0) | round(3) }}
- name: "YoLawnda Trip Distance"
unique_id: yolawnda_trip_distance
unit_of_measurement: "mi"
device_class: distance
icon: mdi:map-marker-path
state: >
{{ states('input_number.yolawnda_trip_distance_mi') | float(0) | round(3) }}
automation:
- alias: "YoLawnda Track Distance"
id: yolawnda_track_distance
mode: queued
trigger:
- platform: state
entity_id: device_tracker.yolawnda_location
condition:
- condition: template
value_template: >
{{ state_attr('device_tracker.yolawnda_location', 'latitude') is not none
and state_attr('device_tracker.yolawnda_location', 'longitude') is not none }}
action:
- variables:
new_lat: >
{{ state_attr('device_tracker.yolawnda_location', 'latitude') | float }}
new_lon: >
{{ state_attr('device_tracker.yolawnda_location', 'longitude') | float }}
old_lat: >
{{ states('input_number.yolawnda_last_latitude') | float(0) }}
old_lon: >
{{ states('input_number.yolawnda_last_longitude') | float(0) }}
- choose:
- conditions:
- condition: template
value_template: >
{{ old_lat != 0 and old_lon != 0 }}
sequence:
- variables:
segment_m: >
{% set R = 6371000 %}
{% set lat1 = old_lat | radians %}
{% set lat2 = new_lat | radians %}
{% set dlat = (new_lat - old_lat) | radians %}
{% set dlon = (new_lon - old_lon) | radians %}
{% set a =
sin(dlat / 2) ** 2
+ cos(lat1) * cos(lat2) * sin(dlon / 2) ** 2 %}
{% set c =
2 * atan2(sqrt(a), sqrt(1 - a)) %}
{{ R * c }}
segment_mi: >
{{ (segment_m | float(0)) / 1609.344 }}
# Ignore tiny GPS jitter and obvious GPS jumps
- condition: template
value_template: >
{{ segment_m | float(0) >= 0.10
and segment_m | float(0) <= 25 }}
# Add segment to lifetime mileage
- action: input_number.set_value
target:
entity_id: input_number.yolawnda_lifetime_distance_mi
data:
value: >
{{
states('input_number.yolawnda_lifetime_distance_mi') | float(0)
+ segment_mi | float(0)
}}
# Add same segment to resettable trip mileage
- action: input_number.set_value
target:
entity_id: input_number.yolawnda_trip_distance_mi
data:
value: >
{{
states('input_number.yolawnda_trip_distance_mi') | float(0)
+ segment_mi | float(0)
}}
# Always save current position for the next update
- action: input_number.set_value
target:
entity_id: input_number.yolawnda_last_latitude
data:
value: "{{ new_lat }}"
- action: input_number.set_value
target:
entity_id: input_number.yolawnda_last_longitude
data:
value: "{{ new_lon }}"
Hi All,
Hope you are all doing well.
So some updates (in beta) to make you aware of. I have started building in features to use/monitor Yarbo with other devices. One is the M5Stack PaperMono (M5Stack Launches PaperMono: A Compact E-Ink Development Terminal for Connected Projects) to act as a portable control screen, the other is the Vestaboard Note (Vestaboard Note — The Small Playful Messaging Display | From $999) which displays status updates of the Yarbo connected to it.
You can see some screen mockups in the GitHub documentation (GitHub - martyndix/yarbo-control-panel: Local PHP web control panel for Yarbo robot mowers via MQTT · GitHub). Please feel free to have a play and let me know what you think, or if you have more suggestions.
Best wishes,
Martyn
So since my intial upload to GitHub there have been quite a few downloads. Just wondering if anyone has used it or finds it useful? Any feedback would be greatly appreciated. If people like it I will keep developing. I have this running on a touchscreen monitor on my wall and actually use it more than the Yarbo app to monitor and trigger workplans to start. What do people think?
Best wishes,
Martyn
Vestaboards are amazing.
I completely agree! I also think my Yarbo is too, so you can imagine how excited I was when I got them playing together!
That’s so cool you did that!!!