Debugging von WebUI-Programmen und Skripten

[MichaelN]

Da immer wieder die gleichen Probleme auftreten, es aber anscheinend noch keinen Beitrag gibt der Tips zum Debugging gesammelt veröffentlicht, habe ich diesen Thread erstellt. Dieser soll als Hilfe zur Selbsthilfe dienen. Es kann auch nicht schaden die umfangreiche Informationssammlung "Tips für Anfänger" nochmal durchzugehen.

Wichtigster Grundsatz: wenn etwas nicht wie erwartet funktioniert muss man sich Daten beschaffen um nachzuvollziehen, wo die Abweichung von der Erwartungshaltung entsteht.

Diese Fragen sollte man sich stellen und beantworten können: Welche Geräte (Datenpunkte) / Systemvariablen sind beteiligt? Welchen Wert hatten diese? Wie haben sich die Werte entwickelt? Welche Bedingungen sind definiert? Sind diese erfüllt? Welchen Wahrheitswert (WAHR / FALSCH) ergaben die Bedingungen zum Zeitpunkt X? Ergibt die gewählte Verknüpfung (UND / ODER) dann am Ende WAHR oder FALSCH? Wahrheitstabelle erstellen! Wurde das DANN, SONST oder SONST-WENN ausgeführt? Wurde überhaupt das "verdächtige" Programm ausgeführt oder ein ganz anderes?
Nicht annehmen, sondern prüfen - z. B. indem man das verdächtige Programm auf inaktiv setzt!
WebUI-Logik verstehen: Unterschied zwischen Trigger und Bedingung!

Generell: sprechende Programm / Variablen / Geräte / Kanalnamen erleichtern das Leben. Im Kanalnamen immer die ursprüngliche Kanalnummern mit beibehalten, damit man weiß um welchen Kanal es wirklich geht. Skripte oder Logs in Foren-Beiträgen immer in Code Tags posten

code.JPG (14.07 KiB) 10199 mal betrachtet

WICHTIG: Ein Programm manuell über Status/Programme zu starten ist KEIN valider Test. Denn dann wird immer ohne jegliche Prüfung das erste DANN ausgeführt. (Ausnahme: aktuelle RaspberryMatic Versionen - hier kann man zwischen einer Ausführung mit Bedingungsprüfung und einer ohne wählen)

Inhalt:
1 ) protokollieren
2 ) haufig getriggert
3 ) Debugging im Systemprotokoll
4 ) Ausloeser feststellen
5 ) Fehlerprotokoll pruefen
6 ) Skripte debuggen
7 ) Diagramme
8 ) DutyCycle oder CarrierSense
9 ) virtuelle Kanale
10) Middleware
11) Programme durchsuchen
12) Programm kaputt
13) Funkkollision
14) Trigger
15) WebUI-Logik


1) Geräte (besser gesagt die einzelnen Kanäle) und Systemvariablen lassen sich in der WebUI unter Einstellungen / Geräte bzw. Einstellungen / Systemvariablen auf "protokolliert" stellen. Alle Änderungen erscheinen dann unter Status&Bedienung/Systemprotokoll


2) ob ein Programm gestartet wurde (was aber nicht IMMER auch bedeutet, das es ausgeführt wurde) kann man unter Status&Bedienung/Programme nachsehen. Auch wichtig für die Identifikation von DutyCycle-Treibern. Programme die im Minutentakt starten sind per se verdächtig.
Da die Liste bei vielen Programmen unübersichtlich wird, kann man mit diesem Skript unter "Programme/Skript testen" eine Liste der kürzlich getriggerten Programme anzeigen lassen; oder mit diesem Skript für einen längeren Zeitraum die Häufigkeit des Triggerns auswerten.


3) Es ist ein ganz probates Mittel eine Systemvariable, Typ Text auf protokolliert zu setzen.

Damit kann man sehr leicht Einträge im Systemprotokoll erzeugen, entweder in der WebUI

log.JPG (21.28 KiB) 10199 mal betrachtet

oder im Skript.

Code: Alles auswählen

dom.GetObject(ID_SYSTEM_VARIABLES).Get("Name der protokollierten Variable").State("Dies ist ein Log-Eintrag");

