[wiregate] Plugins debuggen

[JNK]

Hallo, gibt es irgendeine Möglichkeit rauszufinden, was das Plugin da getrieben hat? Bei 2.4s wird sofort nach Druck auf die Klingel die passende Ansage abgespielt, bei den längeren Zeiten dauert es eben genau so lange, wie angegeben.

plugin.log:

2011-09-21 08:06:48.125,Klingel,Klingel,2.4s, 
2011-09-21 08:06:55.679,Klingel,Klingel,2.4s, 
2011-09-21 08:07:20.755,Klingel,Klingel,2.4s, 
2011-09-22 08:09:13.626,Klingel,Klingel,2.4s, 
2011-09-22 08:30:53.408,Klingel,Klingel,2.4s, 
2011-09-22 08:30:59.257,Klingel,Klingel,2.4s, 
2011-09-22 10:51:16.082,Klingel,Klingel,2.4s, 
2011-09-22 10:51:34.790,Klingel,Klingel,2.4s, 
2011-09-22 15:50:32.647,Klingel,Klingel,2.4s, 
2011-09-23 08:07:09.269,Klingel,Klingel,2.4s, 
2011-09-23 12:34:12.860,Klingel,Klingel,2.4s, 
2011-09-24 10:46:41.524,Klingel,Klingel,2.4s, 
2011-09-24 12:52:09.416,Klingel,Klingel,2.4s, 
2011-09-24 13:56:44.912,Klingel,Klingel,2.4s, 
2011-09-24 13:56:59.694,Klingel,Klingel,2.4s, 
2011-09-24 15:55:17.125,Klingel,Klingel,2.4s, 
2011-09-27 14:31:56.878,Klingel,Klingel,18.9s, 
2011-09-27 15:17:09.670,Klingel,Klingel,2.4s, 
2011-09-28 13:31:08.170,Klingel,Klingel,2.4s, 
2011-09-28 13:31:22.560,Klingel,Klingel,2.4s, 
2011-09-28 18:40:50.094,Klingel,Klingel,2.4s, 
2011-09-29 08:30:50.027,Klingel,Klingel,19.2s, 
2011-09-29 08:30:52.454,Klingel,Klingel,2.4s, 
2011-09-29 10:24:36.056,Klingel,Klingel,2.4s, 
2011-09-29 10:24:46.747,Klingel,Klingel,2.4s, 
2011-09-29 13:09:36.970,Klingel,Klingel,2.4s, 
2011-09-29 15:19:37.953,Klingel,Klingel,2.4s, 
2011-09-29 18:36:02.120,Klingel,Klingel,2.4s, 
2011-09-30 08:33:03.087,Klingel,Klingel,19.8s, 
2011-09-30 08:33:05.587,Klingel,Klingel,2.4s,

eib.log

2011-09-30 08:32:43.141,A_GroupValue_Write,1.1.31,0/0/3,01,1,DPT_Switch,1.001,0,low,6,T_DATA_XXX_REQ,0 
2011-09-30 08:33:03.265,A_GroupValue_Write,1.1.31,0/0/3,01,1,DPT_Switch,1.001,0,low,6,T_DATA_XXX_REQ,0

Gruss,

der Jan

[makki]

Schwer zu sagen, so auf anhieb fällt mir da wenig ein..
Wie wird denn abgespielt? (also wie sieht das Plugin aus)

Die Variante von Chris macht das recht geschickt, Sachen die blockieren sind in Plugins generell nicht so gut (was aber keine 18s erklärt)..

Makki

[JNK]

Plugin sieht so aus:

# do all configs here:
my $knx_addr = '0/0/3'; # address to play doorbell

#################################################################
# do not change anything below, all config stays above
#################################################################
# subscribe plugin and call it only when necessary
$plugin_subscribe{$knx_addr}{$plugname} = 1;
$plugin_info{$plugname.'_cycle'} = 0;
# handle telegrams
return if ($msg{'dst'} ne $knx_addr); # early exit if the message wasn't meant for us
if ($msg{'apci'} eq 'A_GroupValue_Write') # 
{
  if( $msg{'data'} eq '01' ) # play
  {
  #  my $debug = `mpc pause`; # pause mpd
  #  sleep 1;
    my $debug = `aplay /mnt/nas_music/Ansagen/Klingel.wav`;
  #  sleep 1;
  #  my $debug = `mpc toggle`; # resume mpd
    
    return 'Klingel';
  } else {
    return $msg{'data'};
  }
}

