Getting HaniMandl out into the world / Hanimandl raus in die grosse Welt werfen

[roidesreines]

Hi there!

Last year I was on the market for a honey jar filling device, as my apiary expanded.

I learned about a commercial version of the Hanimandl and tried to buy it , but it wasn’t available at the time. Then I found this project and understood it was an open-source project that I (maybe) could build myself for less money and less time than to wait for the commercial one to be delivered.

It has been quite the journey, searching through progamming forums in German and tweaking to adapt to the evolutions of the available hardware (pinouts don’t always stay the same). I finally managed to get it to work as intended, with a Heltec wifi kit V3 and a big OLED display on SPI (so no soldering). It works very well, and every smallscale beekeeper I show this to is abolutely extatic about the project and its achievements.

The point of me telling you this story is just to illustrate that Hanimandl is an absolutely awesome project, and that it is a shame that it has not gone out into the world as much as it deserves.

The biggest barriers to getting this project to as many people as possible I think are of 2 different natures:

• First is language: As the Hanimandl takes its origin in a German-speaking space, and its source code is entirely in German, it is very difficult to even learn about the existence of the project, and even more difficult to adapt it and make it evolve.

• Second is Hardware: As time goes by, some manufacturers tend to evolve their hardware, which makes it pretty difficult to deliver an out-of-the-box solution for people with less time or knowledge to use. A good exemple of that is the Heltec module which had its pinout change between version V2 and V3. (I had to completely rework and understand the pinout, a real pain).
  Also, some components are way more expensive than they need to be, which can be a barrier as well for people with less money to invest.

As you can see, there are many extremely positive points about this project, but also a few dangers looming over it:

• it is a very effective, low budget device that can solve many people’s problems regarding filling honey jars (if you are not convinced of that, go and look online for a commercial solution, you’ll know what I mean)
• it lacks accesibility because of language barriers, hardware choice and code stability. So much that it may one day fall into oblivion, or be so much obsolete that it isn’t useful to anyone anymore.

I would like this to get better.

What I want to do:

1. Translate everything to English:
   -code and commentaries (for example, use “Angle” instead of “Winkel”)
   -dialogue boxes (GUI)
   This should be fairly easy, though time consuming.
   But English only wouldn’t be very satisfying, a better thing would be to create a menu option to switch between languages in the user interface. Looking for answers, I stumbled upon this :
   https://forum.arduino.cc/t/select-languages-at-compile-time-for-dynamic-multi-lingual-array/613976
   But I have no idea about how to implement it, nor if it is possible.

2. Choose hardware and create code that is adapted to a stable and affordable platform
   I was of course thinking of the standard Esp32, barebones with no screen, very cheap, with an external OLED screen.

What I can do:
Translate, spend time testing, do simple adaptions of existing code; adapt and translate existing documentation

What I can’t do and need some help for:
Make relevant hardware choices for the future, create completely new code that requires more than absolute beginner coding knowledge, create new documentation from scratch.

What my motivations are:
Give the Hanimandl to the world, so that all the good and hard work that has been done so far is not for nothing, and help resolve people’s problem through open source an DIY, which I think is the way for a likeable future.

Of course, I am also writing this post to ensure that no other attempt at doing this is already happening, so if you know of some work in progress please let me know.

Alright, I know this was a pretty long 1st post on my part, thank you for reading this far, and please tell me what you think about all this!

[clemens]

Hi @roidesreines, welcome at Hiveeyes! You are absolutely right, it would be great to have HaniMandl with internationalization! We had a discussion about that already in the (German speaking) Facebook Group where HaniMandl “was born”. Or was you the one who initiated the discussion there? :-)

I think it is doable but it is a lot of work, as you mentioned, we have three workpackages:

