Debugging von WebUI-Programmen und Skripten

Problemlösungen und Hinweise von allgemeinem Interesse zur Haussteuerung mit HomeMatic

Moderator: Co-Administratoren

MichaelN
Beiträge: 9562
Registriert: 27.04.2020, 10:34
System: CCU
Hat sich bedankt: 696 Mal
Danksagung erhalten: 1608 Mal

Debugging von WebUI-Programmen und Skripten

Beitrag von MichaelN » 08.05.2021, 13:00

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
code.JPG (14.07 KiB) 8087 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.
Unbenannt2.JPG
Damit kann man sehr leicht Einträge im Systemprotokoll erzeugen, entweder in der WebUI
log.JPG
log.JPG (21.28 KiB) 8087 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
weitere Hinweise siehe viewtopic.php?f=26&t=53387#p532517
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
Zuletzt geändert von MichaelN am 23.04.2023, 13:31, insgesamt 48-mal geändert.
LG, Michael.

Wenn du eine App zur Bedienung brauchst, dann hast du kein Smarthome.

Wettervorhersage über AccuWeather oder OpenWeatherMap+++ Rollladensteuerung 2.0 +++ JSON-API-Ausgaben auswerten +++ undokumentierte Skript-Befehle und Debugging-Tipps +++

Benutzeravatar
Black
Beiträge: 5463
Registriert: 12.09.2015, 22:31
System: Alternative CCU (auf Basis OCCU)
Wohnort: Wegberg
Hat sich bedankt: 418 Mal
Danksagung erhalten: 1069 Mal
Kontaktdaten:

Re: Debugging von WebUI-Programmen und Skripten

Beitrag von Black » 08.05.2021, 14:03

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
Wenn das Fernsehprogramm immer mehr durch nervende Werbung unterbrochen wird und der Radiomoderator nur noch Müll erzählt, ist es besser, die Zeit für sinnvolle Dinge zu nutzen -
mal aufs Klo zu gehen, ein Bier zu holen oder einfach mal den roten AUS-Knopf zu drücken. Klick - und weg

Script Time Scheduler V1.3
AstroSteuerung über Zeitmodul flexibel mit Offset / spätestens, frühestens
SDV 5.03.01 Das umfassende Entwicklungs und Diagnosetool für Homematik
Selektive Backups - Nützliche Dinge, die die WebUI nicht kann

Intel NUC6 Celeron 16GB mit 512GB SSD unter Proxxmox mit insgesamt 5 VM: 2 x bloatwarebefreiter Raspberrymatik, 2 x IOBroker als Middleware und einer MariaDB zur Archivierung. Verbrauch: 6W

technical contribution against annoying advertising

MichaelN
Beiträge: 9562
Registriert: 27.04.2020, 10:34
System: CCU
Hat sich bedankt: 696 Mal
Danksagung erhalten: 1608 Mal

Re: Debugging von WebUI-Programmen und Skripten

Beitrag von MichaelN » 10.05.2021, 12:24

Black hat geschrieben:
08.05.2021, 14:03
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.
Zuletzt geändert von MichaelN am 06.02.2022, 12:26, insgesamt 1-mal geändert.
LG, Michael.

Wenn du eine App zur Bedienung brauchst, dann hast du kein Smarthome.

Wettervorhersage über AccuWeather oder OpenWeatherMap+++ Rollladensteuerung 2.0 +++ JSON-API-Ausgaben auswerten +++ undokumentierte Skript-Befehle und Debugging-Tipps +++

jp112sdl
Beiträge: 12085
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 847 Mal
Danksagung erhalten: 2139 Mal
Kontaktdaten:

Re: Debugging von WebUI-Programmen und Skripten

Beitrag von jp112sdl » 10.05.2021, 13:34

MichaelN hat geschrieben:
10.05.2021, 12:24
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:
Bildschirmfoto 2021-05-10 um 13.35.55.png
MichaelN hat geschrieben:
10.05.2021, 12:24
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. :wink:
Umgekehrt würde .State() ja u.U. auch was auslösen, wenn du dort versehentlich was reinschreibst.

VG,
Jérôme ☕️