[Bodo]

aplay /mnt/nas_music/Ansagen/Klingel.wav

Hoi

Kann es sein, dass Dein NAS runtergefahren ist und dann zum hochstarten eben 16 sec. braucht?

[makki]

Nachdem ich heute nochmal den übersichtlichen source dazu studiert habe ohne einen Fehler zu finden: die These von Bodo klingt gut: es dauert halt so lang; warum auch immer.
Wiegesagt, der ansatz von Chris ist da besser, blocking ist im plugin nicht gesund..

Makki

[JNK]

Hallo zusammen,

also nachdem ich jetzt wieder zu Hause angekommen bin, habe ich mal ins Log des NAS geguckt. Und siehe da: Ich denke Bodo hat recht. Jedesmal, wenn das Plugin lange gebraucht hat, findet man etwas wie

Sep 27 14:31:39 scemd: SCEMD: disk 1 wake up from hibernation
Sep 27 14:31:46 scemd: SCEMD: disk 2 wake up from hibernation

.

Ich werde dann mal das File direkt aufs Wiregate kopieren. Und den Non-Blocking Teil werde ich mir auch noch angucken. Danke.

Allerdings beantwortet das zwar mein aktuelles Problem, aber nicht, ob man Plugins generell irgendwie sinnvoll debuggen kann oder nicht,

Gruss,

der Jan

[Bodo]

Hoi

Ha freut mich, dass ich mit meinem messerscharfen Verstand helfen konnte.

[mumpf]

Hi,

die Frage nach dem Debuggen würd mich auch sehr interessieren. Zumindest wenn es komplizierter wird ist es mit Instrumentierung und Logs auswerten nicht wirklich lustig.

@Makki: Du wirst ja auch den wiregate.pl irgendwie debuggen, und der startet doch die plugins - willst Du uns nicht verraten, wie Dein setup aussieht?

Apprpos debuggen: Es gibt auf der Plugin-Seite die "Plugin-Debug-Infos", und diese Liste wird immer länger, da dort auch Einträge von "Versuchs-Plugins" stehen bleiben. Ich such nach ner Möglichkeit, an die Liste der existierenden Plugins zu kommen - dann würden ich ein Plugin schreiben, dass diese Liste mit den Einträgen in $plugin_info abgleichen und die überflüssigen Einträge entfernen... nur der Übersichtlichkeit wegen.

Gruß, Waldemar

[makki]

Sicher verrate ich das: Debuggen läuft bei mir normalerweise so:

a) Ich habe einen wiregated.pl auf meinem Ubuntu-Notebook, grep, tail & Co
-> "wiregated.pl -d" starten - spuckt so ziemlich alles aus, /var/log/wiregate_plugin.log den eher essentiellen Teil für Plugins. Ziemlich sofort nach dem speichern eine Plugins wird es ja erneut ausgeführt.
- mit return XX oder schreiben von Werten in %plugin_info kann man eigentlich den Rest im Detail.
-> ggfs. wird der ein oder andere DEBUG(xxx) hinzugefügt, das ist aber eher relevant wenn man in der Mutter Probleme sucht oder besser verstehen will.

b) Alternativen: ich mach mir gelegentlich einen deutlich abgespeckten wiregated.pl aber da muss man dann halt sehr tief drinstecken und wissen warums dort dies und jenes nicht gibt; kann ich mal online stellen, für die aktuelleren Versionen gibts den aber so momentan nicht.

c) Wenn es grundsätzlich erstmal darum geht den Syntax usw zu lernen/finden, schreibe ich mir das erstmal "Standalone" in Perl und dann das Plugin daraus.

Apprpos debuggen: Es gibt auf der Plugin-Seite die "Plugin-Debug-Infos", und diese Liste wird immer länger, da dort auch Einträge von "Versuchs-Plugins" stehen bleiben.

