Hobbybrauer.de

Hallo zusammen,

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

Hallo Innu,

erst einmal muss ich dir ein großes Lob für die bisherige Arbeit aussprechen, der Brautomat hat sich zu einem fantastischen Projekt entwickelt und ich möchte ihn nicht mehr missen.

Es ist schön zu sehen, dass du immer weitere Ideen hast und die auch mit uns teilst. Besonders wichtig und richtig finde ich die Klarstellung, dass die eigentliche Brausteuerung weiterhin lokal stattfinden soll und auch dass die bisherigen Funktionen weiterhin kostenlos verfügbar bleiben.

Leider brauche ich die meisten von den angegebenen Cloud-Funktionen nicht. Ich benutze zur Rezeptentwicklung den BrewFather, damit habe ich alle Rezepte online verfügbar. Und durch deine Importfunktion habe ich aus einem Rezept in 2 Minuten meinen Ablaufplan fertig.
Ein Cloud-Backup ist sicherlich hilfreich, da der normale User sicherlich nicht so häufig manuelle Backups macht. Da wäre etwas Automatisches sicherlich nicht schlecht. Als IT'ler bin ich mit Backups allerdings gut versorgt, ich kopiere vor jedem Update die Konfiguration und die gespeicherten Maischepläne.
Alarm-Monitoring kann ich mir für den Fermenter-Betrieb gut vorstellen, den nutze ich bisher allerdings noch nicht. Bei einem Brautag sehe ich keinen großen Vorteil darin, da bin ich sowieso immer direkt dabei.
Die genannten Auswertemöglichkeiten finde ich interessant, wirklich brauchen tue ich sie aber nicht.
Einen Reverse-Proxy kann ich mir wieder gut für den Fermenter-Betrieb vorstellen, beim Brauen brauche ich ihn nicht.

Nichts desto trotz gibt es bestimmt Anwendungsfälle in denen die Funktionen nützlich sind und so wie ich dich kenne wird dir noch viel mehr dazu einfallen. Ob sich daraus aber ein tragbares Geschäftsmodell entwickelt sehe ich eher skeptisch. Selbst bei 2 Euro im Monat wird das maximal die Kosten für das Hosting und ein bisschen Support decken und teurer kannst du das nicht machen, weil's dann wieder kaum einer kauft.

Hallo Jens,

danke für Dein Feedback
Sorry für die späte Rückmeldung. Ich habe das Konzept bzw. die Ideen mittlerweile verworfen. Die rege Beteiligung an einer Diskussion ist eindeutig.
Die Kosten für Cloud Funktionen werden unter den Bedingungen nicht auf null gezogen. Ein "Geschäftsmodell" war nicht der Gedanke, eher das Prinzip Platine & Kabel: ich gehe in Vorkasse (mit größeren Mengen in China), um günstig einzelne Platinen oder Kabel verteilen zu können. Nicht jede Idee ist brauchbar. Deshalb bin ich froh, hier erst das Interesse abgefragt zu haben.
Innu