• translate UI
  This is the most important todo, so that non-German speaking people can interact with HaniMandl
   
  I think there are elaborated i18n (=internationalization) libraries for Arduino we can use. In my first search GitHub - astagi/a18n: i18n with Arduino poped up, they may be more interesting libs. Currently all output is hardcoded, so we have the task to do:
  – implement the library
  – translate all (German) output to English
  – pull all German text out of the code and replace it with placeholder (prefered the English variant)
  – put all text (placeholder, English, German) in the JSON code (or other format, depending on the used library)
  – expand the JSON to further languages, I may see a vote for French here :-)

• translate code / variables / functions to English
  The HaniMandl code is grown over time and the initial code from Marc Vasterling was with German variables and so on, so we stick at this over time … This could be tricky because a wrong character in code can lead to a broken program. But it should be doable with a halt automated search and replace task and decent testing afterwards.

• translate comments in code
  There is a lot of documentaion in code – but German atm.

• translate **documentation **
  Translating the doc under HaniMandl, halbautomatischer Honig-Abfüll-Roboter is the easiest part, I think!
   
  

  
  
   
  Btw. we have a globe icon under every posting here in the board to autotranslate the posting! So this work is nearly done!

Btw I wouldn’t do language selection at compile time because switching to an other language is so not possible. I would do it in code and you can also work with binary files, much more comfortable!

I think @aholzhammer, who did a lot of development work for HaniMandl in the past, did this already but unfortunately he decided to make a commercial product based on the HaniMandl idea and so new code from Andreas in no longer available as open source. So in case you are searching for a fast solution have a look at https://www.der-honigabfueller.de .

The user interface can be switched between several languages (currently German, English, French, Italian, Serbian, Polish, Swedish)

One remark about the choosen board. It may be hard to order, but our intention was to make soldering as less es possible. So an onboard display was a good idea to start with. There is some confusion with the different Heltec versions and we are also limited to this small display. Perhaps the most flexible but still doable Version is a PCB based HaniMandl. Don’t know what you think if ordering a PCB would be an obstakle.

In the current version you have to order only parts at Amazon or on an other shop and you need some soldering skills. Uploading Gerber files to a PCB service and choosing 20 options for PCB productions may be not so easy.

Thank you for your input and as we say in German, du rennst offene Türen damit ein! :-)

[roidesreines]

@clemens

• translate code / variables / functions to English
  The HaniMandl code is grown over time and the initial code from Marc Vasterling was with German variables and so on, so we stick at this over time … This could be tricky because a wrong character in code can lead to a broken program. But it should be doable with a halt automated search and replace task and decent testing afterwards.

• translate comments in code
  There is a lot of documentation in code – but German atm.

This should be pretty straight forward but time consuming.
I got this.

@clemens

• translate UI
  This is the most important todo, so that non-German speaking people can interact with HaniMandl
   
  I think there are elaborated i18n (=internationalization) libraries for Arduino we can use. In my first search GitHub - astagi/a18n: i18n with Arduino poped up, they may be more interesting libs. Currently all output is hardcoded, so we have the task to do:
  – implement the library
  – translate all (German) output to English
  – pull all German text out of the code and replace it with placeholder (prefered the English variant)
  – put all text (placeholder, English, German) in the JSON code (or other format, depending on the used library)
  – expand the JSON to further languages, I may see a vote for French here :-)

The UI translation work is pretty easy too, I’ve done this last year, my Hanimandl is all French now.
The hard part (for me) is getting into the actual new coding.

If someone could have a look into it and give me kind of a template to work with, I could fill in the blanks by translating and testing the UI. I’m thinking something a little bit as in the library you suggested, but integrated a minimum inside the code already. Then, all I would need to do is follow the template and expand on it.

{
    "item_id": {
        "language_code_1":"translation_1", 
        "language_code_2":"translation_2", 
        ...
        "language_code_N":"translation_N"
    }
}

As a reminder, my ressources and competences are limited to basic understanding of computing and coding principles, with no real proficiency in any programming language and good practices.
Also, lots of time, language savviness and a healthy amount of patience/stubbornness.

@clemens

