I have 7 mower areas. To reduce congestion, would it be OK to save them, then delete then and then create new map areas for the snowblower? Some of my mower and snowblower areas overlap. Thank you in advance for your help.
3 Likes
That’s a great question because I am about to map my snow blower so I feel there is no real reason for the mower map to be visible. Unless you can unlayer the mower and just leave the snow blower mappings.
2 Likes
The only caveat with save/restore of the maps is that it does not save any settings.
2 Likes
Great point @steve
1 Like
There is a filtered view. If you label each area mow/snow/blow/sam as appropriate, you can go to the map view and disable seeing areas like the mowing areas, etc. But it doesn’t actually remove them or any of the pathways, etc. They are still there, just not displayed. So, it can help but you might have to turn the layer back on and set a snow throw direction or something if the unit is traversing through that area on it’s way to/from the dock.
2 Likes
Hi there! You may not need to delete your mower areas. We have a label feature that allows you to assign labels to each area. Then, in the map editing interface, you can tap the small filter icon in the upper-left corner to show or hide areas by label. This can help you manage overlapping mower and snowblower areas more easily.
If you still choose to use the save → delete → create new method, please note that when you restore the saved map in the future, all map-related settings will return to their default values, so you may need to configure them again based on your needs.
Hope this helps! Feel free to ask if you have more questions.
1 Like
Design for Area Labels is incomplete. Developers just added labels to filter map and thats it.
Labels are not used for areas and for real task processing.
What is the point ask user to set Snow throwing direction for Blower area? If Area is marked as Blower only area Yarbo Snow Blower module should not see it at all.
Snow Blower parameters should not be available for Blower Area and app should not ask to set Snow Throwing direction of underlying Blower area after completing Snow Blower area.
To make it work now I need to remove all Blower areas underlying Snow Blower Areas. In my setup Blower areas and Snow Blower areas are similar, located in the same placed and the only difference is boundary, Snow Blower area is larger than Blower area, Blower boundary is 0.5m within comparing to Snow Blower area. This is done for the reason to do not Blow completely close to the border, but snow Blower is working directly from the border.
PS Obstacle detection is totally incomplete. After running the plan red areas appeared on the map on empty road (no cars, no items around, no obstacles, clean cameras). After disabled Car Detection it started to work. I have concerns that its even Beta.
2 Likes
@jso Hi there, thank you for providing such honest and detailed feedback.
Regarding the Area Labels, the current design is mainly intended to give users a clearer, more straightforward way to view and filter the map based on the active module. This was the starting point in the feature design stage. Fully separating area types for task logic does require more complex structural changes, but I will share your suggestion and expectations with our product team.
Under the current algorithm, Yarbo may use all mapped areas for travel paths when planning a task. This is why the app still asks for snow-throwing direction on areas even if they’re labeled differently.
As for the car detection feature, we are actively testing and improving it. We truly appreciate your patience and understanding as we continue working to make this feature more accurate and stable.
Thank you again for taking the time to share your experience — feedback like yours helps us improve.
2 Likes
I can’t understand how product operated before even Labels were implemented. All this creates mess, but things should be organized and simple. This is multi module platform.
I believe this is more than Labels(filter on the map) and you can see that its already starts to create issues for users with multiple modules, I need to remove Blower maps to make Snow Blower work as expected in my setup. I will rely on map backup and restore at this point.
I see also mess with area parameters, for some modules they are implemented, for some not, for example expanding area. These are global parameters which are applicable for all modules (but with different values). For example there is parameter to reduce area (safety buffer) for the snow blower but missing parameter to expand area, but both available for Lawn Mower and non available from Snow Blower in Plowe mode etc. Snow Blower in Plow mode is not working to the edge, area expanding parameter is not available, this creates issue. Sometimes even support asks to enable parameters for snow blower which are available for lawn mower only.
I hope there is person in your organization responsible for cross module solutions to merge ideas of isolated teams working on each module separately and do cross platform review and final QA before production.
Thanks.
4 Likes
Is somebody using snow sensor on the property? kind of rain sensor with heating, maybe sensor to see snow level mm zigbee version etc? I did quick search and this looks more advanced as it seemed initially.
I am trying to use at least 2 sources of data for my current automations in HA , for example forecast + real sensor on property. This is long term preparation step for yarbo api.
According to Yarbo support weather service is used for automatic scheduling. 1 inch of snow in 6h weather forecast is the trigger.
1 Like
I don’t understand the need to have separate maps for each module because my property never changes and each module is going to work in different mapped areas but the dock never moves so it will have to travel through mowing areas to get to the driveway to use the leaf blower or snow blower. But, I do think users should have the option of hiding all of that for each module and season.
I do agree that there is a lot of inconsistency in the user interface. Obstacle avoidance for the blower for example. You turn that off under safety settings. I don’t understand why there isn’t an area setting for gentle contact, moderate bypass, etc for it there just like the lawn mower. Your points about the safety buffers are valid. The expand area was changed recently and makes absolutely zero sense to me. The current methodology is to allow the rover that much more space to perform turns. It doesn’t actually move the boundary like it used to. Both are features I wouldn’t use but I could see where possibly expanding the boundary if you mapped conservatively could be useful. However, you can’t guarantee what you mapped would be consistent across the entire area. This is why in the past I encouraged users to never touch it.
1 Like
The point is not to seperate all but to make it work without errors. If you have cross module areas just tick as many labels on it as required (snow blower and lawn, snow blower and blower, etc). Snow Blower usually works on the road concrete, lawn mover works in the garden. I believe the only module working on both surfaces is Blower (SAM is on its own). There is no issue to use other areas for transit like pathway but what is the point to setup snow throwing direction for lawn area which will be never used for snow blowing? My Yarbo was not able to return from the task as snow blower direction was not set for blower area. I do not want to setup snow throwing direction for blower area especially for the case if snow blower area on the same place is available. This is not logical.
With expand area option I am trying to overcome gap for Plow mode as currently it leaves ~0.3m gap between actual border and working area, on 2.5m narrow road this is 0.6m and this is not expected. There are only 2 ways to expand - mark area with yarbo outside the current border (this is not possible because of trees and hill) or expand area by 0.3 to make plow mode work to the real border without the gap. Or fix behaviour and add safety buffer as for snow blower.
If your lawn mower works to the edge there is no sense of course, but my story differs.
Completely agree with all your points. I have never been a fan of the forced and unchangeable safety buffers because invariably Yarbo arbitrarily changes their behavior with firmware updates and if users are compensating for this and don’t expect this change, well now there’s a big issue. This happened recently with the mower. People had zero safety set but a mandatory 4 inches unknown to the user was being forced and then suddenly unenforced.
2 Likes
If you are waiting on the Yarbo API, you probably have plenty of time. 
2 Likes
Hi there, thanks for your honest feedback. With the multi-module concept, finding an effective and intuitive way to manage everything is definitely something we need to consider more carefully in our design, and we agree there is still room for improvement. I’ll make sure to share your feedback with our team.
2 Likes