xsud ⟷ json Mmum

[Kolbäck]

Moin!

Bevor ich selbst einen kleinen Webservice dafür schreibe: Gibt es schon eine Konvertierung zwischen Rezept-Exporten von Maischemalzundmehr in JSON zum xsud-Format, das der kleine Brauhelfer versteht?

Oder gibt es andere Software, die das Mmum-JSON versteht?

/thomas

[Parlue]

Wenn Du dabei ist wäre eine Konvertierung nach Beerxml auch sehr gut. Dann könnte man die Rezepte gleich in den Grainfather importieren.

LG
Dirk

[London Rain]

Toll wäre wenn die Importfunktion im kleinen Brauhelfer selbst landen würde. Wenn du die Konvertierungsroutine eh schreibst müsste sich doch vielleicht ein KBH-Mitentwickler finden, der das dann noch direkt ins Programm integriert.

[schliene]

Wenn, dann würde ich die paar Daten selber eingeben.
Import in den KBH macht wenig Sinn, da viele Namen und Werte eh andere sind(Sudausbeute, Malznamen, Hopfennamen, Alphawerte etc.).
Wenn, dann müsste jeder Wert einzelnd abgefragt werden und dann kann ich gleich einen neuen Sud anlegen.

Beerxml und xsud sind beide xml basierend, daher lässt sich im KBH auch in Beerxml exportieren.

Auf den Webservice bin ich gespannt.
Poste mal hier deinen Werdegang.

Grüße
Markus

[Kolbäck]

Dirk: Ich werde mit dem anfangen, wovon ich selbst nutzen habe. BeerXML ist da noch nicht bei. :)

LondonRain: Ja, der Gedanke kam mir auch. Das müsste ich dann aber von vornherein gleich mit dem Ziel schreiben, nicht als Webservice. Das sind zwei verschiedene Sprachen, hinterher integrieren ist nicht.

Markus: Ja, da sprichst du das Hauptproblem an - die Konvertierung des Formats ist im Prinzip simpel, die unterschiedlichen Benennungen, Einheiten etc. zu überführen nicht. Ich weiß deshalb auch selbst nicht, ob es mir selbst den Aufwand Wert ist, ober ob ich mit "Rezeptübernahme Schüttung" des KBH weiter leben kann.

Auf jeden Fall wollte ich mal hören, ob es schon "prior work" gibt und was andere davon halten, also schonmal danke!

gruß
/thomas

[Parlue]

Schade, hätte ja klappen können :-)

LG

Dirk

[nrtn]

Ein partieller Import ist nicht allzuschwer - für Malze und Hopfen zumindest. Die zusätzlichen Zutaten und vor allem in der Beschreibung versteckten Infos (WP Hopfengaben und Rest-Isomerisierungszeit z.B.) eher unmöglich. Ich schlage vor entweder eine strukturierte Datenquelle zu nehmen oder die Rezepte manuell zu übertragen (mal ehrlich - die 10min. Zeit sind's auch nicht wert)...

[olibaer]

Hallo,

Ein partieller Import ist nicht allzuschwer - für Malze und Hopfen zumindest. Die zusätzlichen Zutaten und vor [...]

Ich bin vom Gegenteil überzeugt.

Der schwierigste Teile solche einer Schnittstelle - mit welcher Technik auch immer umgesetzt - ist die Konsolidierung und Pflege der verbindlich geltenden Stammdaten für Roh-, Hilfs- und Betriebsstoffe, die in Varianten und/oder entlang von gültigen Zeitachsen, gepflegt werden müssten. Vorstellen könnte ich mir z.B. solch eine Stammdatenstruktur:

Master Term:
1000 Perle
1010 ...
2000 Gerstenmalz Hell
2010 ...
3000 Milchsäure
3010 ...
4000 Gerstenrohfrucht
4010 ...

Ländercodes:
00 (keine Angabe)
01 DE
02 US
03 CZ
...

Jahrgang/Herstellungsjahr:
00 (keine Angabe)
16
17
18
19
...

Darreichungsform:
00 (keine Angabe)
01 Dolden
02 Pellets TYP90
03 Pellets TYP45
04 Extrakt
05 Iso-Extrakt
06 Hopfenöle
07 flüssig
08 lose
09 vorgeschrotet
...

Brauwertkonzentration in %(immer aufgerundet angeben, z.B. Alphasäure, Extrakt lufttrocken, Milchsäuregehalt...)
00(keine Angabe)
01
02
..
05
06
..
47
48
..
75
76
77
78
...

Zusatzangabe I: (Für den 1000er Nummernkreis Ölgehalt, für den 2000er Nummernkreis Farbe in EBC, sonst 00 - immer aufrunden)
00 (keine Angabe)
01
02
03
04
05
06
...

So etwas liesse sich dann in einem Rezept, dass ausser "Perle" nicht viel weiß, zu einer Materialnummer codieren die so aussieht:
1000 00 00 00 00 00
So etwas liesse sich dann in einem Rezept, dass einiges von "Perle" weiß, zu einer Materialnummer codieren die so aussieht:
1000 01 16 02 05 00
So etwas liesse sich dann in einem Rezept, dass alles von "Perle" weiß, zu einer Materialnummer codieren die so aussieht:
1000 01 16 02 05 03

Die Leerzeichen in den Beispielen dienen nur der Übersicht.

Auf der Pflegeseite müsste der Anwender nur einmalig zuweisen, dass "dieser" Rohstoff 1000 Perle ist - den Rest übernimmt die Software beim Export/Import.
Jeder exportiert das was hat er hat und jeder importiert das was er kann und Software A muss nicht wissen wie Software B mit Stammdaten umgeht und umgekehrt.

Für ein (Gersten)Malz könnte das z.B. so aussehen:
2000 00 00 00 00 00

oder so ...
2000 01 16 08 77 04
(-> Helles Gerstenmalz aus Deutschland, geerntet 2016, ungeschrotet mit einem Extrakt lufttrocken von 77 % und einer Farbe von 4 EBC )

oder so ... 2000 00 00 00 00 04
(-> Helles Gerstenmalz mit 4 EBC)

Milchsäure 80% könnte so aussehen:
3000 00 00 07 80 00



So oder ähnlich könnte ich mir das mit der Konsolidierung von Stammdaten vorstellen(längst nicht zu Ende gedacht).
Man müsste nur einmalig festlegen, welche Materialien durch die ersten 4 Stellen repräsentiert werden und der Rest ergibt sich dynamisch aus dem jeweiligen Eifer des Anwenders bzw. aus den Möglichkeiten der jeweiligen Software. Jeder trägt bei was er kann und kann weg lassen was er nicht erfassen möchte oder im Kontext einfach nicht verfügbar ist - oder nicht exportiert oder importiert werden soll.

... jetzt kann man über die Schnittstellentechnik als Soche reden ;-)


