How to help development via programming?

[bugwelle]

The title is a bit cryptic, but my question is: How can I support Valetudo besides sponsoring it?

Are there any low hanging fruits that don't require a lot of skill, but are time consuming?
I didn't find anything in that regard in the issues nor discussion here on GitHub.

I've gone and looked for some typos, so there's that. But anything else?

I've got experience in NodeJs but only minimal frontend-skills.

Regards,
Andre

[Hypfer]

Hey, thanks for the interest and offering.

While appreciated, as you've seen, there's just not all too much to do in Valetudo as it's a mature piece of software that just works.

In general, I'm honestly not too fond of code contributions especially for low hanging fruit, as those require way more work from me than just doing it myself due to the vast amounts of communication required.
I do of course understand that you're only well-meaning, however unfortunately I have to say that this is not the right project or at least not the right time for such requests for work to contribute.

While it might not look like it, It is already quite time consuming to just reply to this alone, as rejecting people people that only want to help is quite difficult - even more so through text. This took 35+ minutes of continuous writing and rephrasing and I'm still not very happy with it tbh

[bugwelle]

Hi, thank you very much for your fast response!

Indeed, Valetudo is very mature and I can understand the workload that other code contributions bring with them.

With "time consuming but low skill" I meant for example writing tests for coding that isn't covered as much as you'd like¹. Or adding automated code coverage pages via codecov.io . Something that isn't in the heart of Valetudo, that you always wanted to add but didn't have the time to.

With "low hanging fruit" I think of e.g. updating or adding screenshots, proof reading (new) documents, or anything where you want to have another pair of eyes to look through.

I've read your PSA statement before: I can fully understand your point and appreciate your detailed answer very much.

Kind regards,
Andre

Footnotes

1. Disclaimer: I haven't looked at either tests nor test coverage, yet. ↩

[Hypfer]

Okay so after having overcome the initial fear of having to do more work and giving the question some time, I think I have something for you if you're still interested. Indeed there are issues like the ones you've been suspecting, however they're not part of the main project but rather the ecosystem.

I can't believe it's not Valetudo

https://github.com/Hypfer/Icantbelieveitsnotvaletudo

This companion service that renders the raw map data to png graphics was born to allow me to remove a resource-intensive feature from Valetudo during refactoring. I didn't really want to do it but people needed some solution, so it had to be done.
If you look at the state of that thing, you can tell.

What I'd be looking for in there would be the following things ordered by priority

Goal 1: Autoconfig/Autodiscovery

The service should be reworked so that it doesn't require manual setup by the user apart from connecting it to the MQTT broker.

It should be able to automatically auto-discover multiple Valetudo instances that are connected to the MQTT broker and enrich their data with the rendered map.

For that, it should also provide auto-discovery information for home assistant that reuses the same device config so that it shows up in Home Assistant as just another entity of the Robot device.

Goal 2: Make it work on more hardware

The native dependency required to have canvas in node because I basically just copy-pasted the canvas-based renderer into the project introduces a native dependency. These are bad because they suddenly make running the software on any host you can find much harder.
Apparently, this causes some people to have trouble to get it to work on some old raspberry pis?

The options here would either be testing and making sure that it works with that dependency on armv7, aarch64 and amd64 or rewriting the renderer so that it doesn't require that native dependency

Goal 3: Drop the Config File, Docker Images

Maybe if things turn out to be reliable and easy to maintain, the project could provide official docker images that do the thing.
Big maybe though. It would require being set up so that it can be fire and forget.

One thing worthy of note here is that it could be useful to configure MQTT via ENV variables instead of a config file.
Mounting the config file into the container already caused trouble for users multiple times.

Second headline

I was initially planning on having more here, but while writing this, it became clear to me that ICBINV would be the most relevant one right now.

[bugwelle]

(currently on vacation, but I will definetly have a look and read your comment in more depth after that, thanks!) 😄

[bugwelle]

I can't believe it's been nearly a year already. I very much appreciate your long message. I did look into goal (2) last year in April, but didn't get it to work¹. After that, I forgot about it until December and saw that the project is now archived and another repository is recommended (/linked).

Thank you very much again for posting! If I ever get enough time and if the topic fits, I'll have a look at your "Help wanted" issues (one at the moment).

Footnotes

1. I tried looking into other packages, or the possibility to use web assembly, etc. ; all had drawbacks starting at hardware limitations, missing features, binary size, etc. ↩