Alternativ kann man sich per Skript auch Einträge im Fehlerprotokoll erzeugen:
(Fehlerprotokoll kann man unter Einstellungen/Systemsteuerung/Zentralen-Wartung/Log-Datei herunterladen oder im Dateisystem unter var\log\messages finden oder bequemer mit CUxD [Info - Full Syslog] oder SDV einsehen)

Code: Alles auswählen

string s_text = "*Ausgabe für Fehlerprotokoll*";
string s_out;string s_err; system.Exec("logger -t script -p user.debug "#s_text, &s_out, &s_err); 

4) Wenn das noch nicht reicht um dem Problem auf die Spur zu kommen, kann man mit dem Auslöseskript von Alchy herausfinden, warum das Programm ausgelöst wurde: viewtopic.php?f=31&t=35686

Für RaspberryMatic muss ein Klammerbug beseitigt werden: suchen nach
(dom.GetObject(dom.GetObject(oSrc)).Channel()).Name()
und ersetzen durch
(dom.GetObject(dom.GetObject(oSrc).Channel())).Name()


5) Fehler im Skripten sollten sich im Fehlerprotokoll niederschlagen: Einstellungen/Systemsteuerung/Zentralen-Wartung/Logdatei herunterladen

Mit dem Addon CUxD oder Blacks Editor SDV kommt man leichter an das Log. Der SDV ist sowieso ein mächtiges Werkzeug für Skripting und Analyse.


6) Skripte mit Programme/Skript testen oder dem Addon ScriptParser

Code: Alles auswählen

WriteLine ("x");

erzeugt eine Ausgabe beim Testen.
Reichlich WriteLines einstreuen und Zwischenstände von Variablen, etc. ausgeben!
Komplexere Skripte in einzelne Schritte zerlegen, bis man den Schritt findet, der den Fehler erzeugt!
Systematisch vorgehen!
Homematics spezielle Rechenregeln beachten: ausreichend () schützen vor falschen Berechnung!

Systemvariable spricht man folgendermaßen an:

Code: Alles auswählen

! System-Variable auslesen
var Daten = dom.GetObject(ID_SYSTEM_VARIABLES).Get("sysvarname").Value();
! System-Variable beschreiben
dom.GetObject(ID_SYSTEM_VARIABLES).Get("sysvarname").State(Daten);

Die im WWW oft zu findende verkürzte Schreibweise kann dazu führen, das namensgleiche andere Objekte angesprochen werden.

Datenpunkte spricht man folgendermaßen an:

Code: Alles auswählen

! auslesen
! var Daten = dom.GetObject("Kanalname").DPByHssDP("Datenpunktname").Value();
var Daten = dom.GetObject("Steckdose:3").DPByHssDP("STATE").Value();
! beschreiben
! dom.GetObject("Kanalname").DPByHssDP("Datenpunktname").State(wert);
dom.GetObject("Steckdose:3").DPByHssDP("STATE").State(1);

Ausführlicher in einem Beitrag von Alchy: viewtopic.php?f=31&t=30127


7) reicht das immer noch nicht zur Analyse rate ich dazu das Addon CCU Historian zu installieren und sich Diagramme zu erzeugen mit den beteiligten Datenpunkten / Systemvariablen.


8 ) DutyCycle / CarrierSense-Level OK?
DutyCycle = DC ist ein Maß für die Belegung des Funkbandes durch die CCU. Sind 100% erreicht, darf die CCU für 1 Stunde nicht mehr senden.
Gründe für einen zu hohen DC sind oft ungünstige Programmierung (siehe auch Punkt2) oder (weniger kritisch) gerade laufende Firmware-Updates. Auch als Repeater eingesetzte HmIP-PS/PSM können den DC massiv erhöhen. EQ-3 empfiehlt nicht mehr als 2 Geräte als Repeater zu konfigurieren.
weitere Hinweise siehe viewtopic.php?f=26&t=53387#p532517
für erhöhten DC ab FW ab 3.75.6 siehe diese Tipps: viewtopic.php?f=65&t=82334&start=30#p802527 und viewtopic.php?f=26&t=83045&sid=0c46e0ac ... 10#p810100
Der DC wird auf der Startseite angezeigt