Gruß
Oli

[schliene]

Eine Schnittstelle ist möglich, allerdings rechnet jedes Programm etwas anders.
D.h. IBU-, Malzangaben, Sudausbeuteberechnung ... und zig andere Werte werden beim Import übernommen und von dem Programm nach seinen Berechnungen wieder umgerechnet.

Wenn ich die Daten selber eintippe, dann gleiche ich im Bedarfsfall die Werte so an, dass die Verhältnisse hinkommen und verlasse mich nicht auf einen Import.

Beim Sourcecode vom KBH wird beim Import einer .xsud jeder Wert einzelnd abgefragt. Gibt es einen error, dann wird der Import abgebrochen.Nicht bekannte Werte in der Rohstoffliste werden mit Nachfrage ersetzt.

Ich bleibe beim eintippen, bin aber auch gespannt, ob sich jemand an eine Importmöglichkeit traut.

[Kolbäck]

Ja, mir ging's ja erstmal darum, das Überführen der Schüttung und des Hopfen zu erleichtern. Und die Zuordnung der Zutaten braucht dann schon Handarbeit, solange es keine konsitenten Stammdaten gibt, wie von Oli vorgeschlagen. (Und daran will ich mich keineswegs wagen!)

Schliene: Das ist ein weiterer guter Punkt. Jeder will beim Import was anderes übernehmen und eine Automatisierung würde Entscheidungen treffen müssen, die nicht allen passen. Also doch wieder Handarbeit.

Ich sehe also ein, was das ganze für eine Schnapsidee war. Trotzdem danke für die Diskussion!

/thomas

[nrtn]

Ganz einfach: Du hast Zutaten im Rezept und Inventarzutaten im Rohstoffregister - jetzt einfach dem Benutzer die Rezeptzutaten zeigen und wählen lassen welche Rezeptzutaten er durch welche Inventarzutaten ersetzen will. Ich für mich hab mir das weggespart indem ich eine Rohstoffliste mit allen in MMuM vorkommenden Zutaten hab - skaliert zwar nicht und funktioniert nur für mich, aber MMuM skaliert so ja auch nicht.

@olibaer: Ich hab nicht die geringste Ahnung warum du Zutaten hashen willst - in der Regel macht man das über UIDs und z.B. Relationen, dafür bräuchte man aber eine zentrale Datenbank von Zutaten und genau das meine ich mit "strukturierter Datenquelle". Das Problem ist doch, dass z.B. ein Malz in MMuM ein Textfeld ist und nicht eine Auswahl vordefinierter Malze. Der Grund ist recht klar: Dann muss niemand die Zutatendatenbank vollständig halten - das ließe sich aber durch kollaborative Lösungen vermeiden (wie man beim beersmith sieht - unabhängig davon wie "schön" die das umgesetzt haben).

[chriiisss]

Gibt es mittlerweile was neues dazu? Ein Import von MMuM in den Brauhelfer wäre echt wahnsinnig geil!

[London Rain]

Auf einem Entwicklungsbranch vom Brauhelfer ist das wohl schon umgesetzt, aber gremmel müsste dann mal ein neues Release veröffentlichen. Das wäre toll!

[chriiisss]

Das hört sich doch gut an! Dann warten wir mal das nächste Release ab.