[Vorstellung] Konzept Xenia D(ualboiler)

Naja, es kommt weniger auf die Größe der Community an als darauf, dass da genügend fähige und interessierte / motivierte Leute bei sind. Viele Firmen, die sich selbst eher als Geräte- denn als Softwarehersteller sehen, haben ja auch nur kleine DEV-Teams oder gar keine, sondern greifen auf Freelancer zurück.

Ja, das ist mir beim Schreiben auch aufgefallen, aber ich wollte nicht auf meine Polemik verzichten Sorry.

Ja, da hast du (mit beidem) Recht.

Es geht doch nicht ums Nicht-Akzeptieren (das betrifft mich ja gar nicht), sondern @Iskanda hat nach Use Cases gefragt und da habe ich ein paar naheliegende genannt. Mir fallen auch noch weitere ein Aber natürlich ist das ne ganz normale unternehmerische Entscheidung und ich glaube selbst, dass sie unter rein wirtschaftlichen Gesichtspunkten wahrscheinlich nicht sinnvoll ist. Da braucht es dann schon viel Idealismus (für Open Source, nicht für Kaffee).

Ich glaube auch nicht, dass das so einfach ginge. Irgendwo müssten die Hashs der aufgespielten Firmwares ja gespeichert werden. Und da dürfen sie durch die Firmware selbst nicht geändert oder gelöscht werden können. Ich bin kein Embedded-Spezialist aber denke da ist es mit Software allein nicht getan.

Edit: und dennoch muss ich mich ganz schön zusammenreißen, hier nicht aus Spaß an der Diskussion weiter zu machen. Immerhin mache ich das auch beruflich und lebe gut davon, dass unsere Leute und ich DEV-Teams enablen, Dinge mit ihren eigenen Codebasen hinzubekommen, die sie selbst alleine nicht schaffen. Aber auf ein “es geht nicht unter den gegebenen Rahmenbedingungen (wirtschaftliche und vermutlich auch Hardware der Maschine)” können wir uns sofort einigen

 

Bei mir auf der Arbeit (Kraftwerk mit Dampfkesseln / KWK-Anlage) passiert das - wie erwähnt - über eine Prüfsumme.
Sobald ein fehlersicherer Teil der Programmierung geändert wird (was natürlich nicht jeder darf), ändert sich im Hintergrund die Prüfsumme. Diese Prüfsumme wird jährlich vom TÜV abgefragt und dokumentiert. Sollte es also zu sicherheitsrelevanten Änderungen kommen, wird das nachweislich dokumentiert und kann nicht rückgängig gemacht werden. Da steckt aber natürlich auch entsprechende Hardware, eine große Firma und viel Geld dahinter.
Ob sich sowas (in abgewandelter Form) ohne viel Aufwand implementieren lassen könnte, weiß ich wie gesagt nicht, da ich kein Programmierer etc. bin.

Sollte nur als Anregung dienen, dass sicherheitsrelevante Änderungen nicht zwingend auf dich als Hersteller zurückfallen müssen und gleich den Knast bedeuten Dass das bei einer Espressomaschine aber vielleicht grundsätzlich etwas "drüber" ist, ist mir auch bewusst.
Aber ich verstehe deine Sichtweise zu 100% und persönlich würde ich da ohnehin nichts ändern - das überlasse ich den Profis.

 

ja genau so etwas meinte ich! Das war auch nicht meine Erwartungshaltung, dass das jetzt sofort da ist.
Zum Thema Backlog - ich kenne es von anderen Projekten dass Vorschläge über Github eingereicht werden und dort dann klar nachvollziehbar ist für alle Parteien was wann wie gemacht wird. Plant Ihr so etwas oder gibt es das schon?

 

Es passiert hier, was halt immer bei Release von "V1" (sicher schon etwas höher) passiert
Die bestehende, sehr gute und initiale Funktionalität rückt umgehend ein bisschen in den Hintergrund, obwohl die echte Arbeit auf breiter Nutzerbasis damit noch aussteht.
Es geht direkt um die (bessere) Zukunft, neue Features, angeblich ungenutzte Potenziale und sehr wichtige Ergänzungen.
Jeder sieht das Ganze dabei aus seiner mehr oder minder weiten Sandflohperspektive.
Waagennutzer sehen präzise(re) Bezugsssteuerungen, OSS Freaks sehen Features, Forks und Frotzeleien und ein paar Bastler erhoffen sich schon die ersten Vorbereitungen für Hardwareergänzungen.
Neue, bessere, schnellere und doppelt gehäkelte APIs will sowieso jeder für alles, oder zumindest für sich und seinen (primär relevanten) Einsatzzweck.
Spaß beiseite, jetzt geht es doch erstmal um den Abschluss von V1, Lokalisation und Fehlerbehebung.
Gerade die alten Hasen hier aus der Entwicklung wissen doch, dass der Benutzer Dinge schafft die kein Testbetrieb raufholt. Der Benutzer ist halt der Benutzer. Er macht kaputt, hebelt aus und findet Lücken und Probleme wo gar keine sind.
Ich z.B. helfe dann nach Erhalt auch gerne mit, wenn es um die Erstellung der deutschen Sprachdatei oder Bugreports geht.