CarrierSense = CS ist ein Maß für die Belegung des Funkbandes durch andere Geräte und wird seit FW3. 69 ebenfalls auf der Startseite angezeigt.
Siehe auch detaillierten Info-Artikel zu CarrierSenseLevel viewtopic.php?f=31&t=75532

(Bei orignal CCU mit FW <3.67.10 musste die Anzeige erst aktiviert werden, siehe viewtopic.php?f=31&t=64657)


9) virtuelle Kanäle kontrolliert? Wird vielleicht irrtümlich irgendwo der falsche Kanal geschaltet?


10) Liegt das Problem gar nicht auf der CCU? Middleware (z.B. ioBroker, NodeRED...) oder irgendeine App im Einsatz? Portweiterleitung im Router auf die CCU aktiv?


11) "Programme Drucken" Addon installieren. Dann kannst Du bequem ein durchsuchbares PDF erzeugen.

Textstellen (z.B. Variablen- oder Gerätenamen) in Skripten kann man mit diesem Skript (unter Skript testen ausführen) suchen und die dazugehörigen Programme anzeigen lassen:
viewtopic.php?p=653162#p653162


12) Fieser Bug: vereinzelt kommt es vor, das das Programm kaputt editiert wurde. Vor allem wenn man mit mehreren Tabs arbeitet und sich nicht korrekt abmeldet. Man kann (was vereinzelt geholfen hat) im ersten Schritt eine Kopie des Programms anlegen und schauen ob das Problem damit gelöst ist. Wenn das nicht hilft, dann komplett löschen und manuell neu anlegen.


13) Sendeabstand zwischen zeitgleichen Befehlen berücksichtigt? Also statt zig Befehle "sofort" zu senden besser mit "verzögert um 10 Sekunden" einen Abstand einfügen.


14) Mehrfach den gleichen Trigger im Programm oder aber mehrere Trigger, die nahezu gleichzeitig auslösen? Das kann manchmal dazu führen, das das Programm nicht korrekt ausgeführt wird. In diesem Fall durch umstellen der doppelten Trigger auf "nur prüfen" dafür sorgen, daß nur ein Trigger übrig bleibt. Hier hilft es übrigens, das es egal ist, welcher Trigger ein Programm auslöst. Auch "nur prüfen" wird bei der Bedingungsprüfung natürlich berücksichtigt. Die Triggerbedingung ist dann egal (nur prüfen, Aktualisierung, Änderung) - wenn das Programm erstmal getriggert ist, läuft es von oben bis unten, bis sich ein Block mit wahrer Bedingung findet.


15) und das führt zum 15. Hinweis: Befindet man sich ggf. nur im Irrtum darüber, wie die WebUI arbeitet und alles arbeitet korrekt? Nur die eigene Annahme stimmt nicht? Bitte einmal durcharbeiten: viewtopic.php?f=31&t=4251
Kurzfassung:
jeder Trigger wird für sich geprüft und kann das Programm auslösen
Triggerprüfung und Bedingungsprüfung sind unabhängig voneinander
Die Bedingungen werden immer von oben nach unten geprüft, der erste logisch wahre Bedingungsblock wird ausgeführt

[Black]

Bei den Datenpunkten würde ich etwas ändern..

Zum schreiben....
1. channels.Get (Channelname).DPByHssDP("STATE").State();

Zum lesen
1. channels.Get (Channelname).DPByHssDP("STATE").Value();


State zum lesen auf einen HSSDP bewirkt eine Abfrage über den Xmlrpc type Value, heisst senden eines Telegrammes damit Verzögerung und dutycycle

Value beim Lesen nimmt den letzten bekannten Wert aus der rega selber.


Da du ja den SDV von mir als nützliches Tool schon in den Raum geworfen hast. Ich habe Hier
mal beschrieben, wie sich der SDV zur Fehlersuche in einem Programm unter realbedingungen einsetzen lässt.

Black

[MichaelN]

State zum lesen auf einen HSSDP bewirkt eine Abfrage über den Xmlrpc type Value, heisst senden eines Telegrammes damit Verzögerung und dutycycle

