Flux_bot/schuettgo
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: Planungsdokumente erstellen

Browse Source 
- Marktanalyse (Wettbewerber, Lücken, USPs)
- Anforderungskatalog (Must-Have, Should-Have, Nice-to-Have)
- MVP Definition (Features, Datenmodell, Zeitplan)
- Technische Architektur (Stack, API, DB-Schema)
- Waagen-Integration (Hersteller, Protokolle, Strategie)
This commit is contained in:
FluxKit
2026-02-19 20:21:08 +00:00
commit 76443e6351
5 changed files with 838 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

122
docs/ANFORDERUNGEN.md Normal file
View File

@@ -0,0 +1,122 @@
# SchüttGo - Anforderungskatalog
## 1. Must-Have Features (MVP)
### 1.1 Stammdaten
| Feature | Beschreibung | Priorität |
|---------|--------------|-----------|
| Kundenverwaltung | Name, Adresse, Kontakt, Konditionen | 🔴 Kritisch |
| Lieferantenverwaltung | Lieferanten von Schüttgut | 🟡 Hoch |
| Materialstamm | Schüttgüter mit Preisen, Einheiten | 🔴 Kritisch |
| Fahrzeugstamm | LKW-Daten, Kennzeichen, Tara | 🔴 Kritisch |
| Mitarbeiter | Benutzer, Rollen, Rechte | 🔴 Kritisch |
### 1.2 Kernprozesse
| Feature | Beschreibung | Priorität |
|---------|--------------|-----------|
| Auftrag erfassen | Kunde, Material, Menge, Liefertermin | 🔴 Kritisch |
| Wiegung durchführen | Ein-/Ausfahrt, Brutto/Tara/Netto | 🔴 Kritisch |
| Lieferschein erstellen | Automatisch nach Wiegung | 🔴 Kritisch |
| Lieferschein drucken | PDF-Export, Drucker | 🔴 Kritisch |
### 1.3 Abrechnung
| Feature | Beschreibung | Priorität |
|---------|--------------|-----------|
| Rechnung erstellen | Aus Lieferscheinen | 🔴 Kritisch |
| Preisfindung | Kundenpreise, Staffeln | 🟡 Hoch |
| Sammelrechnung | Mehrere Lieferscheine | 🟡 Hoch |
## 2. Should-Have Features (Phase 2)
### 2.1 Erweiterte Funktionen
| Feature | Beschreibung | Priorität |
|---------|--------------|-----------|
| Dashboard | KPIs, Tagesübersicht | 🟡 Hoch |
| Berichte | Umsatz, Mengen, Kunden | 🟡 Hoch |
| Lagerbestand | Bestandsführung, Inventur | 🟡 Hoch |
| Fuhrpark | Fahrzeuge, Touren, Kosten | 🟡 Hoch |
| Disposition | Tourenplanung | 🟢 Mittel |
### 2.2 Integration
| Feature | Beschreibung | Priorität |
|---------|--------------|-----------|
| Waagen-API | Diverse Hersteller | 🔴 Kritisch |
| DATEV-Export | Buchhaltung | 🟡 Hoch |
| E-Mail | Lieferscheine/Rechnungen versenden | 🟡 Hoch |
| PDF-Vorlagen | Anpassbare Dokumente | 🟢 Mittel |
## 3. Nice-to-Have Features (Phase 3)
### 3.1 Erweiterungen
| Feature | Beschreibung | Priorität |
|---------|--------------|-----------|
| GPS-Tracking | Fahrzeugortung | 🟢 Mittel |
| Fahrer-App | Mobile App für LKW-Fahrer | 🟢 Mittel |
| Kundenportal | Self-Service für Kunden | 🟢 Mittel |
| Automatische Waage | Unbemannte Wiegung | 🔵 Niedrig |
| QR-Code Scanner | Schnelle Identifikation | 🟢 Mittel |
| Statistiken | Erweiterte Analytics | 🔵 Niedrig |
## 4. Nicht-funktionale Anforderungen
### 4.1 Performance
- Seitenladezeit < 2 Sekunden
- Wiegung < 500ms Response
- 100+ gleichzeitige Benutzer
### 4.2 Sicherheit
- DSGVO-konform
- Verschlüsselte Verbindung (HTTPS)
- Rollenbasierte Zugriffskontrolle
- Audit-Log für Wiegungen
### 4.3 Verfügbarkeit
- 99,5% Uptime
- Tägliche Backups
- Disaster Recovery Plan
### 4.4 Usability
- Responsive Design (Desktop, Tablet)
- Max. 3 Klicks für Kernfunktionen
- Deutsche Sprache
- Touch-optimiert für Waagen-Terminal
## 5. Technische Anforderungen
### 5.1 Client
- Moderner Browser (Chrome, Firefox, Edge, Safari)
- Keine Installation erforderlich
- Offline-Fähigkeit für Kernfunktionen (optional)
### 5.2 Waagen-Integration
- RS232/COM-Port Unterstützung
- TCP/IP Unterstützung
- Protokolle: ASCII, Modbus, Herstellerspezifisch
- Unterstützte Hersteller (Ziel):
- Mettler Toledo
- Bizerba
- KERN
- Sartorius
### 5.3 Schnittstellen
- REST API für alle Funktionen
- Webhook-Support für Events
- CSV/Excel Import/Export
- PDF-Generierung
## 6. User Stories
### Waagenbediener
> Als Waagenbediener möchte ich ein Fahrzeug schnell identifizieren können (Kennzeichen), um die Wiegung effizient durchzuführen.
### Disponent
> Als Disponent möchte ich alle offenen Aufträge sehen und Fahrzeuge zuweisen können.
### Buchhalter
> Als Buchhalter möchte ich aus Lieferscheinen mit einem Klick Rechnungen erstellen und an DATEV exportieren können.
### Geschäftsführer
> Als Geschäftsführer möchte ich ein Dashboard mit Tagesumsatz, Mengen und Vergleichszahlen sehen.
---
*Erstellt: 2026-02-19*

