HomeAssistant + Yarbo?

[Tom.C]

GitHub - YarboInc/YarboHA

I saw elsewhere this “isn’t our official release” which sounds like it’s not fully baked and ready for end users. Use with caution.

[I.T]

Seems to work and easy installation.

[bryan.wheeler]

Home Assistant Integration Timeline

I read this as this wasn’t them. I would definitely urge caution. It looks like a fork of the one Markus made just based on the readme.

[rcguymike]

My guess is someone might have made it public a little early​

[rcguymike]

Ope, they already answered

Home Assistant Integration Timeline

Thanks for your interest in Yarbo HA integration—we really appreciate it! This is indeed an official Yarbo integration, but it hasn’t been formally released yet. We’re still finalizing things to ensure it’s ready for a smooth user experience. We’ll make an official announcement once everything is fully ready—thanks for your patience in the meantime!

[rgloverii]

@rcguymike

My guess is someone might have made it public a little early​

Yup! Oopsie

[rcguymike]

Still concering…

[cobradunn]

Yep. Every 20 of those = 1 charge cycle.

[Tom.C]

I’m hoping for a customer adjustable hold limit feature to be implemented. For me, I’d hold at 80% then when I’d know I’d be mowing I’d lift the limit (should be able to be done in HomeAssistant with an automation) to allow for a full charge before the plan starts. Or, if running a smaller plan, just let it start from 80% knowing it won’t deplete during the job.

[rcguymike]

Exactly that functionality should have been implemented either before launch or shortly after…

If this is true that’s a half charge every 12 hours…

And it always shows 100% charge…just show the actual percentage with a battery health indicator with an info bubble clickable link to the wiki explaining the expected behavior.

[Tom.C]

I think it’s supposed to alleviate confusion. Most will see the app say 100% and think “fully charged” vs seeing it jump around. Personally, I’d like to see the actual percentage and set high low points for my own personal charging profile.

[bryan.wheeler]

Agreed. Only been asking them to adopt Apple and other smart phone type implementations for a long time now as well as show the actual SOC. The 100% all the time gives those who know about battery chemistries a lot of angst.

[cobradunn]

Actually, it’s the battery that gets the most stressed about this.

[rgloverii]

@cobradunn

it’s the battery that gets the most stressed about this.

Good one! Geek humor is the best kind!

[bryan.wheeler]

No wonder it needs a 4 hour rest from time to time.

[rcguymike]

Neat data already available in the HA integration:

Also Gemini approves of my name

First off, “SNO-E” is an absolutely top-tier name for a yard robot.

Looking at that attribute payload, we have a definitive answer on the telemetry: The Z-axis is missing from the Home Assistant integration.

Here is the exact diagnostic breakdown of what your HA instance is seeing, and why that Z-axis is getting left behind:

The Good Data

• rtk_fix_type: 1: This is fantastic. It confirms SNO-E has a solid lock on the RTK base station. It isn’t guessing its location; it is mathematically locked in.

• gps_ref vs position: This shows exactly how Yarbo builds its local map. The gps_ref coordinates are the absolute anchor point (likely where your charging dock or RTK antenna sits). The position_x and position_y are the local Cartesian coordinates measured in meters away from that anchor.

The Missing ‘Z’

You have the X and Y, but position_z or elevation is completely absent.

From a software development standpoint, this makes total sense. The Yarbo smartphone app only displays a 2D, top-down map of the yard to show where it has mowed or blown snow. Because the official app UI doesn’t need elevation data to draw a flat map, the developer who wrote the Home Assistant integration likely only parsed the X and Y coordinates out of the API payload.

The Engineering Next Steps

Since the robot physically cannot balance on a slope or maintain an RTK fix without calculating its Z-axis, that elevation data exists somewhere in SNO-E’s brain. To get it into your Node-RED dashboard for the grading project, you have two paths:

1. The Open-Source Route (Feature Request): Find the GitHub repository for the specific Yarbo Home Assistant integration you are using. Open an “Issue” or Feature Request. Since you know it’s an RTK system, you can specifically ask the developer: “Can you expose the Z-axis/Altitude payload as a sensor attribute? I am trying to use it for topographic mapping.” Developers usually love weird, advanced use cases like this and might just add it in the next update.

2. The Hacker Route (API Sniffing): If this integration talks to a Yarbo cloud API (rather than local polling), the raw JSON payload coming back from the server almost certainly contains the elevation. The HA integration is just throwing it away. If you have the skills to hit the Yarbo API endpoint directly using Postman or a raw Node-RED HTTP request, you can probably grab the raw JSON and parse the Z-axis out yourself.

It looks like the fully automated robotic surveyor idea is on hold just pending a software update!

[s.moz]

Please let me know if you are successful with the gate.

[Tom.C]

I have multiple things I need to get done before automating the gate so please don’t hold your breath. But, it is on the list.

[ken.w.gregory]

Seems like with every firmware update the list gets longer for a bit. Tweak this work area, remap that one, etc.

[bryan.wheeler]

Yeah, and the list of work arounds should get smaller with each update. Not change or grow.