Bei Holgers Erfahrung und den offenbar guten Leuten werden das schon wenige(r) Fehler werden, auch da der Einsatzzweck einer Espressomaschine mit 2 Kippschaltern und 4 Schalterstellungen nur mittelgroß galaktisch ist.
Der Umfang ist aber auch bei einer nur mittelgroßen Galaxie gewaltig.
Ich sehe hier aktuell eine tolle Perspektive/Maschine mit Steuerung von Temperatur, Druck, Pumpenleistung, Boilersteuerung und einer mächtigen Skriptsprache. Ein Haufen Zeug, mit dem die neuen Besitzer erstmal unheimlich viel Potenzial auszuschöpfen haben.
So mancher Besitzer wird sich ein schönes Rezept oder zwei auf die Hebel legen und die Xenia ab da einfach benutzen.
Andere werden skripten, testen, wurschteln und trotzdem ab und an mal nen Kaffee trinken.

Es ist sicher eine gute Idee, die Feature Requests zeitnah irgendwo einreichbar zu machen.
Aber selbst das ist ja kein simpler Schnippschnapp und es geht.
Es braucht eine Anzeige der aktuell angefragten Features um Doppeleinreichungen zu vermeiden. Das klappt in 60% der Fälle dann auch...
Es wird manuelle Arbeit sein, die mehrfachen Einreichungen abzugleichen, obwohl man sie öffentlich sieht.
Die Anreicherung eines Features ist die nächste Sache, wenn eine gute Idee zu einer bestehenden Einreichung kommt.
Man kann das natürlich auch im Thread sammeln, aber ich glaube das wird schnell sehr viel, da die vorige Seite oder zwei für Einige schon eine Meile weit weg ist. etc. etc.
Einfach viel zusätzliche Arbeit, die aktuell vielleicht einfach nicht geleistet werden kann.
Dauervollgas schafft kein Team.
Es wird etwas passieren, da bin ich sicher. Wenn es passiert, dann wird es auch gut werden.

Der aktuelle Versatz, zwischen den ersten DB beim Kunden und einem neuen Release in der mittleren Zukunft, füllt sich deswegen halt gerade mit "Flausen", weil es aktuell "nur" die Zukunft zu besprechen gibt und keine Diskussion um z.B. neue Skripte. Das wird doch aber demnächst dann anstehen, was allen Lesern und Besitzern sicher Freude machen wird.
Vielleicht mal nen Gang zurückschalten, für sich selbst überlegen was man einreichen würde, wenn es ginge und ein bisschen weiter die Vorfreude und Teilhabe am Prozess zelebrieren.
Nur meine 2 Pfennig und einen schönen Abend

 

Hallo,
Wird sich mit den neuen Funktionalitäten etwas ändern, bzgl. des Wartungsprozess. Zum Beispiel, sollte man vielleicht einen bestimmten Skript schreiben, wenn man das Blindsieb (Rückspülung), bzw. die Espazzola nützt? Oder der Druckverlauf hat damit nichts zu tun, und es ist alles irrelevant? Zum Beispiel, ich würde mir vorstellen, dass man keine 8bar braucht.

Als zusätzliche Funktionalität zu der Webinterface, könnte auch vielleicht eine "Erinnerungsfunktion" eingefügt werden ("Moment Mensch, du hast mich seit 4,3 Monaten / 643 Shots nicht mehr gereinigt!"). Sicherlich nicht das wichtigste und dringendste, aber vielleicht einfach zu implementieren (für die V2.5)?

 

So, habe jetzt auch eine Maschine geordert.

Eine Frage hätte ich noch. Passen da auch andere Siebträger die normalerweise in eine E61 gehören?

 

Hier ist immer von einer Liste die Rede, wie der Stand der Auslieferung ist. Auf der Webseite habe ich nichts gefunden…

Ich habe meine verbindliche Bestellung für das Upgrade im März 2022 abgegeben, habe aber noch keine Info, ob ind wann ich dran bin. Meine Frage an diejenigen, die schon im Genuss eines Upgrades sind: Wann habt ihr denn bestellt?

 

Ok, dann müssen die Mails wohl in beide Richtungen im Spam verschwinden. Ich habe keine Info erhalten und meine Mails von gestern und vom 20.1. wurden nicht beantwortet.

 

Ist eure Abstastrate zur Netzfrequenz synchronisiert? Bei einer Vibrationspumpe kommt es stark darauf an, ob ich vor, während oder nach einem Pumpstoß messe. Das macht teils über ein halbes bar aus und würde diese Schwankungen locker erklären. Eigentlich ist die Messung sogar zu gut, als dass sie nicht synchronisiert ist, was allerdings auch am Phasenanschnitt liegen kann, so dass pro Pumpstoß deutlich weniger als ein halbes bar Varianz entstehen könnte.

edit: Das Ganze sieht man übrigens gut, wenn man den analogen Ausgang des Drucksensors auf ein Oszi legt. Da sieht man dann dass die Pumpstöße die größte Variationen ist, und man erkennt dann auch schnell dass beispielsweise die Decent mit ihren geraden Verläufen nicht wirklich die Realität zeigt.

 

Hier noch mein Edit aus dem letzten Post, der sich vermutlich mit deiner Antwort überschnitten hat. Falls es nicht synchronisiert ist, ist das ein klassischer Alias-Effekt.