291
docs/ARCHITEKTUR.md Normal file
View File

@@ -0,0 +1,291 @@
# SchüttGo - Technische Architektur
## 1. Tech-Stack Übersicht
```
┌─────────────────────────────────────────────────────────────┐
│ FRONTEND │
│ Vue 3 + FluxKit UI + TailwindCSS + TypeScript │
└─────────────────────────────────────────────────────────────┘
│
│ HTTPS / REST API
▼
┌─────────────────────────────────────────────────────────────┐
│ BACKEND │
│ Deno + Oak + TypeScript │
│ ├── Auth (JWT) │
│ ├── REST API │
│ ├── PDF Generator │
│ └── Waagen-Service (optional) │
└─────────────────────────────────────────────────────────────┘
│
│ SQL
▼
┌─────────────────────────────────────────────────────────────┐
│ DATABASE │
│ PostgreSQL 16 │
└─────────────────────────────────────────────────────────────┘
```
## 2. Frontend
### 2.1 Technologie
| Komponente | Technologie | Begründung |
|------------|-------------|------------|
| Framework | Vue 3 | Reaktiv, performant, gute DX |
| UI Library | FluxKit UI | Eigene Komponenten, einheitlich |
| Styling | TailwindCSS | Utility-first, schnell |
| State | Pinia | Offiziell, einfach |
| HTTP | Axios | Standard, Interceptors |
| Routing | Vue Router | Standard |
| Build | Vite | Schnell, modern |
### 2.2 Projektstruktur
```
schuettgo-frontend/
├── src/
│ ├── components/ # Wiederverwendbare Komponenten
│ │ ├── WeighingForm.vue
│ │ ├── CustomerSelect.vue
│ │ └── ...
│ ├── views/ # Seiten
│ │ ├── Dashboard.vue
│ │ ├── Weighing.vue
│ │ ├── Customers.vue
│ │ └── ...
│ ├── stores/ # Pinia Stores
│ │ ├── auth.ts
│ │ ├── weighing.ts
│ │ └── ...
│ ├── api/ # API Client
│ ├── router/ # Routing
│ └── utils/ # Hilfsfunktionen
├── public/
└── package.json
```
## 3. Backend
### 3.1 Technologie
| Komponente | Technologie | Begründung |
|------------|-------------|------------|
| Runtime | Deno 2.x | Sicher, TS native, modern |
| Framework | Oak | Express-ähnlich, stabil |
| ORM | Drizzle ORM | Type-safe, performant |
| Auth | JWT | Stateless, skalierbar |
| Validation | Zod | Schema-basiert |
| PDF | @pdfme/generator | Vorlagen-basiert |
### 3.2 Projektstruktur
```
schuettgo-backend/
├── src/
│ ├── routes/ # API Endpoints
│ │ ├── auth.ts
│ │ ├── customers.ts
│ │ ├── materials.ts
│ │ ├── vehicles.ts
│ │ ├── weighings.ts
│ │ └── invoices.ts
│ ├── services/ # Business Logic
│ │ ├── weighing.service.ts
│ │ ├── invoice.service.ts
│ │ └── pdf.service.ts
│ ├── db/ # Datenbank
│ │ ├── schema.ts # Drizzle Schema
│ │ ├── migrations/
│ │ └── seed.ts
│ ├── middleware/ # Auth, CORS, etc.
│ └── utils/
├── deno.json
└── .env
```
### 3.3 API Design
```
POST /api/auth/login
POST /api/auth/logout
GET /api/auth/me
GET /api/customers
POST /api/customers
GET /api/customers/:id
PUT /api/customers/:id
DELETE /api/customers/:id
GET /api/materials
POST /api/materials
...
GET /api/vehicles
POST /api/vehicles
GET /api/vehicles/search?plate=...
GET /api/weighings
POST /api/weighings/entry # Einfahrt
PUT /api/weighings/:id/exit # Ausfahrt
GET /api/weighings/:id
GET /api/delivery-notes
GET /api/delivery-notes/:id/pdf
GET /api/invoices
POST /api/invoices
GET /api/invoices/:id/pdf
```
## 4. Datenbank
### 4.1 PostgreSQL Schema
```sql
-- Benutzer
CREATE TABLE users (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
email VARCHAR(255) UNIQUE NOT NULL,
password_hash VARCHAR(255) NOT NULL,
name VARCHAR(255) NOT NULL,
role VARCHAR(50) NOT NULL DEFAULT 'operator',
created_at TIMESTAMP DEFAULT NOW(),
updated_at TIMESTAMP DEFAULT NOW()
);
-- Kunden
CREATE TABLE customers (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
name VARCHAR(255) NOT NULL,
address TEXT,
city VARCHAR(100),
postal_code VARCHAR(20),
contact_name VARCHAR(255),
contact_email VARCHAR(255),
contact_phone VARCHAR(50),
notes TEXT,
created_at TIMESTAMP DEFAULT NOW()
);
-- Kundenpreise
CREATE TABLE customer_prices (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
customer_id UUID REFERENCES customers(id),
material_id UUID REFERENCES materials(id),
price DECIMAL(10,2) NOT NULL,
valid_from DATE,
valid_until DATE,
UNIQUE(customer_id, material_id, valid_from)
);
-- Materialien
CREATE TABLE materials (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
name VARCHAR(255) NOT NULL,
category VARCHAR(100),
unit VARCHAR(20) DEFAULT 't',
default_price DECIMAL(10,2),
created_at TIMESTAMP DEFAULT NOW()
);
-- Fahrzeuge
CREATE TABLE vehicles (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
license_plate VARCHAR(20) UNIQUE NOT NULL,
type VARCHAR(100),
tara_weight DECIMAL(10,2),
customer_id UUID REFERENCES customers(id),
notes TEXT,
created_at TIMESTAMP DEFAULT NOW()
);
-- Wiegungen
CREATE TABLE weighings (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
vehicle_id UUID REFERENCES vehicles(id),
customer_id UUID REFERENCES customers(id),
material_id UUID REFERENCES materials(id),
gross_weight DECIMAL(10,2),
tare_weight DECIMAL(10,2),
net_weight DECIMAL(10,2),
entry_time TIMESTAMP NOT NULL DEFAULT NOW(),
exit_time TIMESTAMP,
status VARCHAR(20) DEFAULT 'open',
operator_id UUID REFERENCES users(id),
notes TEXT
);
-- Lieferscheine
CREATE TABLE delivery_notes (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
number SERIAL,
weighing_id UUID REFERENCES weighings(id),
customer_id UUID REFERENCES customers(id),
created_at TIMESTAMP DEFAULT NOW(),
printed_at TIMESTAMP,
emailed_at TIMESTAMP
);
-- Rechnungen
CREATE TABLE invoices (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
number SERIAL,
customer_id UUID REFERENCES customers(id),
total_net DECIMAL(10,2),
total_vat DECIMAL(10,2),
total_gross DECIMAL(10,2),
status VARCHAR(20) DEFAULT 'draft',
created_at TIMESTAMP DEFAULT NOW(),
due_date DATE
);
-- Rechnungspositionen
CREATE TABLE invoice_items (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
invoice_id UUID REFERENCES invoices(id),
delivery_note_id UUID REFERENCES delivery_notes(id),
description TEXT,
quantity DECIMAL(10,3),
unit VARCHAR(20),
unit_price DECIMAL(10,2),
amount DECIMAL(10,2)
);
```
## 5. Deployment
### 5.1 Docker Setup
```yaml
# docker-compose.yml
services:
postgres:
image: postgres:16-alpine
environment:
POSTGRES_DB: schuettgo
POSTGRES_USER: schuettgo
POSTGRES_PASSWORD: ${DB_PASSWORD}
volumes:
- postgres_data:/var/lib/postgresql/data
ports:
- "127.0.0.1:5433:5432"
backend:
build: ./schuettgo-backend
environment:
DATABASE_URL: postgres://schuettgo:${DB_PASSWORD}@postgres:5432/schuettgo
JWT_SECRET: ${JWT_SECRET}
ports:
- "127.0.0.1:8003:8000"
depends_on:
- postgres
frontend:
build: ./schuettgo-frontend
ports:
- "127.0.0.1:3005:80"
depends_on:
- backend
```
### 5.2 URLs
- Frontend: https://schuettgo.kronos-soulution.de
- API: https://api.schuettgo.kronos-soulution.de
---
*Erstellt: 2026-02-19*

102
docs/MARKTANALYSE.md Normal file
View File

@@ -0,0 +1,102 @@
# SchüttGo - Marktanalyse
## 1. Bestehende Lösungen im deutschsprachigen Raum
### 1.1 Praxis EDV - WinWaage / ProWaage
- **Anbieter:** Praxis EDV GmbH
- **Fokus:** Wiegesoftware für Schüttgutbetriebe
- **Features:**
- Waagen-Integration (diverse Hersteller)
- Lieferscheinerstellung
- Kundenverwaltung
- Auftragsverwaltung
- Materialstammdaten
- Statistiken und Auswertungen
- **Plattform:** Windows Desktop
- **Schwächen:** Keine Cloud-Lösung, veraltete UI
### 1.2 Modula / Primus Software
- **Fokus:** ERP für Baustoffhandel
- **Features:**
- Komplette Warenwirtschaft
- Fuhrparkverwaltung
- Tourenplanung
- Rechnungswesen
- **Plattform:** Windows / Client-Server
- **Schwächen:** Komplex, hoher Preis, nicht spezialisiert auf Schüttgut
### 1.3 BuS Baustoff-Software
- **Fokus:** Baustoffhandel und Schüttgut
- **Features:**
- Auftragsabwicklung
- Waagen-Anbindung
- Disposition
- Fakturierung
- **Plattform:** Windows
- **Schwächen:** Ältere Technologie
### 1.4 Wiegemeister / WinScale
- **Fokus:** Reine Wiegesoftware
- **Features:**
- Waagen-Integration
- Verwiegung
- Protokollierung
- **Schwächen:** Nur Wiegefunktion, keine Gesamtlösung
## 2. Marktlücken & Chancen
### 2.1 Identifizierte Lücken
| Lücke | Chance für SchüttGo |
|-------|---------------------|
| Keine moderne Cloud-Lösung | SaaS-Modell, überall nutzbar |
| Veraltete UIs | Moderne, responsive UI |
| Komplizierte Installation | Browser-basiert, kein Install |
| Hohe Lizenzkosten | Flexibles Abo-Modell |
| Keine Mobile-Unterstützung | Responsive + PWA |
| Schlechte Integration | Offene API, Webhooks |
### 2.2 USPs für SchüttGo
1. **Cloud-First:** Keine lokale Installation, automatische Updates
2. **Modernes UI:** Einfache Bedienung, schnelle Einarbeitung
3. **Mobile Ready:** Tablet-Bedienung auf der Waage
4. **API-First:** Integration mit Buchhaltung, ERP, etc.
5. **Flexibles Pricing:** Monatlich kündbar, nach Nutzung
## 3. Zielgruppe
### 3.1 Primäre Zielgruppe
- Kieswerke (5-50 Mitarbeiter)
- Sandgruben
- Steinbrüche
- Schotter-/Splittwerke
- Recyclinghöfe (Bauschutt)
### 3.2 Sekundäre Zielgruppe
- Baustoffhändler mit eigener Waage
- Agrarbetriebe (Getreide, Futtermittel)
- Entsorger (Mülldeponie)
## 4. Preisvergleich (geschätzt)
| Anbieter | Einmalkosten | Monatlich | Wartung/Jahr |
|----------|--------------|-----------|--------------|
| WinWaage | 2.000-5.000€ | - | 500-800€ |
| Primus | 10.000-30.000€ | - | 2.000€+ |
| BuS | 5.000-15.000€ | - | 1.000€+ |
| **SchüttGo** | 0€ | 99-299€ | inkl. |
## 5. Fazit
Der Markt ist geprägt von:
- Etablierten, aber technisch veralteten Lösungen
- Hohen Einmalkosten und komplizierten Installationen
- Mangel an Cloud- und Mobile-Lösungen
**Empfehlung:** SchüttGo als moderne Cloud-Alternative positionieren mit:
- Einfacher Einstieg (Freemium/Testphase)
- Transparente Preise (Abo-Modell)
- Moderne Technik (Vue 3, responsive)
- Schnelle Waagen-Integration
---
*Erstellt: 2026-02-19*