---
Support for my Homebrew-Devices: Download JP-HB-Devices Addon

Matsch
Beiträge: 5359
Registriert: 30.05.2019, 11:37
System: Alternative CCU (auf Basis OCCU)
Wohnort: Chemnitz
Hat sich bedankt: 113 Mal
Danksagung erhalten: 722 Mal

Re: Debugging von WebUI-Programmen und Skripten

Beitrag von Matsch » 10.05.2021, 13:54

MichaelN hat geschrieben:
10.05.2021, 12:24
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
Beiträge: 9562
Registriert: 27.04.2020, 10:34
System: CCU
Hat sich bedankt: 696 Mal
Danksagung erhalten: 1608 Mal

Re: Debugging von WebUI-Programmen und Skripten

Beitrag von MichaelN » 10.05.2021, 13:59

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
Zuletzt geändert von MichaelN am 10.05.2021, 14:06, insgesamt 1-mal geändert.
LG, Michael.

Wenn du eine App zur Bedienung brauchst, dann hast du kein Smarthome.

Wettervorhersage über AccuWeather oder OpenWeatherMap+++ Rollladensteuerung 2.0 +++ JSON-API-Ausgaben auswerten +++ undokumentierte Skript-Befehle und Debugging-Tipps +++

jp112sdl
Beiträge: 12085
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 847 Mal
Danksagung erhalten: 2139 Mal
Kontaktdaten:

Re: Debugging von WebUI-Programmen und Skripten

Beitrag von jp112sdl » 10.05.2021, 14:00

Matsch hat geschrieben:
10.05.2021, 13:54
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
Matsch hat geschrieben:
10.05.2021, 13:54
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.

VG,
Jérôme ☕️

---
Support for my Homebrew-Devices: Download JP-HB-Devices Addon

Matsch
Beiträge: 5359
Registriert: 30.05.2019, 11:37
System: Alternative CCU (auf Basis OCCU)
Wohnort: Chemnitz
Hat sich bedankt: 113 Mal
Danksagung erhalten: 722 Mal

Re: Debugging von WebUI-Programmen und Skripten

Beitrag von Matsch » 10.05.2021, 14:07

jp112sdl hat geschrieben:
10.05.2021, 14:00
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
Beiträge: 12085
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 847 Mal
Danksagung erhalten: 2139 Mal
Kontaktdaten:

Re: Debugging von WebUI-Programmen und Skripten

Beitrag von jp112sdl » 10.05.2021, 14:09

Matsch hat geschrieben:
10.05.2021, 14:07
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 :mrgreen:

VG,
Jérôme ☕️

---
Support for my Homebrew-Devices: Download JP-HB-Devices Addon

Benutzeravatar
Black
Beiträge: 5463
Registriert: 12.09.2015, 22:31
System: Alternative CCU (auf Basis OCCU)
Wohnort: Wegberg
Hat sich bedankt: 418 Mal
Danksagung erhalten: 1069 Mal
Kontaktdaten:

Re: Debugging von WebUI-Programmen und Skripten

Beitrag von Black » 10.05.2021, 14:14

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
Wenn das Fernsehprogramm immer mehr durch nervende Werbung unterbrochen wird und der Radiomoderator nur noch Müll erzählt, ist es besser, die Zeit für sinnvolle Dinge zu nutzen -
mal aufs Klo zu gehen, ein Bier zu holen oder einfach mal den roten AUS-Knopf zu drücken. Klick - und weg

Script Time Scheduler V1.3
AstroSteuerung über Zeitmodul flexibel mit Offset / spätestens, frühestens
SDV 5.03.01 Das umfassende Entwicklungs und Diagnosetool für Homematik
Selektive Backups - Nützliche Dinge, die die WebUI nicht kann

Intel NUC6 Celeron 16GB mit 512GB SSD unter Proxxmox mit insgesamt 5 VM: 2 x bloatwarebefreiter Raspberrymatik, 2 x IOBroker als Middleware und einer MariaDB zur Archivierung. Verbrauch: 6W

technical contribution against annoying advertising

Antworten

Zurück zu „HomeMatic Tipps & Tricks - keine Fragen!“