Danke, werde ich anpassen. Dazu noch ergänzend: das gilt für Aktoren mit Netzteil. Bei batteriebetriebenen Aktoren wird keine Abfrage generiert, sondern der letzte bekannte Wert genommen.

Und irgendwie hatte ich noch im Kopf, das zwischen State und Value noch ein Unterschied besteht.
EDIT: ich hab's gefunden. Der Unterschied war, das .Value() auch Werte beschreiben kann, aber keinen Triggerung auslöst. Das war der Grund, warum ich Value() meide. nicht schreibend benutzt werden darf.
Dann gibt es noch .Variable, das aber keine Triggerung auslöst und als Ausgabe immer String liefert. Daher meide ich .Variable absolut.

[jp112sdl]

Bei batteriebetriebenen Aktoren wird keine Abfrage generiert, sondern der letzte bekannte Wert genommen.

Das stimmt nicht. Gerade mit einem HM-LC-Sw1-BA-PCB getestet:

Code: Alles auswählen

var a = dom.GetObject("BidCos-RF.NEQ0604514:1.STATE").State();
WriteLine(#a);

erzeugt ein Funktelegramm mit Burst:

das .Value() auch Werte beschreiben kann, aber keinen Triggerung auslöst. Das war der Grund, warum ich Value() meide.

Hmm, .Value() ist ja unkritisch und wenn du nicht selbst mit purer Absicht da noch in die Klammern schreibst, passiert auch nix.
Umgekehrt würde .State() ja u.U. auch was auslösen, wenn du dort versehentlich was reinschreibst.

[Matsch]

Der Unterschied war, das .Value() auch Werte beschreiben kann, aber keinen Triggerung auslöst. Das war der Grund, warum ich Value() meide.

Simmt das? Kenne ich nicht. Woran sollte der Interpreter denn unterscheiden, ob .Value() als Lese- oder Schreibbefehl gemeint ist?
Und was sollte man schreiben wollen mit einem leeren Wert?
M.E. ist dies per se ein Lesebefehl. Eine Anweisung .Value(<wert>) wird ohnehin als Fehler interpretiert.

Verwechselst du das nicht etwa mit dem Beschreiben von SVs, wobei .State(<wert>) eine Protokolltriggerung auslöst, aber .Variable(<wert>) als einzigen Unterschied nicht?

[MichaelN]

Das mag sein. Ich habe auch nicht immer alles ausprobiert, was ich im Forum an Infos gefunden habe.

Gerade überprüft .Value(<wert>) führt in der Tat zu einem Error

[jp112sdl]

Woran sollte der Interpreter denn unterscheiden, ob .Value() als Lese- oder Schreibbefehl gemeint ist?

Genau wie bei State() auch.

Leere Klammer .Value() = lesen
Befüllte Klammer .Value(34) = schreibe 34

Verwechselst du das nicht etwa mit dem Beschreiben von SVs, wobei .State(<wert>) eine Protokolltriggerung auslöst, aber .Variable(<wert>) als einzigen Unterschied nicht?

Stimmt, Variable() gibt es ja auch noch.


Ich nutze aber auch grundsätzlich .Value() zum Prüfen, weil ich nicht will, dass jedes Mal die Aktoren (auch nicht die netzbetriebenen) unnütz angefunkt werden.

[Matsch]

Leere Klammer .Value() = lesen
Befüllte Klammer .Value(34) = schreibe 34

Habe ich gerade ausprobiert. Eine Anweisung .Value(34) wird nicht ausgeführt und erzeugt einen Fehlereintrag.

[jp112sdl]

Habe ich gerade ausprobiert. Eine Anweisung .Value(34) wird nicht ausgeführt und erzeugt einen Fehlereintrag.

Das ist richtig. Ich wollte nur erklären, wie der Interpreter "lesen" von "schreiben" unterscheidet

[Black]

Value ist Operation_Read: EIn versuch Value mit Übergabeparametern einzusetzen führt zu einem Scriptruntimeerror.

Variable() ist nur anwendbar auf VAR_DP
Variable() liefert beim lesen IMMER den Typ string zurück.
Variable schreibend eingesetzt führt nicht zu einem Triggern.

Black