Debugging von WebUI-Programmen und Skripten

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

Moderator: Co-Administratoren

MichaelN
Beiträge: 3128
Registriert: 27.04.2020, 10:34
System: CCU
Hat sich bedankt: 235 Mal
Danksagung erhalten: 422 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. Wenn noch jemanden was einfällt: bitte ergänzen.

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! 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) 788 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.


1) Geräte und Systemvariablen lassen sich in der WebUI 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) 788 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");
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

Code: Alles auswählen

(dom.GetObject(dom.GetObject(oSrc)).Channel()).Name()
und ersetzen durch

Code: Alles auswählen

(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? Sendeabstand zwischen zeitgleichen Befehlen berücksichtigt?

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.

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.
Zuletzt geändert von MichaelN am 06.09.2021, 09:18, insgesamt 19-mal geändert.

Benutzeravatar
Black
Beiträge: 4058
Registriert: 12.09.2015, 22:31
System: Alternative CCU (auf Basis OCCU)
Wohnort: Wegberg
Hat sich bedankt: 140 Mal
Danksagung erhalten: 489 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
SDV 4.07.03E Das umfassende Entwicklungs und Diagnosetool für Homematik

technical contribution against annoying advertising

MichaelN
Beiträge: 3128
Registriert: 27.04.2020, 10:34
System: CCU
Hat sich bedankt: 235 Mal
Danksagung erhalten: 422 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.

jp112sdl
Beiträge: 9340
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 572 Mal
Danksagung erhalten: 1330 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

PN sind deaktiviert!

Matsch
Beiträge: 1920
Registriert: 30.05.2019, 11:37
System: CCU
Wohnort: Chemnitz
Hat sich bedankt: 30 Mal
Danksagung erhalten: 218 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: 3128
Registriert: 27.04.2020, 10:34
System: CCU
Hat sich bedankt: 235 Mal
Danksagung erhalten: 422 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.

jp112sdl
Beiträge: 9340
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 572 Mal
Danksagung erhalten: 1330 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

PN sind deaktiviert!

Matsch
Beiträge: 1920
Registriert: 30.05.2019, 11:37
System: CCU
Wohnort: Chemnitz
Hat sich bedankt: 30 Mal
Danksagung erhalten: 218 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: 9340
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 572 Mal
Danksagung erhalten: 1330 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

PN sind deaktiviert!

Benutzeravatar
Black
Beiträge: 4058
Registriert: 12.09.2015, 22:31
System: Alternative CCU (auf Basis OCCU)
Wohnort: Wegberg
Hat sich bedankt: 140 Mal
Danksagung erhalten: 489 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
SDV 4.07.03E Das umfassende Entwicklungs und Diagnosetool für Homematik

technical contribution against annoying advertising

Antworten

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