• translate **documentation **
  Translating the doc under HaniMandl, halbautomatischer Honig-Abfüll-Roboter is the easiest part, I think!
   
  
  
  
   
  Btw. we have a globe icon under every posting here in the board to autotranslate the posting! So this work is nearly done!

I think this is the very last leg of the journey, once everything else is up and running fine.
Yes indeed, autotranslation is a good friend

@clemens

One remark about the choosen board. It may be hard to order, but our intention was to make soldering as less es possible. So an onboard display was a good idea to start with. There is some confusion with the different Heltec versions and we are also limited to this small display. Perhaps the most flexible but still doable Version is a PCB based HaniMandl. Don’t know what you think if ordering a PCB would be an obstakle.

In the current version you have to order only parts at Amazon or on an other shop and you need some soldering skills. Uploading Gerber files to a PCB service and choosing 20 options for PCB productions may be not so easy.

I would like to get rid of the Amazon and PCB parts. My reasoning is, I’d really like this project to be accessible to people (maybe in other countries) with less ressources and parts availability.

I’d like to keep the minimal needed steps as simple as:

• Get a few of-the-shelf very standard, easy to source and cheap parts.
• Do a little bit of basic soldering (as it is pretty inevitable with this kind of project).
• Adapt whatever mechanical parts are gonna be needed.
• Select the right hardware options and upload the code.
• Done.

Unless you have access to a 3d printer, in which case, you can decide to print whatever you need.
As a good example of that, this is what my current version of Hanimandl looks like:

Apart for a new casing for the scale, and recently replacing the Heltec V3 module with a WROOM + extension board, this is how I worked last season.

I packed more than 1700 honey jars like this, I never had any real problems. The noodle like hanging cables, crappy printed case and bad mechanics are an insult only to the aesthetic soul, not to practicality.

I bet my shirt a few dozen farmers all over, say, France, Spain, Greece, India,Thailand, Morocco, Mexico and so on would love to have this beauty at their service.

I think an “extension board” would be a good alternative to the PCB to provide minimal support to the ESP32 board and prevent it from banging too much inside the case, as well as diminish the amount of soldering while remaining very cheap and super easy to source.

[roidesreines]

So next up for me is to start translating the code, which I better do from the best version available.
Someone reached out to me in private and suggested Roland Rust’s excellent work.

He happens to have made the same hardware choices I would probably have in the end, very good.
We’re talking ESP32WROOM with 38 pins, rotary selector (no more potentiometer), choice for 2 sizes of screens and choice to connect these by either SPI or I2C.

So I’m thinking about using his code as a workbase for translation and kickstart the internationalization of the development.

Please let me know if there is anything better out there for what I intend to do before I need to do this all over again (please not a third time )

[roidesreines]

@clemens

I think @aholzhammer, who did a lot of development work for HaniMandl in the past, did this already but unfortunately he decided to make a commercial product based on the HaniMandl idea and so new code from Andras in no longer available as open source. So in case you are searching for a fast solution have a look at https://www.der-honigabfueller.de .

Also, I need to acknowledge that @aholzhammer has reached out to me in private, and given me some help within his current possibilities, mainly some hints as of what hardware to use.
Good luck to him for his enterprise!

[SalMancina]

As mentioned above by @roidesreines I have built my Hanimandl based on Roland Rust’s excellent work with a 38 pin esp32 WROOM and a 2.4 inch 320x240 ST7789. My project displays only English now, including menus and information. I have translated into everyday English, for example I have used Overfill for Kulanz rather than Goodwill, which the dictionary says is the right translation.

I edited the code somewhat and disabled the jar counter as I don’t need it. I have also removed any code for the unused display types and reduced the user types from 3 to 1. This has made the code quite a bit shorter. I also changed the default jar types to UK ones as we have different sized jars here.

I haven’t translated the code at all as I didn’t see the work would have been worth the effort and it would have been too easy to break something. I have added comments in English in some places to help me understand the code.

The hardware is built on a small project board: RkEducation 5x7cm PCB Copper Matrix Prototyping Stripboard

