Man könnte die Profile vorher auf dem Rechner sichern und dann wieder kopieren, oder funktioniert das auch nicht?
Nein, leider nicht. Der Aufbau der Profile und auch die dort verwendeten Befehle/Variablen wurden teilweise geändert. Die alten Profile kann die neue FW überhaupt nicht verstehen. Hier mal links ein altes Pulverprofil, rechts ein Neues.
Man muss schon die Werte von links auf der rechten Seite an der passenden Stelle eintragen usw.
Wobei, per KI geht das eventuell sogar automatisch, müsste man mal versuchen. Mit nem Verweis zu der neuen BA könnte die das sogar hinbekommen.

Ich hab jetzt übrigens auch das Problem mit den fehlenden Werten von meiner Waage bei der neuen 2.10 gelöst bekommen!
Mit 2.08 konnte der Trickler im Waagenprotokoll "GG" auch die Werte meiner einfach dauerhaft (ca 10x/s) sendenden Waage auswerten.
Das geht mit 2.10+ aber plötzlich nicht mehr...
Es dauert um die 30s, bis der Trickler nen Wert von der Waage erkennt.
In der 2.10 muss man dem Trickler jetzt ein Initialisierungssignal nennen, das er als Befehl zur Waage schicken kann, damit die den aktuellen Wert zurückschickt.
Diese Einstellung ist für einige Waagentypen schon fertig eingebaut. Trägt man GG, AD, KERN, o.ä. bei Scale -> protocol in der config.txt ein, geht das schon. Meine PCE wollte aber wohl einen anderen Befehl haben...
Dafür ist dann das Feld "customCode" in der config.txt da:

Meine Waage möchte laut BA haben:
Zitat
PC -> Waage: Initialisierungssignal S I CR LF (53h 49h 0Dh 0Ah)
Das heißt, die Waage möchte die Befehle S, I, CR und LF haben, damit sie antwortet. In HEX-Codierung wäre das 53 49 0D 0A. Das hat aber einfach nicht geklappt...
Also habe ich die Waage per USB-RS232-Wandler an meinen PC angesteckt (dann muss man aber zwischen Wandler und Waage die Pins 2 und 3 vertauschen), dann kann man am PC mit einem Terminalprogramm (zB Realterm, Teraterm, usw.) alle möglichen Befehle senden und merkt entsprechend gleich, ob daraufhin was empfangen wird. So kann man viel besser und schneller "rumprobieren"... 
So habe ich dann rausgefunden, dass der Befehl "53 49 0D 0A" (als HEX gesendet! in Realterm muss man dazu zB "$53 $49 $0D $0A" eingeben) auch tatsächlich funktioniert. Befehl geht raus, Wert von der Waage kommt rein. Waage geht also schonmal, und hört auch garantiert auf den Befehl.
Also muss die Firmware des Tricklers die Eingabe auch irgendwie anders handhaben als mein PC... Weil auch Realterm schon die vorangestellten $-Zeichen brauchte, um die Zahlen als HEX zu erkennen, habe ich in der Richtung auch gegoogelt und viele übliche Eingabeformate für die verschiedensten ESP32-Firmwares zusammengesucht und jeweils in der config.txt eingetragen und ausprobiert. Und siehe da:
"scale": {
"protocol": "CUSTOM",
"customCode": "0x53 0x49 0x0D 0x0A",
"baud": 9600
},
hat dann funktioniert! Nur mit dem 0x davor werden die Werte 53 49 0D 0A scheinbar auch wirklich als HEX-Werte verschickt.
Fehlen diese 0x davor, werden die Werte vermutlich nur als Dezimalzahlen verschickt, und mit denen kann die Waage nichts anfangen.
Mit dem o.g. Eingabeformat schickt die Waage jetzt auf Anfrage des Tricklers ihre Daten an den Trickler 
Ich hab jetzt aber auch viereckige Augen vom vielen Flimmerkiste-glotzen...
Mit 2.08 brauchte es das noch nicht, da hat der Tricker auch die Dauersendung meiner Waage (das kann man an der Waage aktivieren) verstanden.
In 2.10 klappt das nicht mehr. Da will der Trickler scheinbar zwingend die Anfrage stellen und beantwortet haben.
Naaaaaja, vielleicht hilft das ja jemandem, der ein ähnliches Problem mit einer unbekannten Waage hat. Deswegen auch etwas ausführlicher.