ich möchte eine Diskussion mit offenem Ausgang anstoßen: eine kostenpflichtige Brautomat32 Pro Version.
Es gibt bereits Tests (bspw. ReverseProxy). Im Ergebnis wäre die Realisierung von Cloud Services ein sehr hoher Freizeit-Aufwand (nicht in 2026 realisierbar). Und es entstehen laufende Kosten. Ob ich den Weg gehe, weiß ich noch nicht. Deshalb frage ich nach offenen & ehrlichen Meinungen.
Natürlich sind die Kosten auch entscheidend. Ich kann die Kosten aktuell nur überschlagen, weil insbesondere Kosten nach Nutzung/traffic nur grob abschätzbar sind. Auf dieser Grundlage werden sich die Kosten zwischen 1 bis 2 Euro pro Monat belaufen. Mein Wunsch wären so viele Pro-User, dass € 1,- pro Monat realisierbar ist. Dafür gibt's in Köln nicht mal mehr ein Stößchen. Wenn es dann mal 1Mio Brautomat User werden, freue ich mich
Hier mein brainstorm
# Managed-Service-Strategie
## Zielbild
Brautomat bleibt im aktuellen Ist-Zustand ein kostenloses Hobbyprojekt mit vollständig lokal nutzbarer Kernfunktion (so wie er jetzt verfügbar ist).
Managed Services sind ausschließlich zusätzliche und optionale Dienste.
Die Grundregel lautet:
- lokal und ohne Cloud voll funktionsfähig
- keine künstliche Verschlechterung des kostenlosen Kernprodukts
- kostenpflichtig sind Hosting, Komfort, Fernzugriff, Synchronisation, Historie und Mehrgeräte-Management
Es wird kein Cloud-zentrierter Brautomat angestrebt.
Stattdessen gilt:
- `Free`: der vollständige lokale Brautomat
- `Pro`: optionale Managed Services
## Bedingungen
Die Managed-Services-Strategie muss folgende Bedingungen einhalten:
- der lokale Brautomat funktioniert ohne Konto, ohne Internet und ohne Abo
- Regelung, Aktorik, Sensorik, FSM und sicherheitsrelevantes Verhalten bleiben lokal
- Cloud-Dienste greifen nicht in den harten Echtzeitpfad ein
- bei Verbindungsabbruch bleibt der lokale Betrieb autonom oder fällt in einen definierten lokalen Safe-State
Bis hierher: alles bleibt, wie es ist.
## Geeignete optionale Pro-Services
### Rezeptbibliothek, Cloud-Backup
Mögliche Leistungen:
- zentrale Speicherung von Rezepten, Backups, Profilen
- Versionierung
- Tags, Notizen und Favoriten
- geräteübergreifender Sync
- Freigabe zwischen Nutzern oder Geräten
Argument:
- hoher Komfortgewinn
- keine Abhängigkeit für den lokalen Braubetrieb
### Alarm-Monitoring
Mögliche Leistungen:
- Push-Benachrichtigungen
- Mail oder Messenger-Anbindung
- Alarmweiterleitung bei Prozessende, Sensorfehlern oder Temperaturabweichungen
- Eskalationsregeln
Argument:
- klarer Mehrwert bei Abwesenheit (Fermenter Modus, Gartenarbeit beim Maischen)
- keine Verlagerung der lokalen Grundwarnungen
### Historie und Analytics
Mögliche Leistungen:
- Langzeitarchiv für Sude und Gärverläufe
- Temperaturhistorie
- Alarmhistorie
- Vergleich früherer Läufe
- Diagnose von Sensor- oder WLAN-Problemen
Argument:
- sinnvoller Premium-Nutzen
- passt gut zu gehostetem Speicher und Auswertung
### InfluxDB- und Grafana-Dashboards
Mögliche Leistungen:
- Managed InfluxDB
- fertige Grafana-Dashboards
- Langzeittrends
- Export oder Connector für fortgeschrittene Nutzer
Argument:
- fachlich attraktiv, aber eher ein Advanced- oder Pro-Thema
- nicht als einziger Premium-Pfad geeignet, da viele Enduser keinen direkten Bezug zu InfluxDB oder Grafana haben
### Remote-Dashboard
Mögliche Leistungen:
- read-only Fernansicht
- aktueller Prozesszustand
- Charts
- Geräteübersicht
- optionale Freigabeansicht
Argument:
- hoher Komfortnutzen
- technisch deutlich unkritischer als Vollfernsteuerung
### Reverse-Proxy für sicheren externen Zugriff
Mögliche Leistungen:
- externer Zugriff ohne Portfreigabe oder DynDNS
- Zugriff nur für erlaubte Geräte, Nutzer oder Sessions
- Vermittlung zwischen Internet und lokalem Brautomat
Argument:
- echter Premium-Mehrwert
- Betriebs- und Sicherheitsaufwand auf Dienstseite rechtfertigt Bezahlung
- lokales Produkt bleibt unangetastet
Wichtige Abgrenzung:
- gut geeignet für Monitoring, Dashboard und eingeschränkte Bedienung
- nicht als Pflichtinfrastruktur für lokalen Betrieb
- nicht als primärer Echtzeitpfad für kritische Steuerung
### Multi-Geräte-Koordination
Brautomat kann aktuell nicht mit einem zweiten Brautomat koordiniert zusammenarbeiten.
Das ist ein plausibler Pro-Service.
Zielbild:
- ein führendes Gerät
- ein gekoppeltes Partnergerät
- gemeinsamer Prozesskontext
- verteilte Aufgaben auf zwei physische Brautomaten
Wichtige Begriffe:
- bevorzugt `Primary/Companion`, `Lead/Assist` oder `Controller/Partner`
- nicht `Master/Slave`
Mögliche Anwendungsfälle:
- Maische auf Gerät A, HLT auf Gerät B
- Sud auf Gerät A, Nachguss auf Gerät B
- zentrale Sicht auf zwei Geräte in einem Dashboard
- gemeinsamer Rezept- oder Batch-Kontext
Zusätzliches Kernargument:
- für Enduser mit größeren räumlichen Abständen zwischen Kesseln ist ein zweiter Brautomat oft die praktischste und robusteste Lösung
- statt langer Sensor- und Aktorwege wird die Steuerung räumlich verteilt
- ein Gerät kann führend bedient werden, während das zweite seine lokale Hardware eigenständig steuert
Technische Bedingung:
- die Lizenzierung kann als Cloud-Service erfolgen
- die eigentliche Gerätekopplung soll direkt im lokalen WLAN laufen
- kein Cloud-Zwang im Regel- oder Sicherheitskern
- bei Verbindungsabbruch müssen beide Geräte lokal autonom weiterlaufen oder in einen definierten lokalen Zustand wechseln
Diese Architektur ist besser als ein echter Cloud-Relay im Echtzeitpfad, weil:
- geringere Latenz
- robuster bei Internetausfall
- besser kontrollierbares Verhalten
- klarer Offline-Fallback
## Technische Zielarchitektur
Die bevorzugte Architektur ist nicht `Cloud first`, sondern `local first mit optionalen Services`.
Zielstruktur:
- Firmware erzeugt lokale Zustände, Snapshots und Ereignisse
- optionale Export- oder Sync-Schicht übermittelt ausgewählte Daten nach außen
- Managed Services konsumieren nur definierte Ereignisse, Historien oder Freigaben
- Rückkanäle bleiben auf unkritische Funktionen begrenzt oder werden klar lokal abgesichert
Wichtig:
- keine Duplizierung konkurrierender Zustandskerne neben der lokalen Firmware
- keine Verlagerung des Prozesskerns in Remote-Dienste
- klare Trennung zwischen Steuerung und Komfortdiensten
## Abo-Modell
Gewünschtes Modell:
- nur `Free` oder `Pro`
- `Pro` ist monatlich kündbar
- Mindestlaufzeit immer ein Monat
- Abrechnung jeweils zum `1.` eines Monats
- Kündigung jeweils zum Monatsende
Praktische Interpretation:
- `Pro`-Funktionen bleiben bis zum Ende des bezahlten Monats aktiv
- der kostenlose lokale Brautomat bleibt auch nach Kündigung vollständig nutzbar
## Mehrwert von Pro
Der Nutzer zahlt nicht dafür, dass Brautomat grundsätzlich funktioniert.
Der Nutzer zahlt für:
- Hosting
- sichere externe Erreichbarkeit
- Benachrichtigungsinfrastruktur
- Speicher und Historie
- Geräteverwaltung
- Mehrgeräte-Koordination
- Komfort- und Betriebsdienste
## Zusammenfassung
- Brautomat bleibt lokal kostenlos
- `Pro` bündelt ausschließlich optionale Managed Services
- die wertvollsten Kandidaten sind Rezeptbibliothek und Cloud-Backup, Alarm-Monitoring, Historie, Reverse-Proxy, Remote-Dashboard und Multi-Geräte-Koordination
- die technische Kernarchitektur bleibt lokal-autonom
- die Cloud ergänzt, aber ersetzt nicht den Brautomat
Nochmal: das ist ein brainstorm. eure Meinung ist gefragt. pro und contra sehr gerne. lasst aber bitte die Fliegenklatsche, Teppichklopfer und andere Gerätschaften zum Verhauen weg.
Innu
