Skip to content
This repository has been archived by the owner on Oct 1, 2023. It is now read-only.

[Feature Request] Add calibration points #84

Closed
PiotrMachowski opened this issue Aug 28, 2022 · 2 comments
Closed

[Feature Request] Add calibration points #84

PiotrMachowski opened this issue Aug 28, 2022 · 2 comments

Comments

@PiotrMachowski
Copy link

Hi!

Thank you for your effort put into this project.

Would it be possible to add calibration points to MQTT API? I suppose it should be easily doable by evaluating translateCoordinatesToPixels function for 3 points (possibly hardcoded as they don't even have to be within map boundary).

Adding this feature would make it much easier to use Valetudo with my Vacuum Map Card, especially since it will support Valetudo out of the box since v2.10.0.

Required schema:

[
  {
    "vacuum": {
      "x": 25500,
      "y": 25500
    },
    "map": {
      "x": 466,
      "y": 1889
    }
  },
  {
    "vacuum": {
      "x": 26500,
      "y": 26500
    },
    "map": {
      "x": 730,
      "y": 1625
    }
  },
  {
    "vacuum": {
      "x": 25500,
      "y": 26500
    },
    "map": {
      "x": 466,
      "y": 1625
    }
  }
]
@PiotrMachowski PiotrMachowski changed the title Add calibration points [Feature Request] Add calibration points Aug 28, 2022
@Hypfer
Copy link
Owner

Hypfer commented Sep 13, 2022

Hi,
I just now found this issue as I have all notifications disabled for this repo

So as mentioned in the Readme, this project is pretty much broken, badly maintained, features a bad UX, a lot of moving parts and should not be used by people.
It still exists because it is in use in some setups, however what it actually needs is a complete retooling/rethinking.

For example for home assistant setups, a custom component that takes the map entity and provides a rendered map entity would make much more sense as that could just be installed and configured via HACS and the UI.

For setups other than home assistant, a rewrite would also be in order, as the current project has issues such as apparently not working on armhf see issue #85


I don't know what exactly calibration points are or what your card does, however anything that makes people use ICBINV more instead of less is a big no for me.
It is broken software with little to no support. Please stop using it. Especially, please stop onboarding new users onto it when there are solutions with a much better UX.
With the official lovelace card, you just install that via hacs, enter the name of the robot and boom you have map.


Apart from that, from a technical standpoint, I don't really understand why exactly these calibration points exist.

What do they do?
From a quick glance it seems like they're aiming to recreate data that is not available via the stock xiaomi cloud map images.
However with Valetudo it is different as we have the real actual map coordinates data before it gets rendered to an image.

There is no need to approximate data that already exists in the raw ValetudoMap json


Strategically speaking, official support for a lovelace card that aims to also support vendor robots sounds like a bad idea as that would limit the Valetudo experience to be at most on par with what the vendor cloud has to offer.
As Valetudo has all the raw data however, it is able to provide much more than that.
While it would be nice to have one card that works okay-ish with every vacuum entity, I'd rather have a Valetudo-specific card that works exceptionally well with Valetudo.


Furthermore, I'm not all too fond of creating the same functionality that the Valetudo Webinterface offers again but this time it's a lovelace card including all limitations and third-party dependencies that come with that.
That's just asking for confused users and an overall subpar experience.

Not to say that the card would be bad or anything. I'm sure it's great in its niche.
That niche is just a different niche than the one Valetudo is in even though they both deal with similar vacuum robots.

@Hypfer Hypfer closed this as not planned Won't fix, can't repro, duplicate, stale Sep 13, 2022
@PiotrMachowski
Copy link
Author

So as mentioned in the Readme, this project is pretty much broken, badly maintained, features a bad UX, a lot of moving parts and should not be used by people.
It still exists because it is in use in some setups, however what it actually needs is a complete retooling/rethinking.

Ok, I wasn't aware of that as personally I don't use Valetudo

Especially, please stop onboarding new users onto it when there are solutions with a much better UX.
With the official lovelace card, you just install that via hacs, enter the name of the robot and boom you have map.

As I mentioned above, I wasn't aware that ICBINV is such obsolete and shouldn't be encouraged as a solution for people to use. The problem with official lovelace card is that its functionality is limited when compared to my card (you can check out some of its features here). With calibration points added to ICBINV setup of my card would be almost as simple as using official one.

Apart from that, from a technical standpoint, I don't really understand why exactly these calibration points exist.

They are required for my card to function as it doesn't use raw map data to render a map but just its image. Calibration points are required to calculate transformation matrix between point on the image and vacuum coordinates.

Strategically speaking, official support for a lovelace card that aims to also support vendor robots sounds like a bad idea as that would limit the Valetudo experience to be at most on par with what the vendor cloud has to offer.

Actually I have designed my card to be as much universal as possible (current version already supports vacuums from multiple vendors - Xiaomi (incl. Viomi, Dreame, etc.), Neato, Roomba). It doesn't retrieve image from any cloud by itself (it is purely just for presentation and control), so it has to rely on external sources of map (screenshots in documentation use data from my other integration that retrieves map from Xiaomi cloud).

Every feature of my card is customizable when needed, but at the same time basic user can benefit from automatically generated card config designed specifically for their vacuum (of course provided that it is supported).

While it would be nice to have one card that works okay-ish with every vacuum entity, I'd rather have a Valetudo-specific card that works exceptionally well with Valetudo.

Generally speaking I think say that my card would work excellent with Valetudo (after adding calibration points) - it already works perfectly with ValetudoRE (example) and should support all Valetudo features available via MQTT.

Not to say that the card would be bad or anything. I'm sure it's great in its niche.
That niche is just a different niche than the one Valetudo is in even though they both deal with similar vacuum robots.

The goal of my card is to make it possible to control vacuums without leaving Home Assistant. Valetudo is a standalone software, so of course it has different use-cases, but I think that HA users would greatly appreciate possibility to use just one application on daily basis (but with option to use original Valetudo UI for more advanced, but occasional situations).

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants