Debugging Node-RED

Diese Anleitung bietet umfassende Verfahren zur Fehlersuche bei Node-RED-Problemen auf dem OV80i-Kamerasystem. Verwenden Sie diese für Reparaturen vor Ort, das Debugging von Produktionsproblemen und die vorbeugende Wartung von Prüfabläufen.

warnung

Sicherheit zuerst: Informieren Sie die Produktion stets, bevor Sie Änderungen an aktiven Prüfsystemen vornehmen. Erstellen Sie Backups, bevor Sie Flows modifizieren.

Notfall-Schnellhilfeverfahren

Kritischer Systemausfall – Sofortmaßnahmen

Schritt	Aktion	Zeit	Ergebnis
1	Status der Kamera-Power-LED prüfen	30 Sek.	Hardware OK verifizieren
2	OV80i Node-RED aufrufen: http://camera-ip/recipes/<recipe-number>/ioblock	1 Min.	Editor-Zugriff bestätigen
3	Nach roten Dreieck-Fehleranzeigen suchen	1 Min.	Fehlerhafte Nodes identifizieren
4	Deploy-Schaltfläche klicken (Full Deploy)	30 Sek.	Alle Flows zurücksetzen
5	Grundlegenden Prüf-Trigger testen	2 Min.	Systembetrieb verifizieren

Systemwiederherstellung (falls Editor nicht lädt)

OV80i-Kameras verfügen über keinen Safe Mode – ein Neustart ist die primäre Wiederherstellungsmethode:

1. Kamera vom Strom trennen (Netzkabel für 10 Sekunden abziehen)
2. Vollständigen Bootvorgang abwarten (alle 4 LEDs stabil – 2–3 Minuten)
3. Node-RED des aktiven Recipes über die recipe-spezifische URL aufrufen
4. Flow-Integrität überprüfen und erforderliche Korrekturen vornehmen
5. Änderungen deployen, um den Normalbetrieb wiederherzustellen

hinweis

URL-Format: http://<camera-ip>/recipes/<recipe-number>/ioblock

Beispiele:

• http://192.168.0.101/recipes/20/ioblock
• http://192.168.0.105/recipes/1/ioblock

Systematischer Debugging-Prozess

Schritt 1: Den Problemumfang identifizieren

Schnelle Bewertungsfragen

Frage	Wenn JA	Wenn NEIN
Können Sie auf die OV80i Node-RED-Oberfläche zugreifen?	Weiter mit Schritt 2	Netzwerk-/Kamerastatus prüfen
Sind Flows im Editor sichtbar?	Weiter mit Schritt 2	Kamera neu starten und erneut versuchen
Sehen Sie Fehlerdreiecke an Nodes?	Diese Nodes zuerst untersuchen	Flow-Ausführung prüfen
Wird die Inspektion ausgelöst?	Einzelne Node-Ausgaben prüfen	Trigger-Eingänge verifizieren

hinweis

Zugriffs-URL: Verwenden Sie das recipe-spezifische URL-Format: http://<camera-ip>/recipes/<recipe-number>/ioblock

Schritt 2: Debug-Monitoring aktivieren

Debug-Nodes zur Fehlersuche hinzufügen

1. Debug-Nodes platzieren an Schlüsselpunkten in problematischen Flows:
   • Nach Trigger-Eingängen
   • Vor und nach Logik-Nodes
   • An den finalen Ausgaben
2. Debug-Nodes konfigurieren für maximale Informationen:
   • Output: Vollständiges Message-Objekt
   • To: Debug-Sidebar
   • Name: Beschreibende Namen (z. B. „After Classification Logic")
3. Alle Debug-Nodes aktivieren, indem Sie deren Schaltflächen im Editor anklicken

Verwaltung der Debug-Sidebar

Debug-Sidebar aufrufen:

• Debug-Tab (Bug-Symbol) im rechten Panel anklicken
• Alte Nachrichten löschen mit dem Papierkorb-Symbol
• Nachrichten filtern, falls zu viele Nodes aktiv sind

Interpretation der Debug-Nachrichten:

• Timestamp zeigt, wann die Nachricht auftrat
• Node-Name zeigt, welche Node die Nachricht erzeugt hat
• Nachrichteninhalt zeigt Datenstruktur und Werte

Schritt 3: Flow-Ausführung verfolgen

Nachrichtenpfad nachverfolgen

1. Bei Trigger-Quelle beginnen (Injection, Timer, externer Eingang)
2. Prüfen, ob jeder Node den erwarteten Input erhält
3. Nachrichtentransformationen bei jedem Schritt überprüfen
4. Stelle identifizieren, an der der Flow stoppt oder falsche Ausgabe erzeugt

Häufige Unterbrechungspunkte im Flow

Node-Typ	Häufige Probleme	Schnellprüfung
Classification Logic	Konfidenzschwelle nicht erreicht	ROI-Ausrichtung prüfen, Modell neu trainieren
Switch Node	Falsche Bedingungslogik	Switch-Regeln und Nachrichteneigenschaften überprüfen
Join Node	Wartet auf unvollständigen Nachrichtensatz	Anzahl der Message Parts prüfen
Function Node	JavaScript-Fehler	Browser-Konsole auf Fehler prüfen
HTTP Request	Netzwerkverbindung	Endpoint manuell testen

Häufige Node-RED-Probleme & Lösungen

Probleme bei der Flow-Ausführung

Problem: Flow wird nicht ausgelöst

Symptome:

• Keine Nachrichten in der Debug-Sidebar
• System scheint inaktiv
• Externe Trigger funktionieren nicht

Diagnoseschritte:

1. Trigger-Quelle prüfen: Manueller Inject, Timer, externer Eingang
2. Verdrahtung überprüfen: Verbindungen zwischen Nodes sicherstellen
3. Manuellen Trigger testen: Inject-Node verwenden, um den Flow-Start zu erzwingen

Lösungen:

Ursache	Lösung	Vorbeugung
Deaktivierte Flows	Auf Deploy → Full Deploy klicken	Regelmäßiges Deployment nach Änderungen
Unterbrochene Verbindungen	Nodes korrekt neu verdrahten	Visuelle Prüfung bei Bearbeitungen
Falsche Timer-Konfiguration	Timing-Einstellungen des Inject-Nodes prüfen	Timing-Anforderungen dokumentieren
Ausfall externer Trigger	I/O-Verdrahtung und Signale überprüfen	Regelmäßige I/O-Tests

Problem: Flows laufen, aber falsche Ergebnisse

Symptome:

• Nachrichten fließen, aber falsche Klassifikationen
• Pass/Fail-Logik funktioniert nicht korrekt
• Inkonsistente Ergebnisse

Diagnoseprozess:

1. Debug-Nodes hinzufügen vor und nach verdächtigen Nodes
2. Erwarteten vs. tatsächlichen Nachrichteninhalt vergleichen
3. Node-Konfigurationen auf korrekte Parameter prüfen

Lösungen:

Problembereich	Prüfung	Behebung
Classification Logic	ROI-Ausrichtung, Modelltraining	ROI neu trainieren oder anpassen
Switch-Bedingungen	Eigenschaftsnamen und -werte	Switch-Logik korrigieren
Nachrichteneigenschaften	Datentypen und Formate	Change-Node zur Formatkorrektur verwenden
Kontextvariablen	Gespeicherte Werte und Scope	Kontextspeicher leeren/zurücksetzen

Performance-Probleme

Problem: Langsame Flow-Ausführung

Symptome:

• Verzögerungen zwischen Trigger und Ausgabe
• Inspektions-Timeouts
• Systemverzögerungen

Performance-Diagnose:

1. Debug-Zeitstempel prüfen, um langsame Nodes zu identifizieren
2. CPU-Auslastung am Kamerasystem überwachen
3. Aktive Debug-Nodes zählen (nicht verwendete deaktivieren)

Optimierungsmaßnahmen:

Performance-Problem	Lösung	Erwartete Verbesserung
Zu viele Debug-Nodes	Nicht verwendete Debug-Nodes deaktivieren/entfernen	10–20 % Geschwindigkeitssteigerung
Komplexe Function-Nodes	JavaScript-Code optimieren	Variable Verbesserung
Hochfrequente Trigger	Verzögerung/Rate-Limiting hinzufügen	Systemüberlastung vermeiden
Große Nachrichtenobjekte	Größe der Nachrichten-Payload reduzieren	Schnellere Verarbeitung

Wartungsverfahren

Tägliche Funktionsprüfungen

Visuelle Flow-Inspektion (5 Minuten)

1. Node-RED-Editor öffnen
2. Auf Fehleranzeigen prüfen (rote Dreiecke)
3. Flow-Verbindungen auf Vollständigkeit prüfen
4. Aktuelle Debug-Nachrichten auf Anomalien überprüfen

Flow-Ausführungstest (10 Minuten)

1. Manueller Auslösetest mithilfe von Inject-Nodes
2. Erwartete Ausgaben in der Debug-Seitenleiste überprüfen
3. Pass/Fail-Logik mit bekannten Gut-/Schlechtteilen testen
4. Externe Kommunikation bestätigen (PLC, Datenbanken)

Monatliche Wartungsaufgaben

Leistungsüberprüfung (15 Minuten)

Checkliste zur Flow-Optimierung:

Aufgabe	Aktion	Hinweise
Debug-Node-Bereinigung	Nicht verwendete Debug-Nodes deaktivieren	Nur wesentliche Debug-Ausgaben behalten
Überprüfung des Context Storage	Nicht benötigte gespeicherte Werte löschen	Speicheraufbau vermeiden
Überprüfung des Fehlerprotokolls	Browser-Konsole auf Fehler prüfen	Wiederkehrende Probleme dokumentieren
Backup-Erstellung	Flows in Backup-Datei exportieren	Mit Datum/Versionsinfo speichern

Konfigurationsvalidierung (20 Minuten)

1. Aktuelle Flows mit dokumentierten Standards vergleichen
2. Sicherstellen, dass alle kritischen Pfade über eine geeignete Fehlerbehandlung verfügen
3. Szenarien zur Fehlerwiederherstellung testen
4. Dokumentation aktualisieren bei Änderungen

Monatliche Tiefenwartung

Umfassende Flow-Analyse (45 Minuten)

Erfassung von Leistungskennzahlen:

• Flow-Ausführungszeiten
• Analyse der Fehlerhäufigkeit
• Muster der Ressourcennutzung
• Kommunikationszuverlässigkeit

Überprüfung der Flow-Struktur:

• Redundante Nodes entfernen
• Doppelte Logik zusammenführen
• Veraltete Konfigurationen aktualisieren
• Komplexe Function-Nodes optimieren

Backup- und Wiederherstellungstest (30 Minuten)

1. Vollständigen Flow-Export erstellen
2. Import-Prozedur auf Backup-System testen
3. Sicherstellen, dass die Backup-Wiederherstellung die Funktionalität erhält
4. Wiederherstellungsverfahren dokumentieren

Diagnosewerkzeuge und -techniken

Integrierte Node-RED-Werkzeuge

Funktionen der Debug-Seitenleiste

Funktion	Anwendungsfall	Zugriffsmethode
Nachrichtenfilterung	Auf bestimmte Nodes fokussieren	Filter-Schaltfläche in der Seitenleiste
Nachrichtenverlauf	Letzte 100 Nachrichten überprüfen	In der Debug-Seitenleiste scrollen
Node-Lokalisierung	Quelle der Debug-Nachricht finden	Node-Namen in der Nachricht anklicken
Nachrichtenexport	Diagnosedaten speichern	Nachrichteninhalt kopieren

Context Data Explorer

Zugriff auf Context Storage:

• OV80i Node-RED-Oberfläche öffnen (http://<camera-ip>/recipes/<recipe-number>/ioblock)
• Zum Tab Context Data wechseln (rechte Seitenleiste)
• Werte des Node-/Flow-/Global-Kontexts anzeigen

Context-Debugging:

• Node Context: Zustand einzelner Nodes prüfen
• Flow Context: Gemeinsam genutzte Flow-Variablen überprüfen
• Global Context: Systemweite Einstellungen überprüfen

Test der Netzwerkkommunikation

Validierung von HTTP-Anfragen:

1. Externe Werkzeuge verwenden (Postman, curl), um Endpunkte zu testen
2. Sicherstellen, dass Antwortformate den erwarteten Daten entsprechen
3. Fehlerbedingungen testen (Timeouts, ungültige Antworten)

Überprüfung der PLC-Kommunikation:

1. PLC-Programmiersoftware verwenden, um die Konnektivität zu überprüfen
2. Zugriff auf Datenregister unabhängig testen
3. Konvertierungen des Datenformats validieren

Notfall-Wiederherstellungsverfahren

Wiederherstellung beschädigter Flows

Symptome einer Beschädigung:

• OV80i Node-RED-Oberfläche lädt keine Flows
• Flows erscheinen nach Kameraneustart leer
• Deployment schlägt wiederholt fehl

Wiederherstellungsschritte:

1. OV80i-Kamera aus- und einschalten:
   • Stromversorgung 10 Sekunden trennen
   • Auf vollständigen Bootvorgang warten (alle 4 LEDs stabil)
2. Auf Node-RED-Oberfläche des Rezepts zugreifen:
   • Navigieren zu http://<camera-ip>/recipes/<recipe-number>/ioblock
   • Bei beschädigten Flows aus Backup importieren
3. Aus Backup wiederherstellen:
   • OV80i-Rezeptimportfunktion verwenden
   • Aktuellste Backup-Datei importieren
   • Alle Verbindungen auf Intaktheit prüfen
4. Wiederherstellung validieren:
   • Alle kritischen Flows testen
   • Externe Kommunikation überprüfen
   • Konfigurationsänderungen aktualisieren

Systemressourcenprobleme

Speicher-/CPU-Überlastung

Sofortmaßnahmen:

1. Nicht benötigte Debug-Nodes deaktivieren in OV80i Node-RED
2. Hochfrequente Timer-Trigger entfernen
3. Komplexe Function-Nodes vereinfachen
4. Kamera aus- und einschalten, um alle Dienste neu zu starten

Langfristige Lösungen:

• Flow-Design für OV80i-Hardware optimieren
• Rate Limiting implementieren
• Nachrichten-Payload-Größen reduzieren
• Wartungsfenster einplanen

Troubleshooting-Checklisten

Checkliste vor der Wartung

• Produktion benachrichtigen über Wartungsfenster
• Aktuelles Flow-Backup erstellen
• Aktuellen Systemzustand dokumentieren
• Rollback-Verfahren vorbereiten
• Backup-Wiederherstellungsprozess testen

Validierung nach der Wartung

• Alle Flows werden erfolgreich deployed
• Manuelle Trigger-Tests bestanden
• Externe Kommunikation überprüft
• Fehleranzeigen zurückgesetzt
• Leistung im akzeptablen Bereich
• Dokumentation aktualisiert

Notfall-Reaktions-Checkliste

• Auswirkungen auf System bewertet
• Produktion benachrichtigt
• Schnellbehebung versucht
• Backup-Wiederherstellung falls erforderlich
• Grundursache identifiziert
• Präventivmaßnahmen umgesetzt

Dokumentation und Protokollierung

Wartungsaufzeichnungen

Erforderliche Dokumentation:

• Datum/Uhrzeit der Wartung
• Identifizierte und behobene Probleme
• Vorgenommene Konfigurationsänderungen
• Erzielte Leistungsverbesserungen
• Zukünftige Empfehlungen

🔗 Siehe auch

• Node-RED-Grundlagen
• Erstellung Ihres ersten Rezepts
• Architektur der Kamerakommunikation
• Troubleshooting von Stromversorgungsproblemen
• Node-RED-Architektur im OV80i

---

tipp

Dokumentieren Sie alle Änderungen, die während Debugging-Sitzungen vorgenommen werden. Dies erleichtert zukünftiges Troubleshooting und baut institutionelles Wissen für Ihr Team auf.