Der grundsätzliche Plan ist eigentlich alles was es nicht mehr gibt (^PluginName_.*) da automatisch rauszulöschen aber bisher aus Angst nicht eingebaut.
Naja, es sterben damit ja auch keine Regenwälder wenn es drinbleibt, interims wäre ein Plugin das foreach $value in $plugin_info - if not -e ^$plugname - delete $plugin_info{$value} etwas.. (so ähnlich.. syntaktisch bewusst nicht korrekt damit jetzt nicht jeder.. es spielt keine Rolle ob die 50 Byte da im CF liegen..)

Makki

[mumpf]

-> "wiregated.pl -d" starten

Das probier ich mal bei Bedarf aus...

- mit return XX oder schreiben von Werten in %plugin_info kann man eigentlich den Rest im Detail.

So mach ich das auch, aber Instrumentierung ist ein sehr mühsamer Weg, um Fehler oder Ungereimtheiten zu finden...

b) Alternativen: ich mach mir gelegentlich einen deutlich abgespeckten wiregated.pl aber da muss man dann halt sehr tief drinstecken und wissen warums dort dies und jenes nicht gibt; kann ich mal online stellen, für die aktuelleren Versionen gibts den aber so momentan nicht.

Danke für das Angebot, aber für mich als gelegentlichen perl user ist das wahrscheinlich nicht das Richtige...

Der grundsätzliche Plan ist eigentlich alles was es nicht mehr gibt (^PluginName_.*) da automatisch rauszulöschen aber bisher aus Angst nicht eingebaut.
Naja, es sterben damit ja auch keine Regenwälder wenn es drinbleibt, interims wäre ein Plugin das foreach $value in $plugin_info - if not -e ^$plugname - delete $plugin_info{$value} etwas.. (so ähnlich.. syntaktisch bewusst nicht korrekt damit jetzt nicht jeder.. es spielt keine Rolle ob die 50 Byte da im CF liegen..)

Mir geht es hier primär um die Übersicht, gerade weil man in der Test-Phase durch Instrumentierung potentiell viele Ausgaben in der plugin_info hat. Ich dachte einfach, das finale Plugin umzubenennen und die alten Einträge loszuwerden wäre die Lösung.

Hab aber das @plugins-Array im wiregated.pl gefunden und inzwischen ein Plugin zum aufräumen geschrieben

Danke und Gruss,
Waldemar

[mbx]

In /var/log/wiregate_plugin.log schreiben?

Hallo,
kann man denn eigentlich irgendwie in das /var/log/wiregate_plugin.log schreiben?
Gruß, mbx

[makki]

Klar kann man, MANN ist root und kann alles - theoretisch

Also
plugin_log($plugname,"Mein Text");
-> das ist jedoch intern und nicht bestandteil der offiziellen "API", sprich das kann und wird sich vermutlich mal (bald!) ändern!
(Weil die Suppe in C/perlembed wandert, ohne die kaputten Perl-"Threads", mich nerven die segfaults auch tierisch )

Geschickter wäre daher:

my $ausgabe = "Das will ich sagen: ";
...
# will mir merken was hier stand .= entspricht anhängen an den String
$ausgabe .= " ist mir wichtig: $meineVariable";
...
$ausgabe .= " auch wichtig: $meineAndereVariable";
...
return $ausgabe;

Makki

[mbx]

Die "geschicke" Variante hört sich geschickt an.
So werde ich das machen. Perfekt.
Danke Makki. Gruß.

[Fry]

plugin_log($plugname,"Mein Text");
-> das ist jedoch intern und nicht bestandteil der offiziellen "API", sprich das kann und wird sich vermutlich mal (bald!) ändern!
(Weil die Suppe in C/perlembed wandert, ohne die kaputten Perl-"Threads", mich nerven die segfaults auch tierisch )

Ups, sososo! Da hab ich gerade alle meine Logdateien in /var/log/wiregate_plugin.log umgelenkt, und nun das...

Wo steht denn eigentlich, was die offizielle API ist? m.a.W., wie schreibt man Plugins aufwärtskompatibel für die Zukunft? Vielleicht mal eine Liste der "dos und donts" rausgeben.