154
docs/MVP.md Normal file
View File

@@ -0,0 +1,154 @@
# SchüttGo - MVP (Minimum Viable Product)
## Release 1.0 - Kernfunktionen
### Ziel
Ein funktionsfähiges System für einen kleinen Schüttgutbetrieb mit 1 Waage.
### Zeitrahmen
- Entwicklung: 4-6 Wochen
- Testing: 1 Woche
- Pilotphase: 2 Wochen
---
## MVP Features
### 1. Authentifizierung & Benutzer
- [x] Login/Logout
- [x] Passwort vergessen
- [x] Benutzerrollen: Admin, Waagenbediener, Büro
- [x] Benutzer anlegen/bearbeiten
### 2. Stammdaten
#### 2.1 Kunden
- [x] Kunde anlegen (Firma, Ansprechpartner, Adresse)
- [x] Kunde bearbeiten
- [x] Kunde suchen/filtern
- [x] Kundenpreise hinterlegen
#### 2.2 Materialien
- [x] Material anlegen (Name, Einheit, Standardpreis)
- [x] Materialkategorien (Kies, Sand, Schotter, etc.)
- [x] Material bearbeiten
#### 2.3 Fahrzeuge
- [x] Fahrzeug anlegen (Kennzeichen, Typ, Tara)
- [x] Fahrzeug einem Kunden zuordnen
- [x] Tara aktualisieren
### 3. Wiegung (Kernmodul)
#### 3.1 Einfahrt
- [x] Fahrzeug auswählen (Kennzeichen-Suche)
- [x] Kunde automatisch ermitteln
- [x] Material auswählen
- [x] Bruttogewicht erfassen
- [x] Wiegung speichern
#### 3.2 Ausfahrt
- [x] Offene Wiegung laden
- [x] Leergewicht (Tara) erfassen
- [x] Nettogewicht berechnen
- [x] Lieferschein erstellen
- [x] Optional: Lieferschein drucken
### 4. Lieferschein
- [x] Automatische Nummer
- [x] Alle Wiegungsdaten
- [x] PDF-Generierung
- [x] Druckfunktion
- [x] E-Mail-Versand (optional)
### 5. Einfache Rechnung
- [x] Rechnung aus Lieferschein(en)
- [x] Kundenpreise anwenden
- [x] PDF-Generierung
- [x] Rechnungsliste
### 6. Dashboard
- [x] Heute: Anzahl Wiegungen, Gesamtmenge
- [x] Offene Wiegungen (Einfahrt ohne Ausfahrt)
- [x] Letzte 10 Wiegungen
- [x] Schnellzugriff auf neue Wiegung
---
## Nicht im MVP
❌ Waagen-Hardware-Integration (manuelle Eingabe im MVP)
❌ DATEV-Export
❌ Lagerbestandsführung
❌ Fuhrparkverwaltung
❌ GPS-Tracking
❌ Kundenportal
❌ Erweiterte Berichte
---
## Technischer Scope
### Frontend
- Vue 3 + FluxKit UI
- TailwindCSS
- Responsive (Desktop + Tablet)
### Backend
- Deno + Oak
- PostgreSQL
- JWT Auth
### Deployment
- Docker
- Nginx Reverse Proxy
- SSL (Let's Encrypt)
---
## Datenmodell (MVP)
```
users
├── id, email, password_hash, role, name
customers
├── id, name, address, contact_name, contact_email, contact_phone
materials
├── id, name, category, unit, default_price
vehicles
├── id, license_plate, type, tara_weight, customer_id
weighings
├── id, vehicle_id, customer_id, material_id
├── gross_weight, tare_weight, net_weight
├── entry_time, exit_time, status
├── delivery_note_id
delivery_notes
├── id, number, weighing_id, customer_id
├── created_at, printed_at, emailed_at
invoices
├── id, number, customer_id
├── total_amount, status, created_at
invoice_items
├── id, invoice_id, delivery_note_id
├── quantity, unit_price, amount
```
---
## Success Criteria
1. ✅ Kompletter Wiegezyklus (Ein-/Ausfahrt) funktioniert
2. ✅ Lieferschein wird korrekt erstellt
3. ✅ Rechnung kann generiert werden
4. ✅ System läuft stabil für 1 Benutzer
5. ✅ Response-Zeit < 1 Sekunde
---
*Erstellt: 2026-02-19*

169
docs/WAAGEN-INTEGRATION.md Normal file
View File

@@ -0,0 +1,169 @@
# SchüttGo - Waagen-Integration
## 1. Übersicht Waagen-Hersteller
### 1.1 Mettler Toledo
- **Marktführer** bei Industriewaagen
- **Modelle:** IND780, IND570, IND500
- **Schnittstellen:**
- RS232 (seriell)
- Ethernet/TCP-IP
- Modbus TCP/RTU
- **Protokoll:** MT-SICS (Standard)
- **Doku:** Gut verfügbar
### 1.2 Bizerba
- **Fokus:** Industriewägetechnik
- **Modelle:** ST-EX Serie, iS Serie
- **Schnittstellen:**
- RS232
- USB
- Ethernet
- **Protokoll:** Bizerba Protocol / ASCII
- **Doku:** Auf Anfrage
### 1.3 KERN
- **Fokus:** Preis-Leistung
- **Modelle:** IFS, IFB, EOB Serie
- **Schnittstellen:**
- RS232
- USB (optional)
- **Protokoll:** ASCII (einfach)
- **Doku:** Gut verfügbar
### 1.4 Sartorius
- **Fokus:** Präzisionswaagen
- **Modelle:** Combics, Signum
- **Schnittstellen:**
- RS232
- Ethernet
- **Protokoll:** Sartorius SBI
- **Doku:** Gut verfügbar
## 2. Schnittstellen-Typen
### 2.1 RS232 (Seriell)
```
┌──────────┐ RS232 ┌──────────┐
│ Waage │ ────────────── │ PC │
└──────────┘ 9-pin/25-pin └──────────┘
```
- **Vorteile:** Einfach, zuverlässig, Standard
- **Nachteile:** Kurze Kabelwege (max 15m), 1:1 Verbindung
- **Baudrate:** Typisch 9600 oder 19200
- **Datenformat:** 8N1 (8 Datenbits, keine Parität, 1 Stoppbit)
### 2.2 Ethernet/TCP-IP
```
┌──────────┐ TCP/IP ┌──────────┐
│ Waage │ ────────────── │ Server │
└──────────┘ Netzwerk └──────────┘
```
- **Vorteile:** Lange Distanzen, mehrere Clients, flexibel
- **Nachteile:** Komplexer, Netzwerk-Abhängigkeit
- **Port:** Herstellerspezifisch (z.B. 4001)
### 2.3 USB
- **Emuliert meist RS232** (virtueller COM-Port)
- Treiber erforderlich
## 3. Protokoll-Beispiele
### 3.1 MT-SICS (Mettler Toledo)
```
Befehl: S # Stable weight
Antwort: S S 123.456 kg
Befehl: SI # Send immediately
Antwort: S D 123.456 kg (D=dynamic/unstabil)
Befehl: Z # Zero/Tare
Antwort: Z A # Acknowledged
```
### 3.2 ASCII Standard (KERN u.a.)
```
Anfrage: <ENQ> # ASCII 05
Antwort: + 123.45 kg\r\n
Format: [Vorzeichen][Leerzeichen][Gewicht][Einheit][CR][LF]
```
### 3.3 Modbus RTU
- Binäres Protokoll
- Register-basiert
- CRC-Prüfsumme
- Komplexer zu implementieren
## 4. Implementierungsstrategie
### 4.1 Phase 1: Manuelle Eingabe (MVP)
```
┌─────────────────────────────────────┐
│ Gewicht: [___________] kg 📥 │
│ │
│ [Waage ablesen] → Manuell eingeben │
└─────────────────────────────────────┘
```
- Kein Hardware-Aufwand
- Sofort einsetzbar
- Fehleranfällig
### 4.2 Phase 2: Lokaler Waagen-Agent
```
┌──────────┐ ┌─────────────┐ ┌──────────┐
│ Waage │─────│ Waagen-Agent │─────│ SchüttGo │
│ RS232 │ │ (lokal PC) │ WS │ Cloud │
└──────────┘ └─────────────┘ └──────────┘
```
- Kleines Programm auf Waagen-PC
- WebSocket-Verbindung zur Cloud
- Gewicht wird automatisch übertragen
### 4.3 Waagen-Agent Architektur
```javascript
// Pseudo-Code Waagen-Agent
const serial = new SerialPort('/dev/ttyUSB0', { baudRate: 9600 });
const ws = new WebSocket('wss://api.schuettgo.../waage/connect');
serial.on('data', (data) => {
const weight = parseWeight(data);
ws.send(JSON.stringify({
type: 'weight',
value: weight,
unit: 'kg',
stable: true
}));
});
ws.on('message', (msg) => {
if (msg.type === 'request_weight') {
serial.write('S\r\n'); // Gewicht anfordern
}
});
```
## 5. Empfohlene Hardware für Pilotphase
### 5.1 Budget-Option (< 500€)
- **KERN EOB 150K50** (150kg/50g)
- RS232 Schnittstelle
- Einfaches ASCII-Protokoll
- Ideal zum Testen
### 5.2 Profi-Option (1.500-3.000€)
- **Mettler Toledo IND570**
- Ethernet + RS232
- MT-SICS Protokoll
- Robust, industrietauglich
## 6. Nächste Schritte
1. [ ] Testwaage beschaffen (KERN oder gebraucht)
2. [ ] Waagen-Agent Prototyp entwickeln
3. [ ] WebSocket API im Backend implementieren
4. [ ] Frontend-Integration (Live-Gewicht-Anzeige)
5. [ ] Protokolle für 2-3 Hersteller implementieren
---
*Erstellt: 2026-02-19*