They are also available on Amazon UK.

A proper PCB would be wonderful… there is a bit of “knitting” on the project board to link things together!

I am very happy to share my hanimandl.ino file if anyone wants it… you will need to change the jar sizes to suit your country. Is there a software repository on this site? I couldn’t find it.

Once again I wish to thank the original creators of this project.

[weef]

@SalMancina

Is there a software repository on this site? I couldn’t find it.

GitHub - hiveeyes/hani-mandl: HaniMandl ist ein halbautomatischer...

[roidesreines]

Breaking news (at least for me).
As I was about to commit in downloading a version of Hanimandl and start to translate, I found out that Roland Rust is still very much active on the project.
Indeed, he even has just uploaded a work in progress version in his development branch where is he taking a shot at implementing multilanguage support.
If anyone has the opportunity, I’d love to get in touch with the guy to try and organize something.
I know this is a shot in the dark, but I’d better coordinate efforts here.

[Andreas]

Thank you. We’ve just reached out to Roland at HaniMandl upstream maintenance · Issue #2 · RolandRust/HaniMandlWroom · GitHub.

[gech]

HI !

Do you have some overview of the components you use !
Your stuff looks nice.

Georg

[Roland]

Hi,

yes, I am working on the translation to other languages. At the moment, this is implemented using a header file, and you have to decide before compiling if you want to use German or English. Not the nicest solution, but for my needs it is enough as a starting point.

Note: Be careful with the development branch. There is also a new function implemented for the Servo regulation, and it’s not fully tested yet.

BR
Roli

[roidesreines]

The compilation time way to choose the UI language is good enough for open source.
Since it is intended for users to understand at minimum how to adapt to material, thus tinkering a little bit with .ino files.
I’ve already worked on a version of the resources_fr.h containing dialogues, I’m just waiting for my LCD 320x240 screen to arrive to start the code and translation process from Roland’s dev branch.
I’ve also seen that he started to translate some file names to english, things are on their way, very nice!!

[roidesreines]

Quick update here:
Today I have translated the entire commentaries inside the code. I worked on the last version of @Roland 's dev branch, dated from 3 days ago. Yes I used a google translate more than I’d like to admit, no it’s not perfect and yes it will do the job.
I think it will be good when native German speakers who are familiar with the project have a look into it to catch the inevitable mistakes I must have made.

Next up is the translation of functions and variables.
To not mess up too much the code and avoid redondances, I plan to gather up all functions and variables inside a good old spreadsheet with their proposed translations and submit them here (or some more appropriate place someone would be kind enough to point me to) for the general public to make suggestions and rectifications to.
Coming soon.

[Andreas]

Hi @roidesreines,

@roidesreines

Today I have translated the entire commentaries inside the code.

Thank you so much for contributing!

@roidesreines

Next up is the translation of functions and variables.

I am not sure if I get this right. By “function names” and “variables”, are you referring to symbols in code? This is a detail you usually do not translate into different languages, and it is a well established convention to use the English language. Maybe it is a misunderstanding on my end?

With kind regards,
Andreas.

[clemens]

@Andreas

and it is a well established convention to use the English language.

Most are German atm, thats the “problem” … ;-)

[Andreas]

Oh, I didn’t get that. Then, go ahead, @roidesreines! That’s also a thing I wanted to improve on the upstream version.

[clemens]

Jos (in the Facebook group) has translated the display messages to Dutch, no clear if it is publicly, but try to get the version!

[Roland]

Ja, das ist schon so, das die Funktionen und Variablen fast alle auf deutsch sind. Habe das so übernommen vom Original Code. Mit aber ein wenig Fleissarbeit sollte dies zu ändern gut machbar sein. 90% von den Variablen sind ja von Zeile 370 bis 450 definiert.
Nun mal eine kleine Erklärung wie meine unschöne Implementierung von den verschiedenen Sprachen ist.

in der Zeile 155 wird die Sprache ausgewählt. Für jede Sprache gibt es eine Nummer

#define LANGUAGE 1                // 1 = Deutsch
                                  // 2 = Englisch

Ab Zeile 229 wird das Sprachfile ausgewählt.

#if LANGUAGE == 1
  #include "./Resources/resources_de.h"
#elif LANGUAGE == 2
  #include "./Resources/resources_en.h"
#endif

da muss für das neue Sprachfile einfach ein neues #elif LANGUAGE == X definiert werden.
Dies währe dann schon alles, was im Code geändert werden muss für eine neue Sprache.

Nun muss nur noch das neue Sprachefile im Orden ./Resources erstellt werden (z.B. resources_fr.h).
Zu beachten ist, dass es von dem Display her Einschränkungen mit der Länge gibt. Ich glaube bei den absoluten Positionen ist es so gemacht, das es immer kürzer werden kann und die Position noch korrekt ist. Aber wenn es zu lang wird, kann es zu Überschneidungen kommen oder zu ungewollten Zeilenumbrüchen.
wenn der Text zentriert ist wird bei zu langen Wörtern rechts und links abgeschnitten (Kommt daher, das die Berechnung bei der x Position dann ins minus geht). Und zum Schluss muss man im UTF8 Zeichensatz bleiben. Ansonsten gibt es bei der Zentrierung einen Shift nach links.

Ich werde mir nach meinen Skiferien auch mal Gedanken machen, wie man das Node MCU Board als Hardware Level und der INA code in die upstream version bekommt. Sollte eigentlich gut machbar sein für das OLED Display.

[Andreas]

Hi Roland,

das liest sich gut.

Das mit der Sprachzuordnung so hemdsärmelig über das Header File zu machen, finde ich absolut in Ordnung.

Hautpsache die Symbole bekommen sprechende Namen und wir kommen von Konstantennamen wie PS_MI01, ST_TI01, SC_TO01 usw. weg: Ich würde mich an der Englischsprachigen Variante resources_en.h orientieren, und die Dinger CALIBRATION, FILL_QUANTITY, SERVO_SETTINGS usw. nennen, sonst bekommt man üble Hirnverzwirnung beim Lesen des Quellcodes, wegen der ganzen magic numbers.

Dass beim Übersetzen auf Embedded Geräten viele Dinge berücksichtigt werden müssen (Zeichensatz sowieso, aber auch Textlängen usw.), ist klar, und war zu erwarten. Vielen Dank für die ausführliche Beschreibung der Dinge, die es dabei zu beachten gilt. Das ist ein heißer Kandidat für einen dedizierten Abschnitt in der Dokumentation, damit andere beim Beitragen von Übersetzungen nicht unnötig stolpern.

@Roland

Wie man das Node MCU Board als Hardware Level und der INA code in die upstream version bekommt. Sollte eigentlich gut machbar sein für das OLED Display.

Stark, vielen Dank. Sag bitte rechtzeitig Bescheid, dann kann ich mich u.U. vorher noch um die Integration von Improve multiboard-support · hiveeyes/hanimandl@1acc542 · GitHub kümmern, bevor Du loslegst. Das macht das Einbringen weiterer Hardware-Varianten einfacher als bisher, und kommt ebenfalls von der Verwendung von “magic numbers” weg: HARDWARE_LEVEL == 1 (vorher) vs. HARDWARE_LAYOUT_LEGACY, HARDWARE_LAYOUT_MODERN, usw. (neu). In diesem Sinne würde sich dann eine Konstante HARDWARE_LAYOUT_NODEMCU anbieten, um eine typische Hardware-/Pinbelegung für die von Dir verwendeten Geräte abzubilden. Schöne Skiferien erst einmal!

Viele Grüße,
Andreas.

[roidesreines]

code translation.xls (14 Ko)
Hi all.
Here is my first sweep on all German expression I felt needed to be translated and my first take on translating them.
[edit] I’ve already caught the Tara = tare mistake