Für wann kann man mit der C/perlembed-Version rechnen, und wird der Daemon wieder unter der GPL2 verfügbar sein, sprich offen für Weiterentwicklungen der Community?

Grüße,
Fry

[makki]

Wo steht denn eigentlich, was die offizielle API ist?

Na so richtig nirgends, das ist halt ein bisschen "gewachsen";

Ich will, ich will, ich will

AW: -> Na gut, es geht so..
-> Fakt ist: es geht ja alles, das ist Fluch (für den Hersteller) und Segen zugleich!

m.a.W., wie schreibt man Plugins aufwärtskompatibel für die Zukunft? Vielleicht mal eine Liste der "dos und donts" rausgeben.

Die Online-Hilfe sagt den Kern, das Ziel ist natürlich vorhandene (&bekannte!) Plugins vollständig unversehrt zu lassen, sofern es irgend möglich ist!!
Deswegen ist es auch hilfreich Plugins zu veröffentlichen, wenn ich da ein Problem sehe, werfe ich ein Warnbake in der Hoffnung das man sie sieht..

Aber man wird auch ein paar Zöpfe abschneiden müssen (das betrifft kein mir bekanntes Plugin!), weil da ist vieles gut, aber was da in Perl alles unbrauchbar ist und auf was für Ideen ihr alle kommt, habe ich halt auch erst in den letzten 4J gelernt..

Für wann kann man mit der C/perlembed-Version rechnen

Du beliebst zu scherzen? Bekommst von mir eher einen Hubschrauber als ein Datum
Erstmal werden langsam ein paar Sachen hinterm Vorhang umgebaut die keiner merken sollte, mühsam ist das mit dem Eichhörnchen..
Das passiert aber sehr Transparent, für den der mitlesen will.. (SVN/Trac siehe Update-Thread)

und wird der Daemon wieder unter der GPL2 verfügbar sein, sprich offen für Weiterentwicklungen der Community?

Grundsätzlich ja, wer meine letzten ca. 5000 Posts gelesen hat, sollte wissen, wie ich grundsätzlich zu OSS/GPL stehe..

Aber Du bist so ungefähr der dritte, der mir einen Patch schickt, gut so, aber das Verhältniss zu "das ist ja falsch/alt/warum gibts kein squeeze/.." ist 1:100, insofern werd ich mir das beim nächsten mal vorher besser überlegen..

Nur nochmal am Rande: es gibt keinerlei Not, das es GPL sein müsste! Da war initial viel übernommen aber im Laufe der Jahre wurden 80% geändert bzw. meist neu geschrieben - und fast jeder Punkt Upstream gemeldet! - teils ohne Feedback..
Anektode am Rande: (ganz) Anfangs hatte ich DPT/EIS-decode von mh übernommen - da waren nur leider 50% komplett falsch und 30% haben gefehlt - gemeldet, ist nix passiert, also hab ich sie neu geschrieben; dafür muss ich vor niemandem rechtfertigen ausser vielleicht vor JEF (linknx), das von C++ auf Perl umgesetzt zu haben, bei dem haben 100% gestimmt (aber nur 80% DPT's implementiert)

Anwender (=Kunden die das finanzieren) schreckt das ganze Entwicklungs-gelaber eher ab (verständlich!), wo es doch eigentlich einfach funktioniert, insofern wird das mittelfristig getrennt werden (müssen?)..
Ehrlich, mittelfristig werden wir das (GPL/OSS Entwickler-Talk) vom Support-Forum trennen müssen, wir habens mit mitm Beta-Forum versucht, das funktioniert derzeit aber nicht so sonders gut, also wirds eher eine SF-Liste werden müssen oder so..

Versteht mich mich bitte nicht falsch, aber stellt euch bitte mal naiv vor, ihr seid ein armer Bauherr so wie ich 2007 und keine Chefprogrammierer und lest jetzt in den ersten 20 Threads im Supportforum nur perlembed-gibts-noch-nicht--coding-fehler-hier-und-da--dieses-special-geht-noch-nicht
-> wo doch die Basics im WG wirklich einfach funktionieren - ohne grosses Fachwissen..

Makki